FIDO2-Device-Logon mit Yubico YubiKey 5 NFC
FIDO2 kann zur Authentifizierung im EntraID herangezogen werden.
Was ich dazu brauche:
- eine Identität im EntraID
- MFA per Security Token muss gestattet sein
- einen vernünftigen Speicherort für den FIDO2-Key
Fertig.
Wie kann ich mich On-Premises bei meinem Client und/oder Server anmelden?
- Username + Kennwort
- Smart Card + PIN
Methode 1 ist nicht mehr so super zeitgemäß, Methode 2 stößt an Grenzen durch:
- Provisionierung
- CRL-Prüfung
- NTAuthCA
- Unkenntnis des aktuellen Kennwort-Hashes / Kennwortes
Sign On Methods with Windows
Windows (Server 2016 und Windows 10 1909) unterstützen folgende Anmeldemethoden:
- Benutzername + Kennwort
- Smart Card
- Windows Hello (for Business)
- Secure Token Device
Warum also nicht sich am Gerät mit einem FIDO2-Key in Verbindung mit einem Secure Token Device (z. B. einem YubiKey) anmelden?
Passwordless security key sign-in
Es gibt eine schöne URL bei Microsoft, welche das Thema sehr detailliert beschreibt: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-on-premises
Ich raubmordzitiere mal aus dem Artikel von Microsoft:
Microsoft Entra ID can issue Kerberos ticket-granting tickets (TGTs) for one or more of your Active Directory domains. With this functionality, users can sign in to Windows with modern credentials, such as FIDO2 security keys, and then access traditional Active Directory-based resources. Kerberos Service Tickets and authorization continue to be controlled by your on-premises Active Directory domain controllers (DCs).
A Microsoft Entra Kerberos server object is created in your on-premises Active Directory instance and then securely published to Microsoft Entra ID. The object isn’t associated with any physical servers. It’s simply a resource that can be used by Microsoft Entra ID to generate Kerberos TGTs for your Active Directory domain.
Ergibt also folgenden Ablauf:
- Ein User meldet sich an seinem Windows
1011-Rechner mittels FIDO2 security key (vulgo YubiKey 5 NFC) an und authentifiziert sich gegenüber den EntraID - EntraID überprüft anhand des User-UPNs (local part) zu welcher Active Directory Domain der User gehört. EntraID erstellt darauf hin ein Ticket Granting Ticket (TGT), welches aber nur die SID des Users im PAC-Feld aufweist, keine weiteren.
- Dieses TGT kommt zusammen mit dem Primary Refresh Token (PRT) zum Windows
1011-Rechner des Users. - Der Windows
1011-Rechner kontaktiert den On-Premises Domain Controller und tauscht das partiale TGT zu einem vollwertigem TGT.
Wir brauchen
- Ein On-Premises AD welches sich mit EntraID synchronisiert („Ach was?„)
- ein hybrid join device (HJD)
- Domain Controller mit Server
20162019 oder neuer. - AES256_HMAC_SHA1 beim Kerberos V5-Protokoll
- Ein Mitglied der Domain Admin-Gruppe (ein User und ein Computerkonto müssen erstellt werden)
- Ein Mitglied der Hybrid Identity Administrator-Rolle im EntraID
Im Workshop Secure Hybrid Authentication werden sowohl FIDO2-Login wie auch Smart Card-Logon praktiziert.
Hybrid-Join
Das EntraID-Setup ist in den Grundzügen schon vorhanden. Was noch benötigt wird ist der Service Connection Point (SCP) für das Hybrid Join-Szenario der Workstations. Der SCP wird hier aber nicht für Outlook verwendet, sondern für die Windows 11-Geräte, welche den Hybrid-Join durchführen.
SCP erstellen
Erstellt wird dieser SCP durch den Aufruf vom Microsoft Entra Connect Sync-Wizard; alternativ auch durch das angebotene PowerShell-Skript.
Sobald der SCP für die Device Registratin vorhanden ist, die Computerkonten in das EntraID synchronisiert wurden, werden die Windows 11 Rechner über eine geplante Aufgabe sich im EntraID registrieren.
Install-Module -Name AzureADHybridAuthenticationManagement
Für den nächsten Schritt benötigen wird das PowerShell-Modul „AzureADHybridAuthenticationManagement“, welches von PSGallery stammt.
Mit diesem PowerShell-Modul müssen ein paar Schritte durchgeführt werden:
- Der Endpunkt für den weiteren SCP muss auf Public („0“) gesetzt werden.
- Mit Set-AzureADKerberosServer wird ein weiteres krbtgt_12345*-Konto angelegt, sowie ein Computerobjekt mit dem namen „AzureADKerberos“, welches wie ein RODC in der OU „Domain Controllers“ sitzt.
*Die Nummer ist wie bei einem RODC in der Regel fünfstellig und direkt mit dem Computerkonto „AzureADKerberos“ konnotiert.
Die PowerShell-Befehle
Die PowerShell-Befehle in der Übersicht:
Installation des PowerShell-Modules:
Install-Module -Name AzureADHybridAuthenticationManagementAufbau der Variablen und Erstellen des SCP:
$domain = "CLOUD-HYBRID.DE" #Realm der Quell-Domain
$domainCred = Get-Credential -Credential CH\Administrator #Credentials von einem Domain Admin
$cloudCred = Get-Credential -Credential admin@cloudhybrid.onmicrosoft.com #Credentials von einem Hybrid Dingenskirchen Admin
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred #Erstellen des krbtgt-Kontos + ComputerkontoWichtig: die Version des PowerShell-Modules sollte mindestens 2.4.71.0 sein! Andernfalls geht das mit dem krbtgt-Konto sauber auf die Bretter.
Ein bisschen noch Hand anlegen
Ich empfehle noch zwei Änderungen durchzuführen, sofern das obige geklappt hat.
- beim „krbtgt_12345„-Konto bitte die AES-Verschlüsselung noch aktivieren
- beim Computerkonto „AzureADKerberos“ bitte die AES-Verschlüsselung noch aktivieren
- Keyrollover beim „krbtgt_12345“ konfigurieren.
Group Policy: Turn on security key sign-in
Die letzte Amsthandlung steht an: per Group Policy (oder per Intune, Skript, Deployment und dergleichen) muss der Credential Provider bei Windows 10 11 um security key sign-in erweitert werden.
Hier im Beispiel per Group Policy findet man die notwendigen Einstellungen unter: Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Logon ⇒ Turn on security key sign-in
Diese Policy wird auf „Enabled“ gesetzt und mit der ensprechenden OU verknüpft.
Zeit zu testen!
Renate Ratlos hat nun drei Möglichkeiten sich zu Authentifzieren:
- Benutzername + Kennwort
- Smart Card
- FIDO2 in Verbindung mit Security Key (YubiKey 5 NFC)
Der einzige Unterschied im Vergleich zur Smart Card ist die Tatsache, dass man den Security Key einmal kurz berühren muss, damit die Authentifizierung durchläuft.
Primary Refresh Token – PRT
Ein Show-Stopper kann das Primary Refresh Token (PRT) sein.
A Primary Refresh Token (PRT) is a long-lived authentication token used by Microsoft Entra ID to enable Single Sign-On (SSO) and seamless access to cloud resources. It is issued when a user signs into a Windows device and is automatically renewed every 4 hours, with a default lifetime of 14 days. The PRT contains device and user identity claims and is required for continuous access to Microsoft cloud services without repeated logins.
Das PRT wird normalerweise alle 4 Stunden aktualisiert und hält per Default 14 Tage. Innerhalb der 14 Tage kann das PRT aktualisiert werden. Dieser Prozess kann bis zu 90 Tage lang aufrecht erhalten werden. Nach den 90 Tagen wird eine „full authentication“ fällig.
Die „full authentication“ wird, unter anderem, ausgelöst, wenn:
- Die Sitzung am Rechner vollständig beendet wird (abmelden) und neu angemeldet wird (Username + password, FIDO2 und / oder WHfB). Hierzu ist eine Internetverbindung und ein Kontakt zu EntraID notwendig.
- Per Browser im Incognito-Modus eine M365-Seite aufgerufen wird. Die hierzu notwendige Authentifizierung erneuert das PRT.
Bedeutet: wenn mein PRT abgelaufen ist (90 Tage sind rum) und kein DC zur Verfügung steht, dann kann ich mich zwar immer noch am hybrid joined Rechner anmelden per YubiKey und FIDO2, jedoch bekomme ich kein PRT. Das wiederum hat ein paar negative Auswirkungen, da Anwendungen wie MS-Teams, Outlook, OneDrive und dergleichen ein gültiges PRT benötigen.
„Was tun?“ sprach Zeuss.
- Kontakt zu einem DC herstellen (eg. VPN)
- manuell an den MS-Cloud-Services anmelden (https://mysignins.microsoft.com, https://portal.microsoft.com, https://myaccount.mircosoft.com)
- MFA auslösen (sofern hinterlegt)
Résumé
Unter der Präsmisse man verwendet eine hybride Struktur bei der Authentifzierung: On-Premises Active Directory und EntraID über EntraID-Connect synchronisiert:
Wenn der User bereits einen FIDO2 Key im EntraID hat, ist es ein Klack die Authentifizierung bei Windows 11 im hybrid join-Szenario auf security key sign-in umzustellen.
Vergleicht man den Prozess mit dem der Smart Card, fällt auf, dass die Provisionierung einfacher ist, da der User das selber durch führen kann könnte. Inwieweit die Transferleistung der Anwender hierzu ausreicht, sei dahingestellt.
Das PRT muss man aber im Auge behalten.
Computerlogbuch der IQUnit, Captain Handl, Sternzeit -297859,0
Ein Kontakt per Linkedin fragte im informellen Austausch, ob es möglich ist per Smart Card-Removal-Policy ein Abmelden oder sperren des Bildschirmes beim Abziehen des Security Keys auszulösen.
Das hängt davon ab, ob der Security Key als Smart Card am Windows erscheint oder nicht.
Windows Helo for Business: ja, geht, das ist technisch gesehen eine virtuelle Smart Card, die aber (mittlerweile) FIDO2- und Passkey speichern kann.
Yubico YubiKey 5 NFC: nein, das geht nicht, da der YubiKey sich nicht als Smart Card am Windows erscheint.
Und was mache ich jetzt bei Yubico YubiKey?
Blöde Frage.
Ja, manche Fragen sind blöd.
Diese zum Beispiel.
Oder: „Ist der orangene Präsident wirklich so durchgeknallt?“
Ich schreibe ein Skript, welches die gewünschte Lösung umsetzt!
Für das Problem mit dem YubiKey, nicht für das Problem mit dem orangenen Präsidenten.
$DeviceName = "Yubico YubiKey" # Change this to match your device name in Device Manager
$lockOrLogoff = 'lock'
if($lockOrLogoff -eq 'Logoff')
{
while ($true) {
$Device = Get-PnpDevice | Where-Object { $_.FriendlyName -like "*$DeviceName*" }
if ($Device.Status -eq "OK") {
Start-Sleep -Seconds 5
} else {
Stop-Process -Name "explorer"
logoff
}
}
} else {
while ($true) {
$Device = Get-PnpDevice | Where-Object { $_.FriendlyName -like "*$DeviceName*" }
if ($Device.Status -eq "OK") {
Start-Sleep -Seconds 5
} else {
rundll32.exe user32.dll, LockWorkStation # Locks the screen
}
}
}
Kurze Erklärung zum Skript und zur Mechanik.
Das Skript wird im User-Kontext gestartet und prüft alle 5 Sekunden, ob der Stick noch eingesteckt ist bzw. in Reichweite des NFC-Reader liegt. Ist dem nicht so, dann wird wahlweise Abgemeldet oder der Rechner gesperrt.
Dieses Skript wird dann auf den jeweiligen Client verbracht, zum Beispiel durch Group Policy, und eine geplante Aufgabe (vulgo scheduled task) erstellt, welcher das Skript im Userkontext startet.
%WindowsDir%\System32\WindowsPowerShell\v1.0\powershell.exe
-WindowStyle Hidden -executionPolicy remotesigned -File "%WindowsDir%\System32\FIDO2SecurityKeyRemoval.ps1"Nachtrag zum Thema FIDO2-Device-Login:
Wer Interesse an einer ganzheitlich sicheren Authentifizierung hat, On-Premises und Cloud, kann sich hierzu im „Secure Hybrid Authentication“-Workshop berieseln lassen.