16
RDP-Authentifizierung mit SmartCard leider doppelt
Guten Morgen.
Unser SmartCard Deployment biegt auf die Zielgerade ein.
Eine noch zu klärende Merkwürdigkeit ist die, dass ich bei RDP-Verbindungen von Win10 aus (Ziel-OS ist egal, Win10/Server2012/2016/2019) immer zweimal die PIN eingeben muss: einmal an der Anmeldemaske des Remote-PCs und zuvor schon einmal lokal in einem so gearteten Dialog:
Dies tritt bei allen SmartCardtypen außer Yubikeys auf - bei Yubikeys kommen auch zwei Authentifizierungen, aber die erste kann man überspringen, indem man einfach PIN leer lässt und Enter drückt. Es ist hierbei egal, ob die Eingabe über Tastatur oder über externe Pin-Pads erfolgt.
Kennt das jemand?
Warum wird zweimal gefragt, wenn SC verwendet wird und nur einmal, wenn ein Kennwort verwendet wird?
Warum nimmt der Yubikey eine Sonderrolle ein?
Unser SmartCard Deployment biegt auf die Zielgerade ein.
Eine noch zu klärende Merkwürdigkeit ist die, dass ich bei RDP-Verbindungen von Win10 aus (Ziel-OS ist egal, Win10/Server2012/2016/2019) immer zweimal die PIN eingeben muss: einmal an der Anmeldemaske des Remote-PCs und zuvor schon einmal lokal in einem so gearteten Dialog:
Dies tritt bei allen SmartCardtypen außer Yubikeys auf - bei Yubikeys kommen auch zwei Authentifizierungen, aber die erste kann man überspringen, indem man einfach PIN leer lässt und Enter drückt. Es ist hierbei egal, ob die Eingabe über Tastatur oder über externe Pin-Pads erfolgt.
Kennt das jemand?
Warum wird zweimal gefragt, wenn SC verwendet wird und nur einmal, wenn ein Kennwort verwendet wird?
Warum nimmt der Yubikey eine Sonderrolle ein?
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: 1185642154
Url: https://administrator.de/forum/rdp-authentifizierung-mit-smartcard-leider-doppelt-1185642154.html
Ausgedruckt am: 01.04.2025 um 19:04 Uhr
16 Kommentare
Neuester Kommentar
Hi,
das liegt höchstwahrscheinlich am NLA, d.h. der erste Prompt initialisiert das kerberos Serviceticket fürs termsv NLA, der zweite authentifiziert dich in der RDP Session.
teste mal folgendes: boote den client neu (damit man frisch anfängt)
führe klist aus
da sollte das krbtgt ticket sein und ggf. ein paar andere, aber noch keins mit "termsrv"
mach nun deine rdp session und dannach wieder klist, jetzt sollte ein ticket mit "termsrv @ <servername> da sein.
Solange dieses Ticket gültig ist, solltest du nur noch einmal nach dem PIN gepromted werden (bei verbindung zum selben ziel)
Hier eine Tabelle:
https://community.rsa.com/t5/securid-access-knowledge-base/how-does-remo ...
--> man könnte dieses verhalten umgehen indem man NLA auf den Clients deaktiviert
MFG
N-Dude
das liegt höchstwahrscheinlich am NLA, d.h. der erste Prompt initialisiert das kerberos Serviceticket fürs termsv NLA, der zweite authentifiziert dich in der RDP Session.
teste mal folgendes: boote den client neu (damit man frisch anfängt)
führe klist aus
klistmach nun deine rdp session und dannach wieder klist, jetzt sollte ein ticket mit "termsrv @ <servername> da sein.
Solange dieses Ticket gültig ist, solltest du nur noch einmal nach dem PIN gepromted werden (bei verbindung zum selben ziel)
Hier eine Tabelle:
https://community.rsa.com/t5/securid-access-knowledge-base/how-does-remo ...
--> man könnte dieses verhalten umgehen indem man NLA auf den Clients deaktiviert
MFG
N-Dude
1
Hi.
Zum einen passiert es wie gesagt nur bei SmartCards, nicht bei Kennwörtern, zum anderen ist NLA testhalber schon längst abgeschaltet worden auf Serverseite und Clientseite - ohne Effekt.
Aber sehr interessant ist, dass die Tabelle wiedergibt, dass diese Doppelabfrage nur kommen müsste, wenn NLA auf beiden Seiten an ist - zumindest gibt es also eine Konstellation, wo dies Verhalten zu erwarten wäre.
Sieht also nach einem Bug in Verbindung mit NLA aus, so als wäre es nicht abschaltbar.
Zum einen passiert es wie gesagt nur bei SmartCards, nicht bei Kennwörtern, zum anderen ist NLA testhalber schon längst abgeschaltet worden auf Serverseite und Clientseite - ohne Effekt.
Aber sehr interessant ist, dass die Tabelle wiedergibt, dass diese Doppelabfrage nur kommen müsste, wenn NLA auf beiden Seiten an ist - zumindest gibt es also eine Konstellation, wo dies Verhalten zu erwarten wäre.
Sieht also nach einem Bug in Verbindung mit NLA aus, so als wäre es nicht abschaltbar.
Hallo,
also ich habe RDP immer mit NLA konfiguriert und kenne das Verhalten so gar nicht (seit Windows 7/2008R2 mit Smartcards unterwegs). Was sind denn deine RDP-Policies?
Grüße
Richard
also ich habe RDP immer mit NLA konfiguriert und kenne das Verhalten so gar nicht (seit Windows 7/2008R2 mit Smartcards unterwegs). Was sind denn deine RDP-Policies?
Grüße
Richard
Hi Richard.
Frag mich nicht, was da alles reinspielt.
Interessant wäre "wie sind deine Policies" da es ja bei Dir geht.
Ich teste heute Abend in meiner Testdomäne weiter.
Frag mich nicht, was da alles reinspielt.
Interessant wäre "wie sind deine Policies" da es ja bei Dir geht.
Ich teste heute Abend in meiner Testdomäne weiter.
Habe jetzt Tests doch schon ausgeführt und konnte unter keiner Konstellation hinbekommen, dass nur einmal gefragt wird.
Welche OS' hast Du, Richard?Versuch das bitte mal mit einem Konto, bei dem SmartCard-Authentifizierung vorgeschrieben ist, um sicher zu gehen, dass keine zwischengespeicherten Kennwort-Credentials wirken können.
Welche OS' hast Du, Richard?Versuch das bitte mal mit einem Konto, bei dem SmartCard-Authentifizierung vorgeschrieben ist, um sicher zu gehen, dass keine zwischengespeicherten Kennwort-Credentials wirken können.
21H1 und 2019. Smartcard wird bei den Nutzern generell erzwungen.
O-K.... das ist interessant.
Wie sind nun deine Einstellungen, die Du für verantwortlich hältst?
Da ich hier alle Credential-Delegation-Einstellungen getestet habe mit und ohne NLA, komme ich ohne diesen Tipp nicht weiter.
Wie sind nun deine Einstellungen, die Du für verantwortlich hältst?
Da ich hier alle Credential-Delegation-Einstellungen getestet habe mit und ohne NLA, komme ich ohne diesen Tipp nicht weiter.
Hi,
habe es versucht nachzustellen, hier wird trotz NLA auf Client und Server nur einmal gefragt, und zwar im ersten Dialog (den den du gescreenshottet hast) - mit einem Yubikey
habe es versucht nachzustellen, hier wird trotz NLA auf Client und Server nur einmal gefragt, und zwar im ersten Dialog (den den du gescreenshottet hast) - mit einem Yubikey
Danke für's Nachstellen.
Schon witzig. Ich nutze hier default settings (alle GPOs entfernt auf den Testsystemen) und es geht nur doppelt.
Habt Ihr denn Einstellungen vor Augen, die bei Euch gesetzt sein könnten?
Schon witzig. Ich nutze hier default settings (alle GPOs entfernt auf den Testsystemen) und es geht nur doppelt.
Habt Ihr denn Einstellungen vor Augen, die bei Euch gesetzt sein könnten?
Hast du Remote Credential Guard aktiviert (ohne GPO ggf. noch als Reg-Key auf dem Host)?
Nee, ist nicht aktiv. Der war eh nur auf sehr wenigen Rechnern jemals im Einsatz (und das Phänomen tritt überall auf).
Mit Standardeinstellungen muss es auf jeden Fall auch gehen:
Ansonsten, sind auch auf dem Remote-Rechner der Treiber installiert und der Device-Node da? Welche PIN-Policy hat der YubiKey?
Ansonsten, sind auch auf dem Remote-Rechner der Treiber installiert und der Device-Node da? Welche PIN-Policy hat der YubiKey?
1Mit Standardeinstellungen muss es auf jeden Fall auch gehen:
Nee, hier leider nicht.Treiber sind remote installiert, device node ist da. Pin-Policy egal, mit default Einstellungen (Key resettet, nur ein Zert drauf) ist es genau so, ebenso mit allen anderen SmartCards (Gemalto ID Prime, virtuelle SmartCards, CardOS SmartCards).
Sieht man im Security Eventlog des Clients oder des Servers um den Loginzeitraum irgendwas auffälliges?
Hat die CA eine CRL Konfiguriert? Ggf. prüft das Ziel den Cert vom Token gegen die Liste - und die Antwort bleibt aus oder kommt nicht "rechtzeitig" an?
Hat die CA eine CRL Konfiguriert? Ggf. prüft das Ziel den Cert vom Token gegen die Liste - und die Antwort bleibt aus oder kommt nicht "rechtzeitig" an?
In meiner Testdomäne zu Hause ist alles paletti und es läuft mit einer Anmeldung auch mit NLA.
Sieht man im Security Eventlog des Clients oder des Servers um den Loginzeitraum irgendwas auffälliges?
Ich grabe mal ein wenig. Ich werde den Unterschied schon noch finden.Hat die CA eine CRL Konfiguriert?
Ja, und die ist auch erreichbar.
Ahh, es ist gelöst 
Eine fiese, miese Inkompatibilität war die Ursache:
Wir nutzen Anixis Password Policy Enforcer, und der hat in v8 bis v9.12 (die derzeit aktuellste) die Probleme verursacht.
Deinstalliere ich ihn, verschwindet das Problem sofort.
Da sich diese Software zu Zwecken des Kennwortwechsels in die Anmeldemaske einklinkt (es wird eine dll geladen über einen Bereich unterhalb von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers), kann ich mir auch vorstellen, dass das nicht immer kompatibel ist. Da Hersteller der Software wohl keine SmartCards einsetzen (sie verkaufen ja Software zur strengeren Reglementierung von Kennwörtern), fällt denen das natürlich auch nicht auf!
Puh, die Sorge bin ich los.
Ihr habt mir gut geholfen, dahin zu finden
DANKE
Eine fiese, miese Inkompatibilität war die Ursache:
Wir nutzen Anixis Password Policy Enforcer, und der hat in v8 bis v9.12 (die derzeit aktuellste) die Probleme verursacht.
Deinstalliere ich ihn, verschwindet das Problem sofort.
Da sich diese Software zu Zwecken des Kennwortwechsels in die Anmeldemaske einklinkt (es wird eine dll geladen über einen Bereich unterhalb von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers), kann ich mir auch vorstellen, dass das nicht immer kompatibel ist. Da Hersteller der Software wohl keine SmartCards einsetzen (sie verkaufen ja Software zur strengeren Reglementierung von Kennwörtern), fällt denen das natürlich auch nicht auf!
Puh, die Sorge bin ich los.
Ihr habt mir gut geholfen, dahin zu finden
DANKE
