RDP-Authentifizierung auf Netzwerkebene, Restricted Admin-Modus, Active Directory: Die drei Einstellungen, die entscheiden, wem Ihre Sitzung gehört

Jede Remote-Desktop-Härtungscheckliste endet mit denselben drei Punkten: RDP-Authentifizierung auf Netzwerkebene, Restricted Admin-Modus, zwischengespeicherte Active-Directory-Anmeldeinformationen. Alle drei abzuhaken macht eine Remote-Desktop-Sitzung noch nicht sicher. Zwei davon sind echte Verteidigungsgewinne, und der dritte — der Restricted Admin-Modus — schützt die Anmeldeinformationen, die Sie eingeben, während er einem Angreifer, der bereits einen Hash besitzt, einen Weg hinein verschafft.

Dieser Artikel trennt die drei Einstellungen, zeigt, wie sie sich gegenseitig einschränken, und liefert die Registrierungswerte, Gruppenrichtlinienpfade und Ereignisfelder, die zur Überprüfung jeder einzelnen benötigt werden.

Was RDP-Authentifizierung auf Netzwerkebene, Restricted Admin-Modus, Active-Directory-Härtung bedeuten

Eine Remote-Desktop-Verbindung zu einem domänenbeigetretenen Host umfasst drei unabhängige Entscheidungen, die jeweils an anderer Stelle konfiguriert werden:

1. Authentifizierung auf Netzwerkebene (NLA) — wird der Benutzer authentifiziert, bevor eine Sitzung aufgebaut wird?
2. Die Sicherheitsebene — wie wird der Kanal selbst authentifiziert und verschlüsselt?
3. Der Delegationsmodus für Anmeldeinformationen — sendet der Client überhaupt Anmeldeinformationen an den Remote-Host?

Eine vierte Einstellung, die Anzahl der zwischengespeicherten Anmeldungen, entscheidet, wie viel Anmeldematerial anschließend auf dem Host zurückbleibt. Die meisten Audit-Tools melden diese als vier unabhängige Kontrollkästchen. In der Praxis wirken sie zusammen: Die falsche Sicherheitsebene deaktiviert NLA stillschweigend, und das Aktivieren des „sicheren" Delegationsmodus ändert, was ein Angreifer benötigt, um sich anzumelden.

Die Sicherheitsebene kommt zuerst

Die drei Sicherheitsebenen

Microsoft dokumentiert drei Sicherheitsebenen für eine RD-Sitzungshostverbindung. Der Unterschied ist wichtiger, als er aussieht, denn eine der drei schließt sich gegenseitig mit NLA aus:

Dieser letzte Satz stammt von Microsoft, aus Configure Server Authentication and Encryption Levels. Er erklärt, warum ein Host eine Richtlinie „NLA erforderlich" tragen und trotzdem keine wirksame NLA haben kann: Landet die ausgehandelte Ebene bei nativer RDP-Verschlüsselung, greift Microsofts eigener Ausschluss, und Authentifizierung auf Netzwerkebene kann nicht genutzt werden.

Dass „Aushandeln" die Standardeinstellung ist, ist das leise Problem, und es ist kein Altlast-Artefakt: Microsofts aktuelle SecurityLayer-Referenz dokumentiert weiterhin 1 (Negotiate/Aushandeln) als „den Standardwert". Sie erzwingt kein TLS — sie akzeptiert, was der Client anbietet, und stuft für einen Client, der keine TLS-Unterstützung angibt, auf die RDP-Sicherheitsebene herab. Ein Angreifer, der die Client-Seite des Handshakes kontrolliert, kontrolliert diese Wahl.

Verschlüsselungsstufen

Eine separate Einstellung, die Verschlüsselungsstufe, bestimmt die Schlüsselstärke. Microsoft listet vier Werte, mit Clientkompatibel als Standard:

„Niedrig" ist es wert, klar ausgesprochen zu werden: Es lässt den Datenverkehr vom Server zum Client — die Bildschirminhalte einer administrativen Sitzung — im Klartext.

