RDP ohne Credential-Preisgabe: RCG und Restricted Admin

Eine normale Remotedesktopverbindung sendet Ihre Anmeldedaten an den Server, damit er Sie anmelden und in Ihrem Namen handeln kann. Das ermöglicht einmaliges Anmelden an Dateifreigaben innerhalb der Sitzung. Es bedeutet aber auch, dass ein Administrator, der sich mit einem kompromittierten Server verbindet, wiederverwendbare Anmeldedaten im LSASS dieses Servers hinterlässt: einen NTLM-Hash, Kerberos-Tickets und -Schlüssel. Für einen Angreifer, der bereits lokale Admin-Rechte auf einem Mitgliedsserver hat, ist das Warten auf eine privilegierte RDP-Anmeldung einer der zuverlässigsten Wege zur Rechteausweitung.

Zwei Funktionen ändern das. Der Restricted Admin Mode meldet Sie an, ohne überhaupt wiederverwendbare Anmeldedaten zu senden. Remote Credential Guard hält die Anmeldedaten auf Ihrem Client und leitet Kerberos-Anfragen dorthin zurück. Dieser Leitfaden zeigt, wie Sie beide auf beiden Seiten aktivieren, ihre Verwendung erzwingen und prüfen, ob sie tatsächlich greifen. Zur Transportseite von RDP (NLA, TLS, wer sich verbinden darf, Port-Exposition) siehe RDP-Härtung.

Die Modi im Vergleich

Remote Credential Guard ist der bessere Standard für Administratoren. Restricted Admin ist die Rückfallebene, wenn Kerberos nicht verfügbar ist oder Client und Server nicht in Domänen mit Vertrauensstellung liegen.

Beide Funktionen ergänzen Credential Guard auf dem Server gut. Credential Guard erschwert das Auslesen von Geheimnissen aus LSASS; diese Modi sorgen dafür, dass die Geheimnisse gar nicht erst dort landen.

Schritt 1: Die Modi auf den Servern zulassen

Beide Modi sind auf dem Ziel standardmäßig deaktiviert. Der maßgebliche Wert lautet:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: DisableRestrictedAdmin  (REG_DWORD) = 0

Der Wert 0 erlaubt eingehende Verbindungen mit Restricted Admin und Remote Credential Guard. Per Gruppenrichtlinie setzen Sie Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation > Remote host allows delegation of non-exportable credentials auf jedem Server und Admin-Ziel auf Enabled. Das schreibt AllowProtectedCreds = 1 unter HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation und hat für eingehende Verbindungen dieselbe Wirkung.

Verteilen Sie das mit demselben GPO, das Sie für die Härtung der Mitgliedsserver verwenden, und beziehen Sie die Jump-Hosts ein. Auf dem Server gibt es keinen Nachteil: Ein Client, der diese Modi nicht anfordert, verbindet sich weiterhin normal.

Schritt 2: Die Modi auf Admin-Clients verlangen

Zulassen reicht nicht; der Client entscheidet, welchen Modus er anfordert. Setzen Sie auf Privileged Access Workstations und Admin-Jump-Hosts Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers auf Enabled und wählen Sie einen Modus:

Die Richtlinie schreibt RestrictedRemoteAdministration = 1 und einen Wert RestrictedRemoteAdministrationType unter HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation. Restrict Credential Delegation ist während des Rollouts die praktische Wahl: Admins verbinden sich nie im Standardmodus, und Server, die nur Restricted Admin unterstützen, funktionieren weiterhin. Sobald jeder Server Remote Credential Guard unterstützt, wechseln Sie zu Require Remote Credential Guard.

In Intune suchen Sie im Einstellungskatalog nach Credentials Delegation; Client- und Servereinstellungen stehen dort als ADMX-gestützte Richtlinien bereit.

Einzelne Admins können einen Modus auch pro Verbindung anfordern, was für Tests nützlich ist:

mstsc.exe /remoteGuard /v:srv-app01.corp.example
mstsc.exe /restrictedAdmin /v:srv-app01.corp.example

Schritt 3: Die Voraussetzungen für Remote Credential Guard prüfen

Remote Credential Guard scheitert auf eine Weise, die wie generische RDP-Fehler aussieht. Die üblichen Ursachen:

• Der Client erreicht keinen Domänencontroller. Kerberos-Anfragen werden an den Client zurückgeleitet, der dann Sichtverbindung zu einem DC braucht. Admins in einem VPN, das nicht zu den DCs routet, scheitern.
• Das Ziel wird per IP-Adresse angesprochen. Kerberos braucht einen Dienstprinzipalnamen; verbinden Sie sich über den DNS-Namen.
• Gespeicherte Anmeldedaten. Remote Credential Guard akzeptiert die angemeldeten oder in der Abfrage eingegebenen Anmeldedaten, nicht aber in der Anmeldeinformationsverwaltung gespeicherte. Sich an der PAW mit dem Admin-Konto des jeweiligen Tiers anzumelden, bleibt ohnehin das sauberere Tiering-Design.
• Vertrauensstellung. Client und Server müssen in derselben Domäne oder in Domänen mit Vertrauensstellung sein.
• Join-Typ und Verbindungsweg des Ziels. Das Ziel muss in Active Directory eingebunden sein; Remote Credential Guard kann nicht zu in Microsoft Entra eingebundenen Zielen verwendet werden (ein in Entra eingebundener Client kann sich mit einem in AD eingebundenen Host verbinden, wenn er Kerberos-Tickets erhalten kann). Es funktioniert nur bei direkten Verbindungen, nicht über den Remote Desktop Connection Broker oder das Remote Desktop Gateway.
• Client-App. Erforderlich ist der Remotedesktop-Windows-Client (mstsc.exe); die Remotedesktop-UWP-App unterstützt es nicht.

