[English]Ich greife nochmals ein Thema auf, welches mir im Sommer 2023 von einem Blog-Leser zugeschickt wurde. In Windows 11 22H2 deutet es sich an, dass der Remote Credential Guard des Windows Defender, der das Stehlen von Anmeldeinformationen auf Terminalservern verhindert soll, nur unter speziellen Konstellationen funktioniert. Ich hatte Administratoren gebeten, das zu testen. Inzwischen habe ich die Rückmeldung, was das Problem war.
Anzeige
Remote Credential Guard
Anmeldeinformationen von Administratoren sind hoch privilegiert und deren Schutz bekommt eine hohe Bedeutung. Microsoft hat daher bereits in Windows 10, Version 1607, den Windows Defender Remote Credential Guard eingeführt. Das Sicherheitsfeature hilft dabei, Anmeldeinformationen über eine Remotedesktopverbindung zu schützen. Dazu leitet der Remote Credential Guard des Windows Defender Kerberos-Anfragen an das Gerät zurück, das die Verbindung anfordert.
Der Windows Defender Remote Credential Guard stellt sicher, dass die Anmeldedaten, die für die Verbindung während einer Remotedesktopsitzung verwendet werden, geschützt sind. Das gilt sogar für die Fälle, in denen das Zielgerät kompromittiert wird, da sowohl die Anmeldedaten als auch die Ableitungen der Anmeldedaten niemals über das Netzwerk an das Zielgerät weitergeleitet werden. Außerdem ermöglicht das Feature eine einmalige Anmeldung für Remotedesktopsitzungen. Microsoft beschreibt die Details des Windows Defender Remote Credential Guard in diesem Support-Beitrag. Wolfgang Sommergut hat die Funktion und deren Aktivierung z.B. in diesem Beitrag beschrieben.
Ein Leser berichtet von Problemen
Blog-Leser W. A. hat mich zum 8. Juni 2023 per Mail kontaktiert. Der Leser schrieb dazu, dass ein von Microsoft wärmstens empfohlenes Sicherheitsfeature offenbar kaum genutzt werde.
Anzeige
Und zwar: Remote Credential Guard, welches das Stehlen von Anmeldeinformationen auf Terminalservern unmöglich machen soll [siehe die obigen Erklärung]. Eigentlich eine feine Sache.
Ich habe festgestellt, dass es nur genau dann mit Microsofts neuestem Windows (11 22H2) funktioniert, wenn man auch auf der anderen Seite der RDP-Verbindung ebenfalls Windows 11 22H2 hat.
Andernfalls lässt Windows zwar die Anmeldung zu, aber die eigentliche Funktion von Remote Credential Guard, nämlich die Umleitung der Autorisierungsanfragen an den Rechner von dem man ursprünglich kommt, ist nicht mehr gegeben: Single-Sign-On (SSO) ist zerstört und man muss sich stets re-authentifizieren.
Das ist schon ein dicker Bock, denn auch Windows-11-Nutzer werden ja mitunter Terminalserver nutzen und da läuft dann ein Server OS (2016/2019/2022) und mit keinem von diesen funktioniert dann SSO mehr. Will man von den Servern aus also auf Domänen-Ressourcen rauf, muss man sich jedes Mal re-authentifizieren.
Ich hatte dies im Beitrag Windows 11 22H2: Verhunzter Defender Remote Credential Guard? aufgegriffen und Administratoren gefragt, ob dies so bestätigt werden kann.
Noch eine Problemmeldung von Mark
Mark Heitbrink hatte mich im Nachgang per Mail kontaktiert und schrieb: "ich habe gerade beim Kunden eine Baustelle und die passt zu deinem obigen Artikel". In seiner Mail schrieb er, dass der Remote Credential Guard in Windows 11 22H2 ist nicht kaputt ist. Er konnte es komplett in der Demo Umgebung nachstellen, suchte aber noch nach dem (seinem) Fehler und fragte: "Vielleicht kannst du deinem Leser informieren, der dir es gemeldet hat."
Mark schrieb: Wird nur der Remote Credential Guard per GPO konfiguriert, funktioniert er. In Kombination weiterer Härtungsmaßnahmen kommt es zum Fehler. Die Frage ist, welche Richtlinie macht es kaputt? Ich baue gerade alles Rückwärts im Auschlussverfahren, bzw. sobald es kaputt ist, kann ich es nicht mehr reparieren. Egal, ob ich die GPOs entferne oder nicht. Es muss ein "Preference" Eintrag sein, oder Dienst …
Bei seinem Kunden musste er explizit den Credential Guard von Windows 11 deaktivieren, da deren NAC sonst nicht funktioniert. Seine GPO:
Remote Credential Guard per GPO, ohne Credential Guard wegen der NAC
a) System/Delegierung von Anmeldeinformationen
Delegierung von Anmeldeinformationen an Remoteserver einschränken
Aktiviert
Verwenden Sie den folgenden eingeschränkten Modus: Delegierung von
Anmeldeinformationen einschränken (Alternativ: Remote Credential Guard anfordern, geht beides)
Remotehost ermöglicht die Delegierung nicht exportierbarer
Anmeldeinformationen Aktiviert
b) System/Device Guard
Virtualisierungsbasierte Sicherheit aktivieren Aktiviert
Plattform-Sicherheitsstufe auswählen: Sicherer Start und DMA-Schutz
Virtualisierungsbasierter Schutz der Codeintegrität: Ohne Sperre aktiviert
UEFI-Speicherattributtabelle erforderlich Deaktiviert
Credential Guard-Konfiguration: Deaktiviert
Sichere Startkonfiguration: Nicht konfiguriert
Hardware-erzwungener Stack-Schutz im Kernel-Modus: Aktiviert im
Erzwingungsmodus
c) per GPP Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
DisableRestrictedAdmin = REG_DWORD 0x0
Es sind nur diese 3 Richtlinien aktiv, die direkt ordentlich durchgereicht werden. Ees kommt zu einem SSO des Windows Benutzers, wenn er auf der Ziel Maschine das Recht hat, sich per RDP anzumelden. Alles so, wie der Remote Credential Guard arbeiten sollte. Mark hatte mir obige Information für den Leser, der oben berichtete, geschickt.
Er hat allerdings ein weiteres Problem, nachdem er seine Härtungsrichtlinien anwendet: Der Ziel Client meldet einen RPC Fehler und wird stumpf nach ca. 1 Minute neu gestartet. Später meldete er sich mit: "ich habe den Verursacher. Ein Eigentor. Wenn man ihn dann findet ist er leider erklärbar und halbwegs logisch." In seiner Kundenumgebung wurde ein benötigter Dienst abgeschaltet.
UmRdpService = Anschlussumleitung für Remotedesktopdienst im Benutzermodus (Startmodus: Deaktiviert)
Das CIS und Tenable sagen: Deaktivieren
Microsoft sagt: "Nicht konfigurieren"
Die Anschlussumleitung macht wohl auch das Redirect der Credentials. Die Umleitungsverhinderung von Anschlüssen kann man auch über "normale" Richtlinien absichern. Natürlich ist das Abschalten des Dienstes der einfachere Weg, da "Ein klick = Aus" dafür sorgt, das der Rest nicht konfigurieren muss. Aber das macht leider einiges kaputt.
Klare Empfehlung von Mark: Die Anschlüsse über die Policies steuern.
Computer Configuration\Administrative Templates\Windows-Komponenten\Remotedesktopdienste\Remotedesktopsitzungs-Host\Geräte- und Ressourcenumleitung\
Noch ein Problem
In einer Folgemail schrieb mir Mark noch, dass noch eine Kollision in den GPOs gefunden habe und nach der Lösung suche. Er kann mich mit einem AD User per RDP anmelden. Aber sobald er den .\Admimistrator verwendet, damit er LAPS und das Tiering verewnden kann, bekommt erh am Rechner wieder die identische Fehlermeldung wie mit dem "CredSSP". Alles was man dazu per Google findet, beziehe sich natürlich auf den Fehler, der mit der Oracle Problematik zu tun hatte.
Das Problem war Mark bisher mir noch nicht aufgefallen, da die meine Kunden nur den .\Administrator zum RunAs auf den Rechnern nutzen. Und dann kam jemand, der auch RDP wollte. Mark meinte dann dazu: "Ich bin nah dran das zu ignorieren und dem Kunden zu sagen, das er anders arbeiten muss, weil ich sowieso schon den "Zugriff über das Netzwerk" (User Rights Assignment) wieder für lokale Konten freigeben muss. Was ich eigentlich nicht möchte. "
Erklärung für das obige Verhalten
Die Erklärung für das oben in den Abschnitten beschriebene Verhalten hat Mark mir dann in einer Folgemail geliefert, da er beim Kunden auf die Lösung stieß.
- Der oben beschrieben Fehler mit dem Reboot und der RPC-Fehler tritt bei jeder Windows Professional auf, da dieses keinen Credential Guard unterstützt. Es ist ein Enterprise Feature.
- Ebenso ist der Remote Credential Guard (neuer Name aber gleiches Werkzeug für eine andere Verbindung) nur auf Windows Enterprise möglich.
Mark erläuterte, dass bei diesem Kunde der Credential Guard in der Enterprise explizit deaktiviert ist, da er die Anmeldung an der NAC verhindert. Mark ergänzte dann, dass er den Credential Guard schon öfter ausschalten musste, z.B. bei SSO an einem "Novell Netware" (oder wie auch immer es jetzt heißt) und auch SSO in einem WiFi mit zusätzlicher User Authentication. Sobald
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
auf DisableRestrictedAdmin = 0 gesetzt wird und dann von einer Source aus "mstsc /remoteGuard" aufgerufen wird, fliegt es dem Nutzer mit obigen Fehlern um die Ohren, schrieb Mark. Wenn die Verbindung mit dem RCGuard per GPO erzwungen wird passiert es ebenso.
Restrict delegation of credentials to remote servers =
Require Remote Credential Guard
Computer Configuration\Administrative Templates\System\Credentials Delegation\
Laut Mark funktioniert mstsc /RestrictedAdmin (siehe diesen Microsoft-Beitrag). Vielleicht helfen die obigen Erkenntnisse von Mark etwas weiter – mein oben verlinkter Artikel bekommt ja immer Kommentare von Administratoren, die in Probleme laufen.
Anzeige
In dem Zusammenhang eine Frage: Remote-Desktop Preauthentication… Ist das wirklich eine gute Idee? Früher war es so, dass man per DRP direkt auf dem Zielsystem eine Anmeldemaske bekam, wo man sein User/Pass eingibt. Die Anmelede-Infos blieben "lokal" auf dem Zielserver. Heute macht man das in der Regel in einer Anmeldemaske auf dem Quellsystem, was dann User/Hash auf das Zielsystem überträgt, eben Preauthentifiziuerung, und die Anmeldeaten bleiben lokal im Cache. Vor 1 Monat hatten wir eine Firma beauftragt, bei uns einen internen Pentest durchzuführen. Ging insgesamt ganz gut aus, aber die kamen trotzdem "rein", über ein veraltetes (vergessenes/unbekanntes) Opensource-Tool, das innerhalb eines Treibers/Managementsoftware von HP quasi heimlich mit lief – gut, dazu ist gerade ein Ticket bei HP offen, dass sie das mal aktualisieren – wir haben es schonmal manuell gegen eine neuere Version ersetzt, um diese Lücke zu schließen. Aber auf jeden Fall hatte der Pentester dann Adminrechte auf den Admin-TS wo auch dieses HP-Tool lief und konnte wegen der Pre-Auth meine kleine virtuelle GPO-Test-Domäne und den Zugang dorthin finden und konnte sich dort anmelden, obwohl die nur per RDP-Port erreichbar ist, er fand die Credentials per Mimikatz auf meinem Spungserver… "Protected User" nutzt natürlich bei einem Account aus einer fremden Domain auch nichts. Vergleichbar hätte es eine völlig autarke Minidomäne für Backups oder die ESAE-Domäne des Admin-Tierings sein können. Daher, ist das standardmäßig empfohlene und genutzte Preauth wirklich immer so eine gute Idee?
Die Frage ist, wogegen man sich schützen will. Wenn das Quellsystem gehackt ist könnte ein Angreifer die Tastatur-Eingaben, Session-Tokens etc. abgreifen und diese dann für das Login auf anderen Systemen weiterverwenden.
Einem Zielsystem kann man hingegen ein Kerberos-Ticket übergeben, das nur für dieses eine System gültig ist. Dadurch könnte das Zielsystem kompromittiert sein, ohne dass eine reine Anmeldung an dem System zu weiteren Schäden führen würde.
Moin Günter.
Ich hatte dir damals das Problem gemeldet, was zu deinem Blogeintrag mit dem verhunzten Remote Credential Guard führte.
Wie dort zu lesen ist, ist das mittlerweile erledigt: seit April 24 liegen für alle noch unterstützten Client- und Serverversionen Patches vor.
Nun sind in den Kommentaren zu deinem Artikel neue Probleme aufgetaucht; angeblich funktioniert es mit der Win11 24H2 erneut nicht (diese ist aber auch noch nicht von MS freigegeben). Was sollte man also tun? Als Insider diese Probleme nachstellen und melden, dann den Meldeeintrag hier verlinken und von allen upvoten lassen, die das nachstellen können – dann wird's mit etwas Glück auch rechtzeitig vorm Erscheinen von 24H2 seitens MS gefixt.
Doch was kommt stattdessen? Sehr viel von Mark, was nur bedingt dazu passt. Auch ist hier zu lesen, dass RCG ein Enterprise-Feature ist – falsch. In den selbsthier verlinkten MS Dokus steht explizit drin, dass es auf Pro funktioniert. Auch zitierst Du Mark, dass Credential Guard und Remote Credential Guard das "gleiche Werkzeug für eine andere Verbindung" sein sollen. Ist das so? Das eine (CG) setzt aktive Virtualization-based security (VBS) voraus, das andere (RCG) nicht. Das eine (RCG) funktioniert überall (hardwareunabhängig), das andere hat zwingenden Anforderungen an Hardware und Firmware! Was haben also die beiden noch technisch gemein, außer dem ähnlichen Namen und dem Endresultat (=Schutz der Credentials)? Ich würde beide hier gar nicht vermischen, die Probleme sind unterschiedlicher Natur.
Mea culpa. Das Fehlerbild letzten Sommer war extrem unklar, da zu viele Baustellen beteiligt waren.
Ich habe den RCG tatsächlich aufgrund der Namensgleichheit in die CG Ecke als Enterprise Feature gestellt und gedacht die Credentials werden in dem isolierten Datenspeicher der LSA verpackt, wie beim CG. Da habe ich die Supported OS Tabelle gar nicht mehr angeschaut.
Danke schön!
Kleiner Nachtrag:
Ich habe soeben Win11 24H2 26100.1297 auf einem Testgerät (Credential Guard inaktiv) installiert als Upgrade von 23H2, wo der RCG-Fehler ja behoben war. -> Fehler wieder da! Toll. Here we go again. Mal sehen, was andere sagen… ich habe es hier angemerkt: https://learn.microsoft.com/en-us/answers/questions/1294080/windows-11-22h2-remote-credential-guard-(rcg)-hop?page=1&orderby=Helpful&comment=answer-1262167#newest-answer-comment sowie wo's eigentlich hingehört, da nicht CG-related: https://learn.microsoft.com/en-us/answers/questions/1295736/with-remote-credential-guard-active-there-are-auth?page=1&orderby=Helpful&comment=answer-1263753#newest-answer-comment
Stephan hatte mir noch per E-Mail folgendes geschrieben: "Bitte fragen Sie Ihren Kollegen bezüglich des Credential Guard Problems in Verbindung mit NAC, ob das konfigurierte Wired Profil korrekt eingestellt ist. Wir hatten auch den Credential Guard erst deaktiviert, Ursache war aber eine falsche NAC Config, wo entsprechendes root Zertifikat nicht mitgegeben wurde. "