Alle diese Einstellungen befinden sich unter Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security, und Microsoft weist darauf hin, dass diese Gruppenrichtlinieneinstellungen „Vorrang vor den in der Remotedesktopsitzungshost-Konfiguration konfigurierten Einstellungen haben, mit Ausnahme der Richtlinieneinstellung für die Serverauthentifizierungszertifikatvorlage."

Warum Authentifizierung auf Netzwerkebene wichtig ist

NLA verlagert die Benutzerauthentifizierung vor den Sitzungsaufbau. Microsofts ursprüngliche Beschreibung ist weiterhin die klarste: Sie „schließt die Benutzerauthentifizierung ab, bevor Sie eine Remotedesktopverbindung herstellen und der Anmeldebildschirm angezeigt wird", und die genannten Vorteile sind, dass der Remotecomputer „eine begrenzte Anzahl von Ressourcen verwendet, bevor der Benutzer authentifiziert wird", und dass dies „zu einer besseren Sicherheit beitragen kann, indem das Risiko von Denial-of-Service-Angriffen verringert wird" (Configure Network Level Authentication).

Der Wert dieser Vorauthentifizierungsgrenze ist nicht theoretisch. In den mit dem Advisory zu CVE-2019-0708 veröffentlichten Workarounds — der Pre-Authentication-Sicherheitslücke in Remotedesktopdiensten für Remotecodeausführung, gemeinhin BlueKeep genannt — schrieb Microsoft:

NLA machte aus einem wurmfähigen Pre-Auth-Bug einen Post-Auth-Bug. Das ist das gesamte Argument dafür, sie zu verlangen — sie stellt jede künftige Pre-Authentication-RDP-Schwachstelle hinter eine Anmeldedatenprüfung.

Die hostseitige Einstellung ist ein einzelner Registrierungswert:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication

1 erfordert NLA, 0 deaktiviert sie. Microsofts eigene Azure-VM-Fehlerbehebungsanleitung verwendet genau diesen Wert, um NLA vorübergehend zu deaktivieren und wieder zu aktivieren — was auch der Grund ist, warum sie während eines Vorfalls dauerhaft abgeschaltet und nie wieder eingeschaltet wird.

Restricted Admin-Modus: Die Einstellung mit zwei Seiten

Der Restricted Admin-Modus ändert, was der Client sendet. Microsofts Remote Credential Guard-Dokumentation listet dessen Sicherheitsvorteile genau auf:

• Anmeldeinformationen werden nicht an den Remote-Host gesendet
• Die Remote-Desktop-Sitzung greift auf andere Ressourcen unter der Identität des Remote-Hosts zu
• Ein Angreifer kann nicht im Namen des Benutzers handeln, und jeder Angriff bleibt lokal auf dem Server

Microsofts Vergleichstabelle kennzeichnet den Restricted Admin-Modus als Schutz vor Pass-the-Hash und empfiehlt ihn für Helpdesk-Szenarien ausdrücklich: „RDP-Verbindungen sollten nur mit dem Schalter /RestrictedAdmin initiiert werden." Beachten Sie außerdem, dass der RDP-Zugriff unter Restricted Admin durch Mitgliedschaft in der Gruppe Administratoren auf dem Remote-Host gewährt wird, nicht durch die Gruppe Remotedesktopbenutzer.

Sowohl der Modus als auch Remote Credential Guard hängen von einem einzigen hostseitigen Wert ab:

reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

Die Umkehrung

Hier weichen die beiden Sichtweisen voneinander ab, und die Abweichung ist gerichtet.

Microsofts Aussage betrifft Anmeldeinformationen, die den Client verlassen: Mit Restricted Admin landet nichts auf dem Remote-Host, sodass dort nichts abgegriffen und wiederverwendet werden kann. Das stimmt.