Schritt 4: Das Risiko von Restricted Admin verringern

Restricted Admin hat einen bekannten Zielkonflikt: Es meldet sich mit einer netzwerkartigen Authentifizierung an, sodass der NTLM-Hash eines Administrators genügt, um eine RDP-Sitzung zu einem Server zu öffnen, der es erlaubt. Das ist die Technik „Pass-the-Hash über RDP“. Entschärfen Sie sie mit Maßnahmen, die Sie ohnehin haben sollten:

• Nehmen Sie Admin-Konten von Personen in Protected Users auf, das NTLM für sie ablehnt. Siehe Admin-Tiering und Protected Users.
• Nutzen Sie die Tiering-Rechte Deny log on through Remote Desktop Services, damit jedes Admin-Konto nur sein eigenes Tier erreicht.
• Bevorzugen Sie Require Remote Credential Guard, sobald Ihre Server es unterstützen, da es Kerberos voraussetzt.

Schritt 5: Die übrigen Delegierungswege für Anmeldedaten entfernen

Der Richtlinienknoten Credentials Delegation steuert auch CredSSP, das konstruktionsbedingt wiederverwendbare Anmeldedaten delegiert. Prüfen Sie diese Einstellungen auf den Clients:

• Allow delegating default credentials, Allow delegating saved credentials und Allow delegating fresh credentials: nicht konfiguriert lassen, sofern kein bestimmter Dienst sie braucht; und wenn doch, die Serverliste eng fassen (zum Beispiel TERMSRV/rds-farm.corp.example, niemals TERMSRV/* oder *).
• Encryption Oracle Remediation: auf Force Updated Clients belassen, damit ungepatchte CredSSP-Endpunkte abgelehnt werden.

Aktivieren Sie außerdem Do not allow passwords to be saved unter Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client, damit Admins keine RDP-Kennwörter in der Anmeldeinformationsverwaltung ablegen. Der Leitfaden zu zwischengespeicherten Anmeldungen und WDigest behandelt die weiteren Einstellungen für gespeicherte Anmeldedaten.

Was kaputtgeht

• Double-Hop-Zugriffe unter Restricted Admin. Dateifreigaben, SQL und andere Ressourcen werden als Computerkonto des Servers erreicht. Skripte, die als Admin laufen sollen, schlagen fehl oder, schlimmer, laufen erfolgreich mit den Berechtigungen des Servers.
• Gespeicherte RDP-Anmeldedaten sowie Verbindungen über RD Gateway oder Connection Broker unter Require Remote Credential Guard.
• Verbindungen per IP-Adresse oder über VPNs ohne DC-Zugang unter Remote Credential Guard.
• RDP-Benutzer ohne Admin-Rechte unter Restricted Admin, da der Modus lokale Admin-Rechte auf dem Ziel voraussetzt.
• Manche RDP-Clients und Verbindungsmanager von Drittanbietern, die diese Modi nicht implementieren. Testen Sie Ihre Werkzeuge, einschließlich browserbasierter Gateways.

Überprüfen

1. Auf dem Server. Das Sicherheitsereignis 4624 mit Logon Type 10 (RemoteInteractive) enthält ein Feld Restricted Admin Mode und auf aktuellen Builds ein Feld Remote Credential Guard. Bei privilegierten Konten sollte eines davon Yes lauten.
2. Innerhalb der Sitzung. Führen Sie klist aus. Unter Remote Credential Guard erhalten Sie weiterhin Diensttickets für Netzwerkressourcen unter Ihrer eigenen Identität; unter Restricted Admin erfolgt der Netzwerkzugriff als Computerkonto.
3. Konfigurationsdrift. Prüfen Sie DisableRestrictedAdmin auf Servern und RestrictedRemoteAdministrationType auf Admin-Clients über ein Compliance-Skript.

Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4624} -MaxEvents 200 |
  Where-Object { $_.Properties[8].Value -eq 10 } |
  Select-Object TimeCreated, @{n="User";e={$_.Properties[5].Value}}, Message -First 20

Suchen Sie nach privilegierten Konten mit Restricted Admin Mode: No und Remote Credential Guard: No. Das sind die Verbindungen, die Anmeldedaten zurückgelassen haben.

Checkliste

• DisableRestrictedAdmin = 0 (oder „Remote host allows delegation of non-exportable credentials“) auf allen Servern
• PAWs und Jump-Hosts auf Restrict Credential Delegation gesetzt, danach auf Require Remote Credential Guard
• Admins melden sich an der PAW mit dem Admin-Konto ihres Tiers an und verbinden sich über den DNS-Namen
• Admin-Konten in Protected Users, um Pass-the-Hash über Restricted Admin zu unterbinden
• Delegierung von Standard- und gespeicherten Anmeldedaten über CredSSP nicht konfiguriert oder eng gefasst
• RDP-Client darf keine Kennwörter speichern
• Ereignis 4624 Typ 10 auf privilegierte Anmeldungen ohne einen der beiden Modi geprüft

Das ist eine der günstigsten Methoden, um einen Angreifer auf einem Tier-1-Server daran zu hindern, Admin-Anmeldedaten abzugreifen. Es gehört in die Reihe Schutz von Anmeldedaten, neben Remote Credential Guard im Glossar.