Single Sign-on und Credential Guard
Das Remote-Desktop-Protocol (RDP) ist schon etwas älter und ist sicherlich vielen dadurch bekannt, dass man hierüber auf einen entfernten Windows-Desktop oder auf eine veröffentlichte Anwendung zugreifen kann.
Die Kinderschuhe von RDP waren von der Firma Citrix und deren Produkt „Multiwin“, das war ab dem Jahr 1998 verfügbar. Die kleine Besonderheit war damals, dass Microsoft das ICA-Protokoll nicht als Bestandteil der Lizenzvereinbarnung mit Citrix aufnahm, sondern das eigene RDP-Protokoll (basierend auf T.128) entwickelte. RDP war somit ab Windows NT4.0 in der Terminal Server Edition verfübar und wurde dann später ab den Produkten Server 2000 und Windows XP verfügbar (nein, Windows 2000 Professional verfügte nicht über einen RDP-Dienst).
Das Remote Desktop Protocol verwendet in der Standardkonfiguration TCP 3389 für die Authentifzierung zwischen RDP-Client und RDP-Server und UDP 3389 für den Datastream.
Gleichzeitige Verbindungen und „/admin“
Im administrativen Modus (also ohne die Rolle RD-Session-Host (RDSH)) sind ohne weitere Lizensierung zwei parallele Sitzungen möglich. Der Schalter „/console“ ist seit Server 2008 obsolet geworden, da man nicht mehr die Sitzung „0“ bekommt. Der Schalter „/admin“ kommt nur dann bei der mstsc.exe zum Tragen, wenn man die Rolle RDSH installiert hat.
Installiert man die Rolle RD-Session-Host (RDSH), so sind mehr als 2 gleichzeitige Verbindungen möglich, jedoch muss der RDSH dann nach spätestens 180 Tagen lizensiert werden.
Configuration!
Single Sign-on mit Kerberos V5 bei RDP
Seit Windows Vista und Server 2008 ist es möglich die RDP-Verbindung per mstsc.exe durch Single Sign-on (SSO) mittels Kerberos V5 zu öffnen. Das bietet gleich mehrere Vorteile:
- bequem: ich muss nicht jedes Mal mein langes und sicheres Kennwort eintippen
- sicher: durch das SSO per Kerberos V5 haben Keylogger und neugierige Kollegen weniger Chancen an mein Kennwort zu kommen (sofern nicht einer der beiden GAUs (GAUE?) mit Kerberos aufgetreten ist)
Das Konfigurieren für SSO mit RDP ist nur eine Policy notwendig. Diese „Credential Delegation“-Policy arbeitet mit der alten contrained delegation durch das Kerberos V5-Protokoll. Die Einschränkung (constrainment) erfolgt durch den Service Principal Name (SPN) „TERMSRV“ und die Richtung.
Die Richtung kann auf einen Host beschränkt werden, kann aber auch mit Platzhaltern „*“ sehr weit gefasst werden.
So what?
Ein Kunde berichtete, dass dieses Singe Sign-On mit RDP auf einmal nicht mehr geht.
Wie, nicht mehr geht?
Ja, geht nicht mehr, nach einem Update auf den Windows 11-Clients.
In der Tat, dem ist so!
Ja, echt, dem ist so. Wenn man die diversen Suchmaschinen bemüht findet man reichlich problembeschreibende, hilfesuchende und verzweifelte Menschen, die in das gleiche Phänomen laufen:
Der Credential Guard (CG) blockiert die Verbindung per Kerberos V5 SSO bei Remote Desktop Protocol!
What the heck? Aus irgend einem Grund mag der Credential Guard nicht mehr die Anmeldedaten per SSO übertragen. Ich vermute, weil der LSA-Cache mit meinem Anmeldedaten bei Zielsystem gefüllt wird und der Credential Guard kennt einen bessere Alternative als dieses zu tun*.
Wird aber noch besser.
SSO bei RDP ist also perdu und der Grad der Verzweiflung treibt die Menschen lösungsorientiert vor sich her: dann trage ich halt per cmdkey die Anmeldedaten in die Registry meines Clients, Kreuzdonner!
Ist das die Lösung?
Tja, spannende Frage, in meinen Augen: nein.
Kennwörter sollen zwar nicht mehr ablaufen, jedoch kann es doch einen Grund haben, warum der CG das SSO unterbindet.
Einem nackten Mann greift man bekanntlicher Weise nicht in die Tasche. Warum müssen die Credentials eigentlich immer beim Zielsystem im LSA-Cache liegen? Denn an genau der Stelle kommt der
Remote Credential Guard
ins Spiel!
Remote Credential Guard (RCG)
Der Remote Credential Guard hat erst mal gar nicht so viel mit dem Credential Guard zu tun, zumindest verlangt dieser keinen LsaIso.exe-Prozess. Der RCG ist seit Windows 10 1607 und Server 2016 verfügbar und verwendet eine Call-back-Funktion im Falle einer RDP-Sitzung um dem User zu authentifizieren. Call-back bedeutet die Anmeldedaten des Uses bleiben auf dem Client, gelangen nicht in den LSA-Cache des RDP-Servers.
Dadurch ergeben sich folgende Vorteile:
- Credentials aren’t sent to the remote host
- During the remote session, you can connect to other systems using SSO
- An attacker can act on behalf of the user only when the session is ongoing
Welche (maßgeblichen) Nachteile habe ich?
- Das geht nur mit Kerberos V5-Authentifizierung. NTLM (v2 / v1) wird nicht unterstützt.
Remote Credential Guard am RDP-Client
Der RDP-Client muss gezielt die Funktion beim Verbingungsaufbau aufrufen. Entweder per
- mstsc.exe /RemoteGuard oder
- per GPO als persistentes Setting
Remote Credential Guard am RDP-Server
Der RDP-Server muss über einen etwas merkwürdigen Registry-Key zur Funktion des RCG „motiviert“ werden:
⇒ HKLM\System\CurrentControlSet\Control\Lsa
- REG_DWORD: DisableRestrictedAdmin
- Value data: 0
Das Ende vom Lied
Das Ende vom Lied heißt dann: SSO per RDP geht wieder, auch ab Windows 11 23H2 und zusätzlich werden die Credentials nicht bei den RDP-Server im LSA-Cache hinterlegt.
