Journey To Passwordless: Windows 10 Device Onboarding und Windows Hello for Business
Artikelübersicht
- Passwordless - Aber warum?
- Initiale Konfiguration
- Temporary Access Pass
- FIDO2 Security keys
- Windows 10 Device Onboarding und Windows Hello for Business
- Administrieren mit PowerShell und ohne Passwort
- Microsoft Authenticator app
- FIDO2 Schlüssel einschränken & Fazit
Wiederholung
Der Administrator Account den wir für die passwortlose Anmeldung nutzen hat mittlerweile seinen initialen Login durchgeführt und einen FIDO2 Security Key für die permante Anmeldung registriert. Diese initiale Anmeldung musste aufgrund von Einschränkungen beim Windows 10 Enrollment an einem schon eingerichteten Gerät durchgeführt werden. Leider ist die Nutzung des Temporary Access Pass bei der initialen Einrichtung von Windows mittels der Out-of-Box-Experience oder Autopilot nicht möglich*.
Nun kann die Einrichtung der eigenen Privileged Admin Workstation (PAW) durchgeführt werden.
*Am Ende dieses Blogs stelle ich eine Methode vor mit der mittels Preview Features von Autopilot und Intune ein Deployment auch mittels TAP möglich ist.
Out-of-Box-Experience
Bei der Einrichtung von Windows mittels der Out-of-Box-Experience wählt man “Setup for an Organization” und dann die ist die Option “Anmeldung mit Security Key” in der hier verwendeten Version Windows 10 20H2 direkt vorhanden. Nach der erfolgreichen Anmeldung wird der Computer mit dem Entra ID (Azure AD) verbunden (Entra ID (Azure AD) Join) und wenn konfiguriert in Intune enrolled.
Erste Anmeldung
Wenn keine anderen Einstellungen von Intune geliefert werden wird Windows 10 nach der erfolgreichen Installation direkt Windows Hello for Business für die Anmeldung aktivieren.
Dabei muss der Benutzer eine PIN vergeben die nur auf diesem Geräte Gültigkeit hat. Mit dieser PIN kann der private Schlüssel für die Anmeldung im TPM Chip des Laptops entsperrt werden. Windows forciert hier also direkt eine weitere Methode zur passwortlosen Anmeldung.
Konfiguration
Damit die Anmeldung an Windows ebenfalls mittels Security Key durchgeführt werden kann, muss dies erst aktiviert werden.
Intune
Wenn Intune für die Verwaltung genutzt wird, kann ab Windows 1903 der notwendige Key SecurityKey/UseSecurityKeyForSignin
des PassportForWork configuration service provider verteilt werden.
Zentral kann diese Einstellung im Bereich “Windows enrollment im Menüpunkt Windows Hello for Business aktiviert werden. Diese Einstellung gilt für alle unterstützten Windows 10 Geräte im Unternehmen.
Wenn ein gezieltere Rollout gewünscht ist muss ein “Configuration Profile” vom Typ “Identity protection” angelegt und den entsprechenden Geräte zugewiesen werden.
Registry
Für einen schnellen Test kann die notwendige Konfiguration auch mittels Registrywert aktiviert werden.
HKLM\SOFTWARE\Microsoft\Policies\PassportForWork\SecurityKey
UseSecurityKeyForSignIn = 1
Type: DWORD
Am einfachsten geht es mit diesem PowerShell Snippet.
New-Item -Path "HKLM:\SOFTWARE\Microsoft\Policies\PassportForWork\SecurityKey" -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Policies\PassportForWork\SecurityKey" -Name UseSecurityKeyForSignIn -Value 1 -PropertyType DWord -Force
Anmeldung mit FIDO2 Security Key
FIDO2 USB-C
Es reicht den FIDO2 Security Key am Gerät anzuschließen und mit einer Berührung zu entsperren. Wenn ein Security Key genutzt wird der eine PIN für die Nutzung benötigt, muss diese noch zusätzlich eingeben werden. In dem hier demonstrierten Fall entsperrt der Fingerabdruck direkt den Security Key, was die Anmeldeerfahrung mit dem Entsperren eines Smartphones.
FIDO2 Bluetooth
Sollte ein bluetoothfähiger FIDO2 Security Key genutzt werden, muss dieser einmalig mit Windows verbunden werden.
Die ausführliche Anleitung ist hier zu finden.
Automatische Sperrung
Leider gibt es aktuell noch keine Möglichkeit den Computer automatisch zu sperren wenn der FIDO2 Security Key entfernt wird. Im Falle eines Bluetooth Schlüssels wäre diese Funktion auch nicht sinnvoll nutzbar, da der Schlüssel um Strom zu sparen nicht die ganze Zeit aktiv ist, sondern nur wenn er benötigt wird.
Wer ein wenig spielen möchte dem sei gesagt, dass der Schlüssel sich als HID-compliant fido
Gerät meldet und man dies natürlich nutzen kann um zu prüfen ob der Security Key sich noch im Rechner befindet.
Hier ein Beispiel das aber nur als POC gesehen werden darf und in keinem Fall als nutzbare Implementierung.
# Check if the FIDO2 key is still present
while ( (Get-CimInstance -Class Win32_PnpEntity | ? Caption -match "HID-compliant fido") ) {
Write-Verbose "FIDO2 Key present..."
Start-Sleep -Seconds 1
}
# Lock workstation when removed
Invoke-Command -ScriptBlock { rundll32.exe user32.dll,LockWorkStation }
Windows Hello for Business
Mit Windows Hello for Business bietet Microsoft eine passwortlose Möglichkeit der Anmeldung an Windows 10. Dabei ist die Anmeldung nicht auf die Nutzung der PIN begrenzt, sondern unterstützt auch biometrische Merkmale wie z.B. die Nutzung einer Kamera oder eines eingebauten Fingerabdrucklesegeräts.
Im Gegensatz zu Windows Hello nutzt Windows Hello for Business nur schlüssel- oder zertifikatsbasierte Authentifizierung.
Die Implementierung von Windows Hello for Business in einer Enterprise-Umgebung inkl. PKI sprengt den Umfang dieser Blogserie und wird daher nicht näher beleuchtet.
PAW Deployment mit Autopilot und Intune
Auch wenn es noch keinen offiziellen Support für die Nutzung von TAP beim Deployment von Windows 10 gibt, kann man mit zwei Preview Features ein Szenario herbeiführen wo dies doch möglich ist.
Vorraussetzungen sind die Nutzung des Deployment Modus “Self-Deploying” und der Einstellung “EnableWebSignIn” für den Authentication CSP.
Device configuration Profile
Es sind zwei Profile notwendig um die notwendige Konfiguration zu verteilen. Beide Profile müssen der Gerätegruppe, in meinem Fall die Gruppe “Self deploying admin workstation” zugewiesen werden.
Enable Security Key Sign-In
Profile type: | Identity protection |
Use security keys for sign-in | Enabled |
Enable Web Sign-In
Profile type: | Identity protection |
Name | Authentication/EnableWebSignIn |
OMA-URI | ./Device/Vendor/MSFT/Policy/Config/Authentication/EnableWebSignIn |
Data type | Integer |
Value | 1 |
Auto Pilot Profile
Zusätzlich wird noch ein Deployment Profil für Autopilot eingerichtet. Dabei ist es wichtig den Deployment Mode “Self-Deploying (preview)” auszuwählen und dieses Profil der Entra ID (Azure AD) Gruppe zuzuweisen.
Autopilot
Im Bereich Windows Autopilot devices muss das Gerät hinzugefügt worden sein und der Profile status auf “Assigned” stehen. Wichtig ist das nur Geräte unterstützt werden die einen TPM 2.0 Chip nutzen der TPM attestation unterstützt.
Anschließend kann der Rechner, am Besten direkt mittels Ethernetverbindung, gestartet werden und das Gerät führt das komplette Deployment ohne Benutzereingriff durch.
Virtuelle Maschinen
Ich habe es in meinem Test nicht geschafft eine virtuelle Maschine (VMware) in diesem Modus zu deployen. In der offiziellen Dokumentation wird darauf hingewiesen das Hyper-V virtual TPMs nicht unterstützt werden, was wohl generell für virtuelle TPMs gilt.
Die Installation bricht mit dem Fehler 0x800705b4 im Abschnitt “Securing your hardware” ab.
Anmeldung mittels Web Sign-In
Bei der Anmeldung werden dem Benutzer unter “Sign-in options” vier verschiedene Optionen für die Anmeldung angezeigt.
Anmeldung mittels Benutzername und Passwort | |
Anmeldung mittels FIDO2 Security Key | |
Anmeldung mittels Windows Hello for Business PIN | |
Anmeldung mittels Web Sign-In |
Web Sign-In nutzt den Browser des Betriebssystems für die Anmeldung, was die Nutzung eines Temporary Access Pass bei der Anmeldung erst möglich macht. Es wird also kein spezieller TAP Modus genutzt, sondern alle im Browser verfügbaren Anmeldemethoden.
Nach der erfolgreichen Anmeldung muss eine WHFB PIN vergeben und anschließend natürlich der FIDO2 Security Key registriert werden.
Self-deploying Mode mit Web Sign-In
Der Self-deploying mode von Intune und Web Sign-In bieten somit eine Lösung für das initiale Bereitstellen einer Admin Workstation in einer passwortlosen Umgebung.
Dabei gilt es aber zu berücksichtigen das
- Das Gerät in Intune nicht dem Benutzer zugeordnet wird
- Der Benutzer dadurch keinen Zugriff auf BitLocker Recovery Keys des Geräts hat
- Der Benutzer kann keine Ihm persönlich zugewiesenen Apps im Company Portal installieren
- In Umgebungen mit ADFS muss der der Wert
Authentication/ConfigureWebSignInAllowedUrl
gesetzt werden um CVE-2021-27092 zu verhindern - Windows 10 wird erst ab Version 1903 korrekt unterstützt
- Web Sign-in und Self-deploying nur auf Entra ID (Azure AD) joined Computern unterstützt wird
- (Conditional Access soll teilweise nicht unterstützt werden**)
Gerade der Umstand das nicht jeder Benutzer auf den BitLocker Recovery Key zugreifen kann ist jedoch nicht zwingend ein Nachteil. Wie Stephen Shkardoon in seinem Blogartikel “All my Intune users could become Local Administrators and it’s a Feature?” beschreibt ist diese Funktion auch ein Einfalltor für Angreifer um sich erhöhte Berechtigungen auf dem eigenen Gerät zu verschaffen.
Was Conditional Access angeht betrifft dies wohl nur das initiale onboarding. Nach der erfolgreichen Installation kann bei der Nutzeranmeldung sehr wohl geprüft werden ob das Gerät compliant / managed ist.
Solltest du hier weitere Informationen zu Einschränkungen haben, melde dich gerne bei mir.
Nächste Schritte
Im nächsten Blog werde ich die Einschränkungen in der täglichen Nutzung der FIDO2 basierten Anmeldung näher beleuchten und Workarounds für bekannte Probleme aufzeigen.