Offline Cache Credentials mit Smartcard unter Windows 11 24H2

Mittlerweile häufen sich die Probleme bei der Anmeldung mittels Smartcard (bspw. eines Yubikeys) und einer fehlenden Line-of-Sight zu einem Domain Controller. So wird dem Benutzer die Fehlermeldung „Die angegebene Domäne steht nicht zur Verfügung“ präsentiert, sobald er sich mit einer Smartcard am Client authentifizieren möchte. Dieses Problem dürfte aber erst seit kurzem auftreten. Warum das so ist, schauen wir uns in diesem Artikel näher an.

Smartcard Authentifizierung

Grundlagen

Bevor wir zum eigentlichen Problem vorstoßen, sollten wir uns kurz anschauen, wie die Smartcard Authentifizierung überhaupt funktioniert. Das soll jetzt kein technischer Deep Dive werden, sondern den Authentifizierungsflow nur oberflächlich beschreiben.

Bei der Smartcard-Authentifizierung, wie sie beispielsweise mit einem Yubikey durchgeführt werden kann, kommen asymmetrische Kryptoverfahren zum Einsatz. Auf dem Smartcard-Gerät – in diesem Fall dem Yubikey – ist ein Schlüsselpaar hinterlegt, bestehend aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel verbleibt sicher auf dem Gerät und verlässt dieses nie, während das zugehörige öffentliche Zertifikat in der Regel von einer internen Certificate Authority signiert wurde.

Diese interne CA wird innerhalb der Unternehmensdomäne als vertrauenswürdig eingestuft. Das bedeutet, dass alle Systeme, die zur Domäne gehören (z. B. Domain Controller, Server, Clients), der Gültigkeit der von dieser CA ausgestellten Zertifikate vertrauen.

Wenn sich ein Benutzer mit seiner Smartcard authentifizieren möchte, prüft der Domain Controller bei der Anmeldung das präsentierte Zertifikat. Dabei kontrolliert er:

• ob das Zertifikat gültig ist (z. B. nicht abgelaufen oder widerrufen)

• ob es von einer vertrauenswürdigen CA stammt

• ob es zur Identität des Benutzers passt

Ist das alles der Fall, wird die Authentifizierung als erfolgreich angesehen, und der Benutzer erhält Zugriff entsprechend seiner Berechtigungen.

Ein wichtiger Vorteil dieser Methode ist, dass der private Schlüssel das Gerät niemals verlässt. Selbst wenn ein Angreifer das Zertifikat abgreifen würde, könnte er sich ohne den privaten Schlüssel nicht authentifizieren. Dies macht die Smartcard-Authentifizierung besonders sicher gegenüber vielen gängigen Angriffsvektoren wie zum Beispiel Phishing.

Kerberos

Wie in vielen Fällen bei der Active-Directory-Authentifizierung kommt auch bei der Smartcard-Anmeldung das Kerberos-Protokoll zum Einsatz – allerdings mit einer spezifischen Erweiterung namens Kerberos PKINIT. Die grundlegende Funktionsweise von Kerberos habe ich bereits hier ausführlicher beschrieben. Für diesen Beitrag ist zunächst nur relevant, dass Kerberos grundsätzlich auf eine direkte Kommunikation mit dem Domain Controller angewiesen ist, da sämtliche Authentifizierungs- und Ticket-Prozesse zentral dort abgewickelt werden.

Im Fall der Smartcard wird bei der Initial-Authentifizierung kein symmetrisches Geheimnis (Username und Passwort) verwendet, sondern der Benutzer authentifiziert sich über ein asymmetrisches Schlüsselpaar. Der Client präsentiert dem DC das auf der Smartcard hinterlegte Benutzerzertifikat. Dieses wird durch den Domain Controller anhand der im Active Directory hinterlegten und als vertrauenswürdig eingestuften internen Certificate Authority validiert. Nach erfolgreicher Zertifikatsprüfung wird über den privaten Schlüssel auf der Smartcard eine „kryptographische Challenge“ signiert, womit der Nutzer nachweist, dass er der Besitzer des Schlüssels ist. Erst danach stellt der DC ein Ticket Granting Ticket (TGT) aus, womit der reguläre Kerberos-Ticket-Workflow startet.

Lange Rede, kurzer Sinn – warum erkläre ich das?

Das Problem

Möchte man sich als Nutzer auf seinem Client anmelden und hat keine direkte Line-of-Sight zum Domain Controller, wird die Smartcard Authentifizierung mit folgender Fehlermeldung fehlschlagen.