Die Konsequenz betrifft Anmeldeinformationen, die in den Host gelangen. Weil der Client kein Passwort mehr sendet, wird die Anmeldung mit dem Anmeldematerial erfüllt, das der Client bereits besitzt — was bedeutet, dass ein NTLM-Hash ausreicht. Öffentliche Forschung dokumentierte dies bereits im Jahr der Veröffentlichung des Features. Portcullis Labs (Autor MRL, 20. Oktober 2013) beschrieb, dass der Client unter Windows 8.1 und Windows Server 2012 R2 „leere Anmeldeinformationen in der TSPasswordCreds-Struktur" sendet, und zeigte eine Authentifizierung, bei der ein Hash anstelle des Passworts übergeben wurde. Ihr Proof of Concept war kein Standardclient: Er benötigte FreeRDP-pth, ein gepatchtes FreeRDP, dessen Argument -p einen NT-Hash statt eines Passworts überträgt.

# FreeRDP-pth, der gepatchte Client von 2013 — -p nimmt den NT-Hash entgegen
xfreerdp -u test -p 36374BD2767773A2DD4F6B010EC5EE0D 192.168.226.129

Ein Standardbuild akzeptiert das nicht: Er behandelt den Hash als Klartextpasswort, und die Anmeldung schlägt fehl. Das aktuelle FreeRDP implementiert die Fähigkeit nativ, mit der als „Pass the hash (restricted admin mode)" dokumentierten Option:

xfreerdp3 /u:test /pth:36374BD2767773A2DD4F6B010EC5EE0D /v:192.168.226.129

Derselbe Beitrag stellt fest, dass die Technik nur für Administratoren funktioniert — Mitglieder der Gruppe Remotedesktopbenutzer können sich auf diesem Weg nicht authentifizieren. Mit dem nativen Windows-Client entspricht dem das vorherige Einschleusen des Hashes in eine Anmeldesitzung:

sekurlsa::pth /user:Administrator /domain:CORP /ntlm:<hash> /run:"mstsc.exe /restrictedadmin"

Beide Aussagen treffen also zu. Der Restricted Admin-Modus verhindert, dass Ihre Anmeldeinformationen vom Remote-Host gestohlen werden, und er senkt gleichzeitig die Hürde für die Anmeldung an diesem Host von einem Klartextpasswort auf einen Hash. Ist Pass-the-Hash in Ihrer Umgebung bereits durchführbar, erweitert die domänenweite Aktivierung des Restricted Admin-Modus dies auf den interaktiven RDP-Zugriff auf jedem Host, auf dem er aktiviert ist.

Es gibt eine zweite Konsequenz. Weil die Authentifizierung anhand eines Tokens statt eines eingegebenen Passworts bewertet wird, können am Zielsystem erzwungene Kontrollen umgangen werden. SpiderLabs (Apurva Goenka, 15. November 2023 — veröffentlicht unter Trustwave, inzwischen von LevelBlue übernommen) dokumentierte, dass die Authentifizierung „nicht auf dem Remote-Desktop-Server, sondern auf dem Client selbst" stattfindet, sodass „am Zielserver erzwungene Authentifizierungsfaktoren wie über Duo, Okta … bereitgestellte MFA wirkungslos werden" (Restricted Admin Mode – Circumventing MFA On RDP Logons).

Zwischengespeicherte Anmeldungen: Was zurückbleibt

Zwischengespeicherte Domänenanmeldeinformationen erlauben einem Benutzer die Anmeldung, wenn kein Domänencontroller erreichbar ist. Microsofts Anleitung zu Interaktive Anmeldung: Anzahl der zwischenzuspeichernden vorherigen Anmeldungen (für den Fall, dass kein Domänencontroller verfügbar ist) benennt das Risiko direkt: „Ein Angreifer, der auf das Dateisystem des Servers zugreifen kann, könnte diese zwischengespeicherten Informationen finden und mit einem Brute-Force-Angriff versuchen, Benutzerpasswörter zu ermitteln." Die zwischengespeicherten Informationen „laufen nicht ab, können aber überschrieben werden."

Der Standardwert ist 10 Anmeldungen auf Mitgliedsservern und Clientcomputern, der zulässige Bereich reicht von 0 bis 50. Microsofts Standardwerttabelle listet den effektiven Standardwert für Domänencontroller als Keine Auswirkung — die Einstellung gilt dort schlicht nicht.

