10
Smartcard Login unterläuft SSO bei Windows Defender Remote Credential Guard
Hallo,
ich bin bei der Implementierung vor Windows Defender Remote Credential Guard ein Problem gestoßen.
Folgendes Szenario:
Wenn man auf dem Client mit der Smartcard angemeldet ist, fragt der RDP-Client beim Verbindungsaufbau erneut nach den Credentials. Man gibt also die PIN ein und bestätigt auf dem Yubikey. Die Verbindung wird dann aufgebaut. Soweit so gut.
Man hat allerdings auch die Möglichkeit, im Fenster "Anmeldeinformationen eingeben" das Konto zu wechseln. Also: "Anderes Konto verwenden" und Benutzername/Password eingeben. Das funktioniert auch, die Verbindung wird unter dem anderen Benutzernamen hergestellt.
Also:
Benutzer per Passwort angemeldet -> zwangsweise SSO
Benutzer per Smartcard angemeldet -> keine SSO, Benutzer kann frei ausgewählt werden.
Frage: Könnt Ihr das so bestätigen?
Ist das so gedacht? Laut dem Link oben ja nicht: "Benutzeranmeldeinformationen verbleiben auf dem Client. Ein Angreifer kann nur im Namen des Benutzers handeln, wenn die Sitzung ausgeführt wird."
Grüße
lcer
ich bin bei der Implementierung vor Windows Defender Remote Credential Guard ein Problem gestoßen.
Folgendes Szenario:
- Active Directory
- RDP-Server 2016
- Client mit Windows 10
- Smartcard-Login per Yubikey
Wenn man auf dem Client mit der Smartcard angemeldet ist, fragt der RDP-Client beim Verbindungsaufbau erneut nach den Credentials. Man gibt also die PIN ein und bestätigt auf dem Yubikey. Die Verbindung wird dann aufgebaut. Soweit so gut.
Man hat allerdings auch die Möglichkeit, im Fenster "Anmeldeinformationen eingeben" das Konto zu wechseln. Also: "Anderes Konto verwenden" und Benutzername/Password eingeben. Das funktioniert auch, die Verbindung wird unter dem anderen Benutzernamen hergestellt.
Also:
Benutzer per Passwort angemeldet -> zwangsweise SSO
Benutzer per Smartcard angemeldet -> keine SSO, Benutzer kann frei ausgewählt werden.
Frage: Könnt Ihr das so bestätigen?
Ist das so gedacht? Laut dem Link oben ja nicht: "Benutzeranmeldeinformationen verbleiben auf dem Client. Ein Angreifer kann nur im Namen des Benutzers handeln, wenn die Sitzung ausgeführt wird."
Grüße
lcer
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5476484541
Url: https://administrator.de/forum/smartcard-login-unterlaeuft-sso-bei-windows-defender-remote-credential-guard-5476484541.html
Ausgedruckt am: 13.03.2025 um 21:03 Uhr
10 Kommentare
Neuester Kommentar
Moin.
Bei uns funktioniert das sowohl mit Yubikey 5 (ohne Touchzwang) als auch mit anderen Smartcards.
Fragen:
Ist das Verhalten ohne die Touchpolicy anders?
Ist das Verhalten anders, wenn das Ziel ein höheres OS ist als 2016?
Ist am 2016er Network level authentication für rdp an? Mach's mal an, wenn nicht.
Bei uns funktioniert das sowohl mit Yubikey 5 (ohne Touchzwang) als auch mit anderen Smartcards.
Fragen:
Ist das Verhalten ohne die Touchpolicy anders?
Ist das Verhalten anders, wenn das Ziel ein höheres OS ist als 2016?
Ist am 2016er Network level authentication für rdp an? Mach's mal an, wenn nicht.
Wenn man auf dem Client mit der Smartcard angemeldet ist, fragt der RDP-Client beim Verbindungsaufbau erneut nach den Credentials
Sollte er nicht tun. Darf er nicht, denn Remote Credential Guard schreibt ja vor, dass die eigenen Credentials durchgereicht werden. Im RDP-Client MUSS das Feld Nutzername unveränderlich sein (ausgefüllt und ausgegraut).
Zitat von @DerWoWusste:
Moin.
Bei uns funktioniert das sowohl mit Yubikey 5 (ohne Touchzwang) als auch mit anderen Smartcards.
Fragen:
Ist das Verhalten ohne die Touchpolicy anders?
Ist das Verhalten anders, wenn das Ziel ein höheres OS ist als 2016?
Ist am 2016er Network level authentication für rdp an? Mach's mal an, wenn nicht.
Moin.
Bei uns funktioniert das sowohl mit Yubikey 5 (ohne Touchzwang) als auch mit anderen Smartcards.
Fragen:
Ist das Verhalten ohne die Touchpolicy anders?
Ist das Verhalten anders, wenn das Ziel ein höheres OS ist als 2016?
Ist am 2016er Network level authentication für rdp an? Mach's mal an, wenn nicht.
Wenn man auf dem Client mit der Smartcard angemeldet ist, fragt der RDP-Client beim Verbindungsaufbau erneut nach den Credentials
Sollte er nicht tun. Darf er nicht, denn Remote Credential Guard schreibt ja vor, dass die eigenen Credentials durchgereicht werden. Im RDP-Client MUSS das Feld Nutzername unveränderlich sein (ausgefüllt und ausgegraut).Wie ist das, wenn Du den Yubikey rausziehst und dann RDP öffnest? Bei mir kommt dann eine Credential-Nachfrage, in die ich eingeben kann, was immer ich möchte. Die Verbindung wird hersgestellt.
Ich suche mal in den Logs, ob man feststellen kann, ob Remote-Credential-Guard verwendet für die RDP-Sitzung verwendet wurde.
Grüße
lcer
Wie gesagt: du darfst da zu keinem Zeitpunkt etwas eingeben können. Ist die SmartCard gezogen, wird dennoch der Nutzername ausgegraut eingetragen.
Prüfe bitte, ob Credential Guard die einzige aktive Credential Delegation policy ist und schaut ob die zugehörigen Registrywerte auch unter hklm\software\policies\microsoft\credential Delegation eingetragen wurden.
Prüfe bitte, ob Credential Guard die einzige aktive Credential Delegation policy ist und schaut ob die zugehörigen Registrywerte auch unter hklm\software\policies\microsoft\credential Delegation eingetragen wurden.
Hier nochmal die Regpfade zu prüfen: https://admx.help/HKLM/Software/Policies/Microsoft/Windows/CredentialsDe ...
Hallo,
ich glaube, das Problem gefunden zu haben.
Allerdings:
fehlteaurf dem Host. Ich hatte gedacht, die GPO genügt. Wobei ich das schon seltsam finde, dass man GPO und Registry-Eintrag benötigt.
Der Server ist übrigens 2019. Vertippt.
Ich werde das nach dem Serverneustart noch mal testen.
Grüße
lcer
ich glaube, das Problem gefunden zu haben.
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation]
"RestrictedRemoteAdministration"=dword:00000001
"RestrictedRemoteAdministrationType"=dword:00000002
"AllowProtectedCreds"=dword:00000001 reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORDDer Server ist übrigens 2019. Vertippt.
Ich werde das nach dem Serverneustart noch mal testen.
Grüße
lcer
Dazu muss der Server nicht neu starten.
Hallo,
Na dann hat es das Problem nicht behoben.
Weisst Du, wo man im Erreignisprotokoll findet, ober Remote Credential Guard verwendet worde? In https://learn.microsoft.com/en-us/windows/security/threat-protection/aud ... wird nur RestrictedAdminMode erwähnt.
Grüße
lcer
Na dann hat es das Problem nicht behoben.
Weisst Du, wo man im Erreignisprotokoll findet, ober Remote Credential Guard verwendet worde? In https://learn.microsoft.com/en-us/windows/security/threat-protection/aud ... wird nur RestrictedAdminMode erwähnt.
Grüße
lcer
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation]
"RestrictedRemoteAdministration"=dword:00000001
"RestrictedRemoteAdministrationType"=dword:00000002
Diese beiden sind am Client gesetzt? Und wenn du nun mstsc startest, ist der Nutzername nicht vorbefüllt und ausgegraut?"RestrictedRemoteAdministration"=dword:00000001
"RestrictedRemoteAdministrationType"=dword:00000002
Weisst Du, wo man im Erreignisprotokoll finde...
Nein. Ich würde am Server den Virenscanner deaktivieren und dann mittels mimikatz schauen, was dort lesbar ist.
Hallo,
habs gefunden:
Man muss also Remote Credential Guard auf dem Client (per GPO) und auf dem Server (per Registrierungsschlüssel) aktivieren. Ich verstehe dann zwar nicht, warum der Host ein Fallback auf nicht-Remote-Credential-Guard akzeptiert hat, aber was egal.
Das man keine Eventlogeinträge findet, kann doch eigentlich nicht sein ....
Grüße
lcer
habs gefunden:
Zitat von @DerWoWusste:
Das war das Problem. Ursache war, dass die GPO nicht auf alle Computer wirkte. Auf einigen hatte es funktioniert, auf anderen nicht. Dummerweise hatte es gerade da, wo ich die Smartcard verwende nicht gegriffen.[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation]
"RestrictedRemoteAdministration"=dword:00000001
"RestrictedRemoteAdministrationType"=dword:00000002
Diese beiden sind am Client gesetzt? Und wenn du nun mstsc startest, ist der Nutzername nicht vorbefüllt und ausgegraut?"RestrictedRemoteAdministration"=dword:00000001
"RestrictedRemoteAdministrationType"=dword:00000002
Man muss also Remote Credential Guard auf dem Client (per GPO) und auf dem Server (per Registrierungsschlüssel) aktivieren. Ich verstehe dann zwar nicht, warum der Host ein Fallback auf nicht-Remote-Credential-Guard akzeptiert hat, aber was egal.
Das man keine Eventlogeinträge findet, kann doch eigentlich nicht sein ....
Grüße
lcer
Das man keine Eventlogeinträge findet, kann doch eigentlich nicht sein ....
Doch, bei MS kann alles sein. Nimm Mimikatz zur Hand, damit hast Du in einer Minute nachgewiesen, dass keine verwertbaren Credentials auf dem Ziel ankommen.
1