Komischerweise war das aber nicht immer so. Wir verwenden bereits seit langem Yubikeys zur Authentifizierung und bislang hat es gereicht, wenn sich der User einmalig mit seiner Smartcard im Intranet (mit Line-of-Sight zum DC) authentifiziert hat. Der Client hat dann, wie er es auch beim normalen Passwort-Login vollzieht, die Anmeldedaten im Cache gespeichert. Bei jeder weiteren Anmeldung war es damit möglich, auf diesen Cache zurückzugreifen. Somit war eine direkte Line-of-Sight zu einem Domain Controller nicht mehr notwendig.

Die Analyse

Grundlagen

Nach langem Debugging stellte sich heraus, dass die neuen Windows Versionen – um genau zu sein ab Windows 11 24H2 – dafür verantwortlich sind. Bei 23H2 und älter wurde beim Smartcard Login noch ein entsprechender Registry Eintrag im Cache abgespeichert. Im Grunde wurde dort das gleiche Verhalten getriggert, wie beim Login mittels Username und Passwort.

Standardmäßig werden bis zu 10 solcher Cache-Einträge in der Registry gespeichert – dieser Wert lässt sich bspw. mittels GPO auf bis zu 50 erhöhen oder auf 0 reduzieren (in besonders sicheren Umgebungen). Der Registry Schlüssel dafür lautet „HKLM:\SECURITY\Cache„.

Im folgenden Screenshot sieht man unter dem Eintrag „NL$1“ wie bereits Zugangsdaten (Username/Passwort) im Cache angelegt wurden. Somit wäre es mit diesem Client jetzt möglich, einen Login via Username & Passwort zu vollziehen und zwar ohne Line-of-Sight zu einem Domain Controller.

Melden wir uns nun mittels Smartcard am System an, wird ein weiterer Eintrag erstellt:

Damit wäre nun auch ein Smartcard Login ohne direkter Verbindung zu einem Domain Controller möglich. Das besondere daran ist, dass dieser Eintrag ab Windows 11 24H2 eben nicht mehr erstellt wird. Das gilt aber ausschließlich für den Smartcard Login. Somit haben wir auch die Ursache für unser Problem gefunden.

Triggert man unter Windows 11 24H2 einen Smartcard Login, werden regulär Calls zu den hinterlegten Domain Controllern initiiert.

Da wir uns aber nicht im internen Netz befinden, antwortet dort natürlich nichts.

Noch ein paar weitere Findings dazu: Hat man seine Smartcard das erste Mal auf Windows 11 23H2 (oder älter) eingerichtet und aktualisiert es anschließend auf 24H2, wird der Login weiterhin ohne Line-of-Sight zum DC funktionieren. Der Registry Eintrag ist noch vorhanden und wird vom Client honoriert. Ändert man allerdings sein Passwort im Active Directory, ist der Eintrag nicht mehr valide und durch 24H2 wird er auch nicht mehr aktualisiert – somit ist ab diesen Zeitpunkt der Offline Login mit Smartcards nicht mehr gegeben.

Warum W11 24H2?

Jetzt stellt sich natürlich die Frage, warum das so ist? Was hat sich beim Update von 24H2 geändert? Auch wenn ich längere Zeit nach einer Antwort gesucht habe, kann ich diese Frage leider nur mit einem unbefriedigenden „keine Ahnung“ beantworten.

Es gibt zwar das Gerücht, dass sich ab 24H2 beim Smartcard Login einiges geändert haben soll und es auch sicherer gestaltet wurde, ich finde aber keine offizielle Quelle von Microsoft dazu. So wird auch gemunkelt, dass Windows nun weit aus strenger mit der Revocation Liste umgeht und einen Login ablehnt, wenn diese nicht abrufbar ist. Leider finde ich dazu auch keine offizielle Quelle.

Workaround

Für alle Unternehmen die nicht auf Windows Hello for Business setzen und es auch in Zukunft nicht tun wollen, kann der KDC Proxy Service eine Lösung für das Problem darstellen. Hierbei wird ein Windows Server mit der KDC Proxy Rolle installiert und im Internet zugänglich gemacht. Somit könnten Clients, welche sich nicht im internen Netz befinden, eine direkte Line-of-Sight mit einem Domain Controller über das Internet herstellen.

Wie das funktioniert, beleuchten wir vielleicht in einem zukünftigen Artikel.

Update 20.06.2025

Nach weiterem Testing scheint es aktuell so, dass das oben genannte Verhalten nur bei Smartcards mit ECDH (Elliptic Curve Diffie Hellmann) auftaucht. Wurde das Zertifikat mittels RSA Kryptografie bereitgestellt, wird der Cache Registry-Key regulär und korrekt angelegt. Hiermit scheint es keine Probleme zu geben. Das wirft nur weitere Fragen auf und würde den Verdacht in den Raum stellen, dass es sich hierbei wirklich um einen Bug handelt.