Seien Sie vorsichtig, wie Sie die Empfehlung zitieren, denn Microsofts eigene Seite spricht nicht mit einer Stimme. Ihr Abschnitt Gegenmaßnahme rät, den Wert auf 0 zu setzen und die lokale Zwischenspeicherung zu deaktivieren. Ihr Abschnitt Bewährte Methoden besagt, dass die Windows-Sicherheitsbaselines empfehlen, „diese Einstellung überhaupt nicht zu konfigurieren". Ihr Abschnitt Mögliche Auswirkungen schlägt 2 für Endbenutzercomputer vor, damit mobile Benutzer sich weiterhin offline anmelden können. Die vertretbare Position für einen Tier-0-Mitgliedsserver ist ein niedriger Wert; bei Laptops zerstört 0 die Offline-Anmeldung vollständig. Ein Vorbehalt, der regelmäßig falsch gemacht wird: Diese Einstellung gilt nicht für Domänencontroller, deren effektiven Standardwert Microsoft als „Keine Auswirkung" auflistet — DCs verwalten das Verzeichnis und speichern keine Domänenanmeldungen zwischen.

Erkennung

Ereignis 4624 enthält die Felder, die zur Unterscheidung dieser Anmeldungen benötigt werden. Version 2 des Ereignisses (Windows 10 und später) fügte ein Feld RestrictedAdminMode hinzu, das laut Microsoft „nur für Anmeldesitzungen des Typs RemoteInteractive ausgefüllt wird" und als Ja/Nein-Kennzeichen angibt, ob der Restricted Admin-Modus verwendet wurde.

Dieses Detail ist für eine korrekte Regel entscheidend: Eine Restricted-Admin-RDP-Sitzung ist weiterhin Anmeldetyp 10 (RemoteInteractive), nicht Typ 3. Der Modus ist im Kennzeichen sichtbar, nicht im Anmeldetyp.

Microsofts Überwachungsempfehlung auf derselben Seite lohnt sich, wörtlich zu übernehmen: Muss der Restricted Admin-Modus von bestimmten Konten verwendet werden, überwachen Sie Anmeldungen dieser Konten mit Logon Type = 10 und Restricted Admin Mode = „Ja", und lösen Sie einen Alarm aus, wenn Restricted Admin Mode = „Nein" für sie ist. Die Umkehrung ist ebenso nützlich — alarmieren Sie, wenn RestrictedAdminMode = „Ja" für Konten, die ihn niemals verwenden sollten, da Angreifer-Tools gezielt zu /restrictedadmin greifen, weil es einen Hash akzeptiert.

Die Konfiguration auditieren

Das Auditieren der Konfiguration selbst ist ein Registrierungs-Lesevorgang auf jedem Host:

$ts = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
Get-ItemProperty -Path $ts -Name UserAuthentication, SecurityLayer, MinEncryptionLevel
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name DisableRestrictedAdmin -ErrorAction SilentlyContinue

Ein fehlender Wert DisableRestrictedAdmin bedeutet, dass der Modus nicht aktiviert ist; ein Wert von 0 bedeutet, dass er es ist.

Remediation

1. TLS als Sicherheitsebene verlangen. Aktivieren Sie Verwendung einer bestimmten Sicherheitsebene für Remoteverbindungen (RDP) erfordern und wählen Sie SSL, unter Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security. Stellen Sie RD-Sitzungshost-Zertifikate über Ihre interne CA aus, statt das selbstsignierte Standardzertifikat zu akzeptieren.

2. NLA verlangen. Aktivieren Sie im selben Richtlinienpfad Benutzerauthentifizierung für Remoteverbindungen mithilfe der Authentifizierung auf Netzwerkebene erfordern. Gruppenrichtlinien haben Vorrang vor lokaler Konfiguration, was für die Drift-Kontrolle erwünscht ist.

