SmartCard-Logon with YubiKey 5 NFC
kostenfreie Webinare zu dem Thema
Aktuell bieten wir zwei kostenfreie Webinare zu dem Thema an. Bei Interesse bitte hier klicken und sich anmelden.
Eine Authentifizierung, egal ob im Web, in der Cloud oder On-Premises, mittels Benutzername (E-Mail-Adresse) und Kennwort zählt nicht mehr zu den sicheren Varianten.
Die Kombination aus Benutzername (bzw. E-Mail-Adresse) und Kennwort war vor 15 Jahren ggf. noch adäquat, jedoch heute ganz sicher nicht mehr.
2. Faktor
Warum nicht also mehr auf einen zweiten Faktor im Bereich der Authentifizierung setzen; kurzes Zitat aus der Wikipedia hierzu:
Die Zwei-Faktor-Authentisierung (2FA), häufig auch Zwei-Faktor-Authentifizierung genannt, bezeichnet den Identitätsnachweis eines Nutzers mittels einer Kombination zweier unterschiedlicher und insbesondere voneinander unabhängiger Komponenten (Faktoren). Typische Beispiele sind Bankkarte und PIN beim Geldautomaten, Fingerabdruck und Zugangscode in Gebäuden, oder Passphrase und Transaktionsnummer (TAN) beim Online-Banking. Die Zwei-Faktor-Authentisierung ist ein Spezialfall der Multi-Faktor-Authentisierung.
2. Faktor: SmartCard
Microsoft unterstützt die Zwei-Faktor-Authentifizierung seit dem Jahr 2006 durch PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). Die letzte Änderung am PKINIT war, nach aktuellem Stand, am 23.04.2024.
PKINIT bedeutet, kurz umrissen, dass zur Anmeldung, anstelle des Benutzernamens + Passwortes, Zertifikate verwendet werden können. Die erste Implementierung war für Benutzerkonten realisiert worden, wobei im Dokument schon von Anfang an auch die Computerkonten miteinbezogen wurden.
Also verwende ich anstelle meines Kennwortes bei der Anmeldung meinen Private-Key um mich zu legitimieren. Der Private-Key wird dabei aber nicht über das Netzwerk übertragen, sondern signiert die Anmeldedaten.
Dieses signierten Anmeldedaten bestehen aus dem öffentlicher Schlüssel des Users, welcher mit dem privaten Schlüssel des Users digital signiert ist. Dieses ist im Kerberos-Protokoll die „Pre-Authentication“.
Die Gegenseite, der Domain Controller, muss nun im Active Directory das Benutzerobjekt lokalisieren. Dieses erfolgt in der Regel über den UserPrincipalName aus der Subject des Zertifikats. Sofern das Benutzerkonto lokalisiert wurde, kann der öffentliche Schlüssel des Benutzers herangezogen werden um die Signatur zu prüfen.
Nachzulesen wäre dieses hier.
Die Domain Controller benötigen hierzu noch ein eigenes Zertifikat um die Authentifizierung via PKINIT durchzuführen: Kerbeos Authentication (weiter unten, sehen wir gleich, warum).
Vorteil?
Was wäre denn nun der Vorteil im Gegensatz zu „Benutzername + Kennwort“
- Bindung an ein physisches Gerät (etwas was ich habe)
- gekoppelt an die PIN dazu (etwas was ich weiß)
- Passwordless – keine Kennwörter mehr in Benutzung
- die Pre-Authentication bei Kerberos hat keine Schwachstelle mehr.
Voraussetzungen für SmartCard-Logon
Es gibt ein paar Voraussetzungen, welche erfüllt sein müssen, um den SmartCard-Logon im On-Premises-AD durchzuführen:
- Idealerweise eine zweistufige On-Premises PKI auf Microsoftbasis (sehen wir im Teil 2, warum).
- Alle Domain Controller benötigen Zertifikate mit der Application Policy „Smart Card Logon“
- einen Enrollment-Agent
- physikalische Smart Cards (z. B. die Yubico YubiKey 5 NFC)
- Smart Card-Treiber-Software (z. B. den YubiKey Minidriver für 64-Bit Systeme unter Windows)
PKI-Struktur
Eine eigene, zweistufige auf Microsofttechnik basierende PKI bietet hier mehrere Vorteile:
- Integrativ für das bestehende Active Directory
- Scalierfähig durch die zwei Stufen
- Nahezu kostenfreier Betrieb im Vergleich zu kommenziellen Zertifikaten oder Managed PKI
- Verfügt über die Fähigkeit von Authentication Mechanism Assurance (AMA) im Rahnen von Issuance-Policies
- Unterstützt Auto-enrollment für Zertifikate
Was mir an dem Design der PKI nicht gefällt, ist die zwingende Notwendigkeit, dass Geräte fast immer mit der Issuing-CA via RPC (Remote Procedure Call) kommunizieren müssen. Die Issuing-CA ist ein Tier0-System und solche Systeme versuche ich immer von den Clients zu trennen.
Certificate Templates
In dieser CA-Struktur mit einer Offline-RootCA und einer Online-IssuingCA müssen drei Zertifikatsvorlagen konfiguriert werden, damit Smart Card Logon funktioniert:
- Kerberos Authentication: für die Domain Controller – eine Untermenge von dieser Vorlage ist Smart Card Logon für den DC
- Enrollment Agent: für die ausstellende Person von Zertifikaten – dieses Vorlage ermöglicht es im Namen von Dritten Zertifikate zu beantragen
- Smart Card Logon: über dieses Zertifikat kann die Authentifzierung zertifikatsbasierend erfolgen.
Alle drei Vorlagen werden auf der IssuingCA konfiguriert und veröffentlicht.
V4.KerberosAuthentication – für die Domain Controller
V4.EnrollmentAgent – für den Enrollment Agent
(wäre hätte das gedacht?)
V4.SmartCardLogon – für den Smart Card Logon
(ich wiederhole mich hier nicht…)
Veröffentlichen der Zertifikate im Active Directory
Auto enrollment Policy für die Domain Controller
Zunächst benötigen die Domain Controller das Zertifikat V4.KerberosAuthentication. Das weise ich aber nicht manuell zu, sondern stelle in der „Default Domain Controllers“-Policy ein, dass die DCs ein auto-enrollment durchführen.
Nach spätestens fünf Minuten holen sich die, hier drei, DCs je ein Zertifikat. Das Erneuern bei zeitlichem Ablauf eines Zertifikats oder nach Erneuerung der Zertifikatsvorlage passiert auch vollautomatisch.
Enrollment Agent – Zertifikat hierzu beantragen
Damit nun nicht jeder User selber ein Smart Card Logon-Zertifikat beantragen muss und/oder soll, wird hier ein „Enrollment Agent“ eingesetzt. Der „Enrollment Agent“ hat die Möglichkeit, Zertifikate im Namen Dritter zu benantragen.
Der Prozess sieht dann so aus, dass die natürliche Person, welche mit dem AD-User Enrollment Agent konnotiert ist, über ein eigenes Zertifkat (Enrollment Agent) die Legitimation erfährt, für Dritte bestimmte Zertifikate auszustellen und diese auf die jeweiligen physischen Tokens speichert.
Das Zertifikat, welches hierzu beantragt wird, ist nicht geeignet um sich anzumelden. Dieses Zertifikat ist die Legitimierung andere Zertifikate zu beantragen. Daher kann dieses Zertifikat, meiner Meinung nach, auch auf einem Rechner gespeichert sein. Natürlich ist dieser Rechner als höchst sensibles Gerät zu betrachten und dementsprechend abzusichern (Bitlocker, CredentialGuard und dergleichen).
Diese bedauerliche natürliche Person muss den ganzen Tag Yubico YubiKeys auspacken, die Seriennummern erfassen, physisch in den USB-A oder USB-C (YubiKey 5C NFC kann auch USB-C) stecken, Zertifikate beantragen, die jeweilige PIN festlegen, den Kram in einen sicheren Umschlag packen und schlussendlich dem User zukommen lassen.
…hättest Du was gescheites gelernt…
Enrollment Agent – Beantragen der Smart Card Logon-Zertifikate
Bevor der Enrollment Agent auf die physikalischen Smart Cards (hier Yubico YubiKey 5 NFC) schreiben kann, muss der Treiber für das Gerät installiert sein und noch ein kleines Verwaltungstool, um später die PIN festzulegen und um, je nach Notwendigkeit, Funktionen der physischen Smart Card zu deaktivieren.
YubiKey Minidriver
Der Minidriver ist die notwendige Implementierung im Windows, damit der YubiKey als Smart Card erkannt wird. Eine Suche im Internet nach „Yubikey“ und „Minidriver“ sollte in jedem Fall gute Resultate liefern, ich mag hier nicht auf eine URL verweisen, die am Schluss zu einem HTTP 404 führt.
Bei der Installation des Minidrivers sind ein paar Punkte zu beachten:
- Für die Anmeldung am lokalen Rechner muss der minidriver installiert sein.
- Wenn man sich per RDP und SmartCard auf einem System Anmelden will, muss auf dem Zielsystem der minidriver installiert sein und die mstsc.exe muss die Smart Card weiterreichen (das ist aber der Standard).
- Wenn man sich per RDP und Smart Card auf einem System Anmelden will, so muss der Treiber mit der Syntax „INSTALL_LEGACY_NODE=1″ installiert werden
- Wenn man den minidriver grundsätzlich mit „INSTALL_LEGACY_NODE=1″ installiert, ist es nicht verkehrt.
YubiKey Manager
Der YubiKey Manager ist ein Verwaltungstool für die YubiKeys. Hier gilt das gleiche wie oben: bitte nach „YubiKey“ und „Manager“ suchen.
Beantragen der Smart Card Logon-Zertfikate
Der Enrollment Agent kann nun, mittels dem minisdriver und dem YubiKey Manager, einen YubiKey 5 NFC mit einem Smart Card Logon-Zertifikat bestücken. Zu Anfangs solle der YubiKey richtig herum (bei USB-A kann man den Key auch verkehrt herum) einstecken. Über den Gerätemanager von Windows und den YubiKey Manager kann geprüft werden, ob der Key funktioniert.
Im Bereich von „Interfaces“ im YubiKey Manager kann alles deaktiviert werden, was man nicht kennt, möchte, benötigt oder mag.
Lediglich PIV (Personal Identity Verification) muss angehakt bleiben, selbst wenn man es nicht kennt, möchte oder mag, denn es wird benötigt.
Suddenly: certificates!
Jetzt ist es soweit: der Enrollment Agent kann über das Tool certmgr.msc in Verbindung mit eingestecktem YubiKey (Default PIN: 123456) für den User mhandl@CLOUD-HYBRID.DE das Smart Card Logon-Zertifikat beantragen.
Der Enrollment Agent braucht dazu nicht das Kennwort von mhandl@CLOUD-HYBRID.DE, muss nicht die certmgr.msc im Namen von mhandl@CLOUD-HYBRID.DE öffnen und muss mhandl@CLOUD-HYBRID.DE auch nicht bitten sich am Rechner anzumelden.
Es wird ein „enroll on behalf of“ durchgeführt.
„Enroll on behalf of“ bedeutet, dass während der Prozedur des Beantragens der Enrollment Agents diesen Antrag durch sein Zertifikat rechtfertigen muss („Select Enroll Agent Certificate“). Dieses Zertifikat liegt auf dem lokalen Rechner des Enrollment Agents. Danach wird die Vorlage gewählt (V4.SmartCardLogon) und für den User mhandl@CLOUD-HYBRID.DE / CH\mhandl beantragt.
Das Tool certmgr.msc hat hier ein bisschen an Opas Hustensaft genuckelt: der Auswahl-Dialog für den User, welcher mit einem Zertifikat beglückt werden soll, liegt immer auf der lokalen Maschine. Das ist halt so und kann ich nicht erklären, ohne selbst an Opas Hustensaft zu naschen.
Yikes! Smart Card Logon!
Der User mhandl@CLOUD-HYBRID.DE hat nun den Umschlag mit „dem Stecker“ und „dem Code“ in Empfang genommen. Die Kurzanleitung wird nicht gelesen. Es wird sofort im laufenden Betrieb der YubiKey in den USB-A-Port gepfriemelt und mit Freude festgestellt, es ist egal wie herum, der geht immer „rein“.
Testhalber mal den Rechner gesperrt (zu- und aufgeklappt, recht laut, das knallt immer so lustig und die Frau Meier bekommt einen Schreck) und trotzdem brauche ich noch mein Kennwort.
Das ganze Smart Card-Zeug ist des Teufels, wurde von den Echsenmenschen auf die Erde gebracht und durch die Illuminaten verbreitet!
Ganz ruhig durchatmen.
Und wie melde ich mich jetzt an?
Der Anmeldedialog zeigt jetzt die Sign-in-Options (siehe Kurzanleitung unter der Kaffeetasse, damit der Schreibtisch nicht schmutzig wird). Wenn man dort auf die Smart Card klickt (ja, das „Pizza-Symbol“) muss man nur noch seine PIN (ja, den „Code“) eingeben und schon wird man angemeldet.
Smart Card Removal Policy
Q: Was passiert eigentlich, wenn ich die Smart Card im Betrieb rausziehe?
A: Erst mal gar nichts.
Möchte man eine Aktion (Sperren, Abmelden etc.) provozieren, sofern die Smart Card abgezogen wird, so muss man eine Smart Card Removal Policy erstellen.
Die Smart Card Removal Policy besteht aus zwei Inhalten:
- der Dienst „Smart Card Removal Policy“ muss gestartet werden
- die Aktion („No Action“, „Lock Workstation“, „Force Logoff“ oder „Disconnect if a remote Remote Desktop Services session*“)
Diese Policy wirkt dann auf die Computerkonten, welche mit einer Smart Card benutzt werden.
*ja, das heißt wirklich so in der Vorlage.
Abschließende Gedanken zum Smart Card Logon
Zum Abschluss sollte bei den Usern, welche über Smart Cards verfügen, noch der Haken beim Benutzerobjekt gesetzt werden „Smart card is required for interactive logon“. Jenes unterbindet die Verwendung des Kennwortes gleich auf zwei Arten und Weisen:
- Das Kennwort des Users wird auf ein 120 Zeichen langes, komplexes Zufallskennwort geändert.
- Der PDC-Emulator, ab Server 2016 oder neuer, ändert das Kennwort solcher User automatisch im Rahmen der Computerkennwortänderung (30 Tage oder was davon abweichend eingestellt wurde).
Geheim-Tipp
Den Haken „Smart card is required for interactive logon“ würde ich bei jedem deaktivierten User setzen, der dort im AD noch residiert. Manchmal müssen solche User beibehalten werden (aus regulatorischen oder schlicht dummen Gründen). Diese Kennwort-Hashes von solchen Usern können für Pass-the-Hash verwendet werden. Das wird schwieriger, wenn diese Hashes sich alle 30 Tage (oder kürzer) ändern.
Dieses war der erste Streich, doch der zweite folgt sogleich!
kostenfreie Webinare zu dem Thema!
Aufgrund der hohen Resonanz auf meine drei Blogartikel biete ich zwei kostenfreie Webinare zu dem Thema Smart Card logon mit YubiKey 5 NFC.