3. Verschlüsselungsstufe erhöhen. Setzen Sie Verschlüsselungsstufe für Clientverbindungen festlegen auf Hoch, sodass der Datenverkehr in beide Richtungen 128-Bit-verschlüsselt ist, und stellen Sie sicher, dass kein Host bei Niedrig verbleibt.

4. Entscheiden Sie sich bewusst und pro Tier für den Restricted Admin-Modus. Aktivieren Sie ihn nicht reflexartig domänenweit. Wo Administratoren sich mit weniger vertrauenswürdigen Hosts verbinden, bevorzugen Sie Remote Credential Guard über die Richtlinie Delegierung von Anmeldeinformationen an Remoteserver beschränken, gesetzt auf Remote Credential Guard erforderlich. Wo er für Helpdesk-Arbeiten tatsächlich benötigt wird, aktivieren Sie ihn nur auf diesen Hosts und alarmieren Sie bei seiner Verwendung anderswo. Beachten Sie Microsofts Hinweis: Ist Delegierung von Anmeldeinformationen einschränken aktiviert, „wird der Schalter /restrictedAdmin ignoriert" und stattdessen Remote Credential Guard verwendet.

5. Delegierung nicht exportierbarer Anmeldeinformationen auf Remote-Hosts aktivieren — erforderlich sowohl für Restricted Admin als auch für Remote Credential Guard — über Remotehost erlaubt Delegierung nicht exportierbarer Anmeldeinformationen.

6. Zwischengespeicherte Anmeldungen auf Servern reduzieren. Setzen Sie Interaktive Anmeldung: Anzahl der zwischenzuspeichernden vorherigen Anmeldungen auf einen niedrigen Wert unter Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Validieren Sie dies gegen Ihre Offline-Anmeldeanforderungen, bevor Sie es auf Laptops anwenden.

7. LAPS bereitstellen. Microsoft kombiniert seine Restricted-Admin-Anleitung mit Windows LAPS, das „das Risiko lateraler Eskalation" durch gemeinsam genutzte lokale Administratorpasswörter mindert — genau die Bedingung, die einen einzelnen gestohlenen Hash auf jedem Host nützlich macht.

Das Ergebnis überprüfen

Überprüfen Sie das Ergebnis, statt dem GPO-Bericht zu vertrauen:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" |
    Select-Object UserAuthentication, SecurityLayer, MinEncryptionLevel

UserAuthentication sollte 1 sein und SecurityLayer sollte 2 (TLS) sein.

Diese Kontrollen verstärken sich gegenseitig mit dem Rest Ihrer Authentifizierungshärtung — TLS für RDP zu verlangen ist dasselbe Argument wie das Verlangen von SMB-Signierung und LDAP-Signierung auf NTLM-Relay-Pfaden, und die Einschränkung, wer über RDP auf Tier 0 zugreifen darf, ist untrennbar mit der Einschränkung von Kerberos-Delegation und Passwort-Richtlinien verbunden.

Wie EtcSec dies erkennt

EtcSec prüft diese vier Einstellungen unabhängig voneinander, weil sie unabhängig voneinander versagen. PA038_RDP_NLA_NOT_REQUIRED erzeugt einen Befund, wenn keine GPO in der Domäne UserAuthentication auf 1 setzt. PA038_RDP_SECURITY_LAYER_WEAK löst aus, sofern keine Richtlinie die Sicherheitsebene auf TLS festlegt, sodass auch der Negotiate-Standard gemeldet wird, der still herabstufen kann. TERMINAL_SERVICES_NOT_HARDENED deckt die breitere Konfigurationsoberfläche von Terminaldiensten und RDP ab, und CACHED_LOGONS_EXCESSIVE löst bei einem Winlogon\CachedLogonsCount über 4 aus. Dies sind richtlinienbezogene Prüfungen: Ein sauberes Ergebnis bedeutet, dass die Richtlinie existiert, und zu bestätigen, dass sie tatsächlich auf jedem Host angekommen ist, erfordert weiterhin den oben genannten Registrierungs-Lesevorgang.