Windows Hello for Business: Passwortlose Anmeldung mit Cloud Kerberos Trust

Passwörter sind seit Jahren das schwächste Glied in der Authentifizierungskette: Sie werden wiederverwendet, abgephisht und über das Netzwerk übertragen. Windows Hello for Business (WHfB) löst dieses Problem, indem es das Passwort durch eine gerätegebundene, kryptografisch abgesicherte Anmeldung per PIN oder Biometrie ersetzt. Besonders spannend wird es in Hybrid-Umgebungen: Mit Cloud Kerberos Trust greift selbst ein reines Entra-Joined-Gerät ohne Username und Passwort auf lokale Fileshares und andere Kerberos-Ressourcen zu. Dieser Artikel führt durch die Deployment-Modelle, die Voraussetzungen, die Einrichtung von Entra-ID Kerberos samt Cloud Trust und erklärt Schritt für Schritt, wie die Authentifizierung im Hintergrund abläuft.

Was ist Windows Hello for Business?

Windows Hello for Business ist ein modernes, kennwortloses Authentifizierungssystem von Microsoft. Es nutzt Biometrie (Gesichtserkennung, Fingerabdruck) oder eine PIN, um Zugriff auf Geräte und Ressourcen zu ermöglichen. Die Anmeldedaten sind gerätegebunden und werden durch eine starke Zwei-Faktor-Authentifizierung abgesichert.

Die Kernkomponenten:

• Benutzer- und Gerätezertifikat oder ein Schlüsselpaar (je nach Konfiguration: Key-Trust oder Certificate-Trust)
• Sicher gespeicherte private Schlüssel im TPM des Geräts
• Anmeldung über PIN oder biometrische Daten
• Keine Übertragung von Passwörtern im Netzwerk

Der entscheidende Punkt: Der private Schlüssel verlässt das TPM nie. Statt eines Passworts, das abgefangen werden könnte, beweist das Gerät seine Identität über eine kryptografische Signatur – phishing-resistent und an genau dieses eine Gerät gebunden.

Deployment-Modelle für das WHfB-Onboarding

Das Ziel jedes Onboardings ist identisch: die Registrierung des WHfB-Credentials nach erfolgreicher MFA. Der Weg dorthin unterscheidet sich jedoch je nach Umgebung und Reifegrad der Organisation.

A. Self-Service (User-driven) Onboarding

Der Benutzer richtet WHfB bei der ersten Anmeldung selbst ein.

Ablauf:

1. Der Benutzer meldet sich mit Benutzername und Passwort an.
2. Er wird zur MFA aufgefordert (z. B. via Authenticator-App, SMS).
3. Nach erfolgreicher MFA startet die Einrichtung von PIN und ggf. Biometrie.

Voraussetzungen: Azure AD (Entra ID), ein unterstützendes Gerät und aktivierte MFA.

Varianten:

• Azure AD Join – z. B. bei neuen Cloud-Only-Geräten
• Hybrid Azure AD Join – Domänenmitgliedschaft plus Azure AD

B. Provisioning durch die IT (PKI- oder MDM-basiert)

Die IT richtet WHfB über Gruppenrichtlinien, MDM oder während der Gerätebereitstellung (Autopilot) ein.

Beispiel – Autopilot + Intune (mit MFA):

• Der Benutzer durchläuft den Autopilot-Prozess.
• Währenddessen wird die MFA durchgeführt und WHfB eingerichtet.

C. Temporary Access Pass (TAP)

Die IT vergibt einen temporären Zugangscode (TAP), um das initiale MFA zu ermöglichen – ideal für neue Mitarbeitende oder verlorene Geräte.

Ablauf:

1. Der TAP wird erzeugt und dem Benutzer bereitgestellt.
2. Der Benutzer verwendet den TAP als einmalige MFA, um WHfB einzurichten.

Vorteil: passwortloser Start, geeignet für Zero-Trust-Ansätze.

Vergleich der Deployment-Methoden

Hinweis zu GPO-basierten Deployments: Die Policy-Einstellungen (u. a. PIN-Komplexität, -Länge und -Historie) werden über Gruppenrichtlinien gesetzt. Nach dem Zurücksetzen einer PIN über GPO wird die PIN-Änderung in ein Attribut im Azure AD geschrieben. Dieses muss mit dem nächsten AAD-Connect-Sync ins lokale AD synchronisiert werden. Vorher kann der User die neu geänderte PIN nicht verwenden – dadurch kann eine Wartezeit von bis zu 30 Minuten entstehen.

PIN-Recovery-Optionen für Mitarbeitende

Wenn eine PIN vergessen wurde oder zurückgesetzt werden muss, gibt es drei Wege:

• A. Selbstservice über die Einstellungen – In den Windows-Einstellungen unter Anmeldeoptionen → PIN vergessen. Das führt zu einer erneuten MFA, danach kann eine neue PIN gesetzt werden.
• B. Via Temporary Access Pass (TAP) – Die IT stellt einen TAP aus, der Benutzer kann WHfB inklusive PIN neu einrichten.
• C. Gerätezurücksetzung und Neueinrichtung – Das Gerät wird zurückgesetzt, die WHfB-Einrichtung erfolgt im Rahmen des Onboardings erneut.

Verfügbare MFA-Methoden in Entra ID

Da WHfB zwingend eine erfolgreiche MFA während der Registrierung voraussetzt, lohnt ein Blick auf die von Microsoft unterstützten Methoden:

Typische Einrichtungs-Workflows je MFA-Methode

1. Microsoft Authenticator (Push) – modern, empfohlen, sicher:

1. Der Nutzer meldet sich mit Benutzername und Passwort an.
2. Ein Push wird an die Authenticator-App gesendet, der Nutzer bestätigt.
3. Der WHfB-Einrichtungsbildschirm erscheint: PIN und ggf. Biometrie.
4. Das Credential wird lokal im TPM erstellt und mit Azure AD bzw. AD verknüpft.

Vorteil: komfortabel und sicher. Voraussetzung: Die App muss vorher registriert sein.

2. SMS oder Telefonanruf – einfach, aber weniger sicher:

1. Anmeldung mit Benutzername und Passwort.
2. SMS-Code oder Anruf zur Authentifizierung.
3. Die Einrichtung von WHfB erfolgt direkt danach.

Vorteil: niedrige Einstiegshürde. Nachteil: abhängig vom Mobilfunk, leichte Spoofbarkeit.

3. FIDO2-Sicherheitsschlüssel – kennwortlose Einrichtung, sehr sicher:

1. Der Benutzer steckt den FIDO2-Key ein oder verbindet ihn via NFC.
2. Der Key wird entsperrt (z. B. per Fingerabdruck oder PIN).
3. Die Anmeldung erfolgt komplett ohne Passwort.
4. WHfB kann direkt gesetzt werden (z. B. beim Autopilot).

Vorteil: passwortlos, Zero-Trust-ready. Nachteil: Bedarf an Hardware und Integration.

4. Temporary Access Pass (TAP) – ideal für Erstzugänge oder PIN-Recovery:

1. Die IT generiert einen TAP über Azure AD.
2. Der Benutzer verwendet den TAP zur einmaligen Anmeldung.
3. WHfB wird eingerichtet (PIN, Biometrie).
4. Danach wird der TAP automatisch ungültig.

Vorteil: keine Passwörter nötig. Nachteil: TAP-Management durch Admins notwendig.

5. Smartcard (Hybrid, On-Prem-PKI) – für klassische Umgebungen:

1. Der Benutzer steckt die Smartcard ein.
2. PIN-Eingabe als zweiter Faktor.
3. Anmeldung und Credential-Provisioning durch die IT.
4. WHfB wird meist über GPO oder Skript ausgerollt.

Vorteil: gut integrierbar bei bestehender PKI. Nachteil: Verwaltungsaufwand, hardwareabhängig.

Best Practice für die Einführung

• Phase 1 – Vorbereitungen: MFA-Registrierung erzwingen (z. B. via Azure AD Identity Protection), festlegen, welche MFA-Methoden erlaubt sind, optional TAP für Break-Glass-Szenarien aktivieren.
• Phase 2 – Pilot & Onboarding: Pilotgruppe mit WHfB ausstatten (z. B. via Intune), MFA aktivieren – bevorzugt Authenticator oder FIDO2 –, Autopilot nutzen, wo möglich.
• Phase 3 – Rollout & Governance: Policies zu PIN-Länge, Biometrie und Recovery definieren, Monitoring und Logging aktivieren, Endanwender schulen.

Die drei Hybrid-Trust-Modelle

Windows Hello for Business auf Azure-AD-Joined-Geräten kann Single Sign-On zu Active-Directory-domänengebundenen Diensten und Servern in Hybrid-Identity-Umgebungen bereitstellen. Microsoft bietet dafür drei Wege an: Certificate Trust, Key Trust und Cloud (Kerberos) Trust. Jedes dieser drei Trust-Modelle hat eigene Vor- und Nachteile, eine eigene Anleitung und eigene Artefakte – zugleich teilen sie einige Gemeinsamkeiten. Wer diese Aspekte kennt, kann jedes Modell gezielter troubleshooten.

Eine bewährte Reihenfolge beim Troubleshooting von WHfB Hybrid Access:

• Prüfen, ob dem Benutzerobjekt in Azure AD eine Azure AD Premium-Lizenz zugewiesen ist.
• Prüfen, ob das Benutzerobjekt die Berechtigung hat, WHfB-Methoden zu konfigurieren.
• Prüfen, ob die richtige MFA-Methode für das Benutzerobjekt konfiguriert ist.
• Prüfen, ob das Gerät korrekt für WHfB konfiguriert ist.
• Prüfen, ob das Benutzerprofil korrekt konfiguriert ist.
• Das Event-Log prüfen.
• Den Read-only Domain Controller des Cloud Trust prüfen.
• Prüfen, ob die Domänencontroller mit dem richtigen Zertifikat konfiguriert sind.
• Prüfen, ob das Gerät mit dem Zertifikat der Root-CA konfiguriert ist.
• Prüfen, ob das Benutzerobjekt für das richtige Zertifikat registriert ist.

Azure-AD-Premium-Lizenz prüfen

Eine der wichtigsten Voraussetzungen für WHfB Hybrid Access ist die Azure AD Premium-Lizenzierung. Während MFA als Teil von Azure AD Free über die Security Defaults verfügbar ist, benötigt WHfB Azure AD Premium. Jede Person, die von Azure-AD-Joined-Geräten aus auf On-Premises-Ressourcen zugreifen soll, braucht die Azure AD Premium P1-Lizenz. Da P1 in Azure AD Premium P2, in Microsoft EMS E3/E5 sowie in Microsoft 365 E3/E5 enthalten ist, funktioniert auch die Zuweisung über eine dieser Suiten.

Vorgehen im Entra-Portal:

• Mit einem Konto anmelden, das die Rolle Global Administrator, License Administrator, Directory Writers, Groups Administrator, User Administrator oder Partner Tier1 Support besitzt (bzw. aktivieren kann). MFA durchführen, wenn dazu aufgefordert.
• Bei aktivem Privileged Identity Management (PIM) die Rolle mit den geringsten Rechten aktivieren.
• Show more… → Billing → Licenses öffnen.
• Unter All products das Lizenzprodukt Azure AD Premium P1 (oder die enthaltende Suite) wählen.
• Über die Suche das betroffene Benutzerobjekt finden und sicherstellen, dass das Feature aktiviert ist. Bei Suiten über Enabled Services prüfen, ob die P1-Lizenz zugewiesen ist – falls nicht, per (dynamischer) Gruppe oder individuell zuweisen.

Nach Änderungen an Lizenzen etwas Zeit für die Replikation innerhalb der Azure-AD-Infrastruktur einplanen.

Berechtigung zur Konfiguration einer WHfB-Methode prüfen

Selbst mit korrekter Lizenz und Methode können Einstellungen der Nutzung als passwortlose Methode widersprechen – besonders bei der Microsoft-Authenticator-App und FIDO2-Sicherheitsschlüsseln.

Für den Authenticator (passwortlose Anmeldung):

• Im Entra-Portal mit einer Rolle wie Global Administrator, Authentication Administrator oder Privileged Authentication Administrator anmelden.
• Show more… → Protect & secure → Authentication Methods öffnen.
• Microsoft Authenticator wählen. Für die All users-Gruppe (oder die relevante Zielgruppe) sicherstellen, dass die Spalte Authentication mode auf Any oder speziell Passwordless steht. Enthält keine Gruppe das Benutzerobjekt, eine Gruppe hinzufügen oder ersatzweise All users einschließen. Anschließend Save.

Für FIDO2:

• Zurück zu Authentication methods | Policies navigieren, FIDO2 security key wählen.
• Sicherstellen, dass die Option Enable aktiviert ist und eine Gruppe (oder All users) ausgewählt ist, die das Benutzerobjekt enthält, um FIDO2 als WHfB-Methode zu erlauben. Danach Save.

MFA-Methode am Benutzerobjekt prüfen

WHfB-Authentifizierung gilt in Conditional Access als MFA-Methode – im Kontext der Authentication Strengths sogar als phishing-resistente MFA-Methode. Für ein sicheres Onboarding muss die Person mindestens einmal während des Deployments eine MFA durchführen. Ein guter Weg dafür ist, MFA für die Aktion Register or join devices in Conditional Access zu verlangen.

Prüfung:

• Im Entra-Portal unter Users → All users das Benutzerobjekt öffnen und Authentication methods wählen.
• Ist die neue Erfahrung für Authentifizierungsmethoden noch nicht aktiv, über das lila Banner darauf umstellen.
• Sicherstellen, dass mindestens eine Methode in der Liste der Usable authentication methods vorhanden ist. Fehlt eine nutzbare Methode oder ist sie verloren gegangen, als Admin eine hinzufügen oder eine Neuregistrierung veranlassen.

Geräte-Konfiguration prüfen

Ein Azure-AD-Joined-Gerät lässt sich manuell oder über eine MDM-Lösung wie Microsoft Intune für WHfB konfigurieren. Am Ende landet alles in Registry-Einstellungen auf dem Gerät – der zuverlässigste End-to-End-Nachweis. Relevante Registry-Werte:

• Use Windows Hello for Business – Aktiviert das Provisioning per Schlüssel oder Zertifikat für alle Nutzer. Registry: Enabled und DisablePostLogonProvisioning unter HKLM\SOFTWARE\Policies\Microsoft\PassportForWork. Enabled sollte den Wert 1 haben, DisablePostLogonProvisioning den Wert 0 (oder gar nicht vorhanden sein).
• Use biometrics – Erlaubt biometrische Gesten als Alternative zur PIN (eine PIN muss dennoch als Fallback konfiguriert werden). Registry: Domain Accounts unter HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WinBio\Credential Provider mit Wert 1.
• Use certificate for on-premises authentication – Speziell für Hybrid Certificate Trust: UseCertificateForOnPremAuth unter HKLM\SOFTWARE\Policies\Microsoft\PassportForWork muss vorhanden sein und 1 betragen.
• Use cloud trust for on-premises authentication – Speziell für Hybrid Cloud Trust: UseCloudTrustForOnPremAuth unter HKLM\SOFTWARE\Policies\Microsoft\PassportForWork muss vorhanden sein und 1 betragen.

Benutzerprofil-Konfiguration prüfen

Auch auf Profilebene kann das Provisioning blockiert sein, selbst wenn die Geräteebene korrekt ist:

• Use Windows Hello for Business – Registry: Enabled unter HKCU\SOFTWARE\Policies\Microsoft\PassportForWork muss entweder fehlen oder den Wert 1 haben.
• Use certificate for on-premises authentication – Registry: UseCertificateForOnPremAuth unter HKCU\SOFTWARE\Policies\Microsoft\PassportForWork muss fehlen oder 1 betragen.

Hardware-Voraussetzung (TPM) prüfen

In der Standardkonfiguration benötigt ein Windows-Gerät einen konfigurierten TPM-Chip. Im TPM gespeicherte Schlüssel lassen sich nur auf diesem System nutzen, während softwarebasierte Schlüssel anfälliger für Kompromittierung sind und auf anderen Systemen missbraucht werden könnten.

Die – ausdrücklich nicht empfohlene – Deaktivierung ist über die Gruppenrichtlinie Use a hardware security device möglich. Fehlt ein geeigneter TPM 1.2 oder TPM 2.0, muss diese Einstellung deaktiviert werden, um das Provisioning zu ermöglichen. Registry: RequireSecurityDevice unter HKLM\SOFTWARE\Policies\Microsoft\PassportForWork – für Tests ohne geeigneten TPM auf 0 setzen.

Event-Log auswerten

Sind die Einstellungen korrekt, liefert das Windows-Event-Log Aufschluss darüber, warum das Provisioning nicht stattfindet. Auf Windows 11 22H2 liefern die Logs Microsoft\Windows\HelloforBusiness\Operational und Microsoft\Windows\User Device Registration\Admin detaillierte Informationen. Speziell beim Hybrid Access hilft Microsoft\Windows\Security-Kerberos\Operational. Bei FIDO2-Keys liefert Microsoft\Windows\WebAuthN\Operational zusätzliche Details. Zugriff über den Event Viewer (eventvwr.exe) unter Anwendungs- und Dienstprotokolle.

Read-only Domain Controller des Cloud Trust prüfen

Gilt nur für das Hybrid-Cloud-Trust-Szenario.

Im Cloud-Trust-Szenario wird im lokalen Active Directory ein Read-only-Domain-Controller-Objekt namens AzureADKerberos in der OU Domain Controllers angelegt. Kerberos-Tickets werden von Azure AD ausgestellt – basierend auf dem Passwort seines speziellen krbtgt-Kontos krbtgt_AzureAD im Container Users.

Beide Objekte lassen sich über die MMC-Snap-ins Active Directory Users and Computers (dsa.msc) oder das Active Directory Administrative Center (dsac.exe) prüfen. Den Status des RODC liefert PowerShell auf einem Server mit Azure AD Connect:

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1"
$domain = "domain.tld"
Get-AzureADKerberosServer

Zertifikate für Certificate/Key Trust prüfen

Gilt für Certificate Trust und Key Trust.

Bei diesen beiden Szenarien müssen die Domänencontroller mit den richtigen Zertifikaten ausgestattet sein. Prüfung:

• Interaktiv am Domänencontroller anmelden, certlm.msc starten (Certificates-Snap-in für den lokalen Computer).
• Unter Personal → Certificates nach der Spalte Certificate Template sortieren und auf Zertifikate mit der angegebenen Vorlage achten. In den Microsoft-Docs wird die Vorlage Domain Controller Authentication (Kerberos) verwendet.

Tipp: Wurde die automatische Zertifikatregistrierung konfiguriert, der DC hat die Einstellungen aber noch nicht übernommen, lässt sich die Registrierung mit certutil.exe -pulse anstoßen.

Root-CA-Zertifikat auf dem Gerät prüfen (Certificate/Key Trust): certlm.msc starten, unter Trusted Root Certification Authorities → Certificates nach dem Zertifikat der Root-CA suchen.

Benutzerzertifikat prüfen (nur Certificate Trust): certmgr.msc starten (Snap-in für den aktuellen Benutzer), unter Personal → Certificates nach der Spalte Certificate Template sortieren. In den Microsoft-Docs wird die Vorlage WHfB Certificate Authentication verwendet.

Passwortloser Cloud Kerberos Trust mit Windows Hello

Es geht hier um ein Hybridszenario, in dem sowohl ein On-Prem-AD als auch ein Azure AD (Entra ID) vorhanden ist. Das Ziel: Man hat ein lokales AD, möchte aber Windows Hello for Business einsetzen und weiterhin auf lokale Ressourcen zugreifen.

Mit einem Trust erhält man über WHfB ein SSO gegenüber Kerberos-Ressourcen. Konkret heißt das: Ein reines Entra-Joined-Gerät kann auf lokale Fileshare-Ressourcen zugreifen, ohne dass der Nutzer Benutzername und Passwort eingeben muss.

Der grundlegende Ablauf:

• Der PC fragt über Entra ein Kerberos-Ticket (Ticket Granting Ticket, TGT) beim lokalen DC an.
• Mit dem TGT kann sich der Client gegenüber Kerberos-Ressourcen authentifizieren.
• Wichtig: Geräte müssen das TGT direkt vom Domänencontroller beziehen. Zum Ausstellungszeitpunkt muss der Client den DC also netzwerkseitig erreichen und mit ihm kommunizieren können.

Wann genau das TGT angefordert wird, hängt vom Join-Typ ab:

• Entra-Joined: Nutzer melden sich mit Entra-Zugangsdaten am Gerät an. Das TGT wird erst dann angefordert, wenn zum ersten Mal auf eine Kerberos-Ressource zugegriffen werden soll.
• Hybrid-Joined: Nutzer melden sich mit lokalen AD-Zugangsdaten an. Das Kerberos-Ticket wird direkt bei der ersten Anmeldung angefordert. Kann der DC nicht gefunden werden, erscheint eine Fehlermeldung.

Der Gesamtablauf beim Zugriff (mit FIDO2-Key oder Windows Hello) zusammengefasst:

1. Ein Benutzer meldet sich an einem Windows-10-Gerät mit einem FIDO2-Sicherheitsschlüssel bzw. Windows Hello an und authentifiziert sich gegen Microsoft Entra ID.
2. Microsoft Entra ID überprüft das Verzeichnis auf einen Kerberos-Serverschlüssel, der zur lokalen Active-Directory-Domäne des Benutzers passt.
3. Microsoft Entra ID generiert ein Kerberos-TGT für die lokale AD-Domäne. Dieses TGT enthält nur die SID des Benutzers, aber keine Autorisierungsdaten.
4. Das TGT wird zusammen mit dem Microsoft Entra Primary Refresh Token (PRT) an den Client zurückgeschickt.
5. Der Client kontaktiert einen lokalen Domänencontroller und tauscht das Teil-TGT gegen ein vollständig gebildetes TGT.
6. Der Client verfügt nun über ein Entra PRT und ein vollständiges AD-TGT und kann sowohl auf Cloud- als auch auf firmeninterne Ressourcen zugreifen.

Der Windows-10-Client authentifiziert sich gegen Microsoft Entra ID (1–3), erhält ein Teil-TGT und tauscht es beim lokalen Active Directory gegen ein vollständiges TGT (4–5). Die Kerberos-Server-Keys werden per Azure AD Connect synchronisiert.

Voraussetzungen für den Cloud Trust

Bevor der Cloud Kerberos Trust eingerichtet werden kann, müssen folgende Voraussetzungen erfüllt sein:

1. Microsoft Entra Kerberos für SSO muss implementiert sein (bzw. wird im Rahmen der Einrichtung implementiert).
2. Ein PC mit installierter PowerShell, der Domain-Joined ist (die Ausführung ist auch direkt vom AADC-Server oder DC möglich).
3. Die Domänencontroller müssen mindestens laufen mit:
   • Windows Server 2016 mit dem entsprechenden Patch, oder
   • Windows Server 2019 mit dem entsprechenden Patch.

Nur die Hybridbereitstellung mit Cloud Kerberos verlangt Mindestversionen (Windows 10/11 21H2 mit den genannten KB-Updates); alle übrigen Modelle laufen mit jeder unterstützten Windows-Version. 4. Global-Admin-Zugangsdaten für den Tenant. 5. Ein On-Prem-User mit Domänen-/Organisationsadministrator-Rechten. 6. TLS 1.2 muss auf dem Server bzw. Client, auf dem der Trust eingerichtet wird, für das PowerShell-Modul aktiviert sein.

Folgende Szenarien werden nicht unterstützt:

1. Deployment auf reinen On-Premises-Geräten (nur AD DS-joined, ohne Entra).
2. Remote Desktop Protocol (RDP), Virtual Desktop Infrastructure (VDI) und Citrix-Szenarien per Security Key.
3. S/MIME per Security Key.
4. „Run as" per Security Key.
5. Anmeldung an einem Server per Security Key.

Remote Credential Guard sollte hingegen funktionieren.

Einrichtung: Entra-ID Kerberos + Cloud Trust

Die Einrichtung besteht aus zwei Schritten:

1. In der lokalen Domäne muss ein Kerberos-Computerkonto erstellt werden – ein Dummy-Read-Only-Domänencontroller, der für das Ausstellen der TGTs zuständig ist.
2. Den Geräten muss man mitteilen, dass sie den Kerberos Cloud Trust verwenden sollen – dies geschieht über eine Intune-Policy.

Schritt 1: Entra-ID Kerberos über PowerShell

Zunächst PowerShell als Administrator starten. Anschließend sicherstellen, dass TLS 1.2 aktiviert ist, damit der Zugriff auf die PowerShell-Gallery funktioniert:

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

Das benötigte Modul installieren und importieren:

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
Import-Module -Name AzureADHybridAuthenticationManagement

Die Domäne des aktuell angemeldeten Users auslesen – das Kerberos-Server-Objekt wird in genau dieser AD erstellt:

$domain = $env:USERDNSDOMAIN

Den UPN des Global-Admin-Accounts des Tenants eintragen:

$userPrincipalName = "globaladmin@example.onmicrosoft.com"

Die Zugangsdaten für den lokalen Domänenadministrator abfragen (Format DOMAIN\Admin oder ganzer UPN):

$domainCred = Get-Credential

Das Azure-AD-Kerberos-Server-Objekt in der AD erstellen und zum Azure AD veröffentlichen. Dabei erscheint ein Global-Admin-Login-Prompt (Azure AD):

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Prüfen, ob das Kerberos-Server-Objekt erfolgreich erstellt wurde:

Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Die Ausgabe bestätigt das erstellte Objekt: UserAccount krbtgt_AzureAD, ComputerAccount AzureADKerberos in der OU Domain Controllers sowie die passenden On-Prem- und Cloud-Key-Versionen.

Hinweis: Bei Bedarf lässt sich der Kerberos Server Encryption Key rotieren (sowohl on-prem als auch in Entra):

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey

Was dabei im Active Directory entsteht

In der OU Domänencontroller wird nun ein Computerobjekt AzureADKerberos angelegt. Dieser DC ist ein RODC (Read-only Domänencontroller) und stellt ausschließlich TGTs aus. Der Kerberos Server Encryption Key sollte alle 30–60 Tage rolliert werden – parallel zu den Schlüsseln der Entra-SSO-Accounts.

In der OU Domain Controllers taucht das neue RODC-Objekt AzureADKerberos auf – erkennbar an der Beschreibung „Azure AD Kerberos Server".

Zusätzlich wird in der lokalen AD ein User angelegt: krbtgt_AzureAD (der Azure-AD-Kerberos-Server-User-Account für die lokale Domäne). Dieser User ist mit dem RODC über Entra ID verbunden und hält den Kerberos-TGT-Encryption-Key. Damit verschlüsselt und signiert er die Kerberos-Tickets.

Im Users-Container liegt neben dem klassischen krbtgt nun krbtgt_AzureAD – der Azure-AD-Kerberos-Server-User-Account für diese Domäne.

Jeder Domänencontroller in einer AD führt einen KDC-Dienst (Kerberos Distribution Center) aus, der alle Ticketanfragen bearbeitet – so auch der hier erstellte RODC. Dieser ist über einen Backlink mit einem krbtgt-Konto verbunden, das zum Verschlüsseln und Signieren der Kerberos-Tickets benötigt wird. Der RODC kann dadurch nur Kerberos-Tickets verarbeiten, die von Entra ID stammen, denn genau dafür wurde er erstellt. Er hat keinerlei Verbindung zu den anderen DCs.

Read-only Domain Controllers besitzen jeweils ihr eigenes KRBTGT-Konto (krbtgt_######), das zum Verschlüsseln/Signieren von Kerberos-Tickets in ihren eigenen Sites verwendet wird. Über den Backlink am Konto wird eine kryptografische Isolierung zwischen vertrauenswürdigen Domänencontrollern und nicht vertrauenswürdigen RODCs sichergestellt.

Zur Erläuterung des KRBTGT-Kontos: Jede Active-Directory-Domäne verfügt seit ihrer ersten Einrichtung über ein zugehöriges KRBTGT-Konto, das zum Verschlüsseln und Signieren aller Kerberos-Tickets der Domäne dient. Da es sich um ein Domänenkonto handelt, kennen alle beschreibbaren Domänencontroller das Kontopasswort, um Kerberos-Tickets zur Validierung zu entschlüsseln.

Schritt 2: Cloud Trust über Intune aktivieren

Der Weg im Intune-Portal:

Intune → Gerätekonfigurationsprofil → Plattform Windows 10 und höher → Einstellungskatalog → Create → Namen vergeben → Add Settings → nach „Hello" suchen → Kategorie Windows Hello for Business.

Dort werden zwei Einstellungen gesetzt:

1. Use Cloud Trust for On-Prem Auth
2. Use Passport for Work (aktiviert grundsätzlich, dass Windows Hello funktioniert)

Zusätzlich lassen sich viele weitere Einstellungen zu PIN-Länge etc. konfigurieren – das ist dann kundenspezifisch. Das Profil wird auf eine Gruppe (Geräte) zugewiesen.

Im Einstellungskatalog wird die Kategorie Windows Hello for Business gewählt und mindestens Use Cloud Trust for On-Prem Auth (Enabled) sowie Use Passport for Work (true) gesetzt – daneben lassen sich PIN-Länge, Biometrie und weitere Parameter feinjustieren.

Funktionsweise: Entra-Joined Gerät

Bei einem reinen Entra-Joined-Gerät läuft die Authentifizierung gegen Active Directory über Cloud Kerberos Trust wie folgt ab:

Phase A

1. Die Authentifizierung beginnt mit dem ersten Versuch des Benutzers, eine Ressource zu nutzen, die Kerberos-Authentifizierung erfordert.
2. Der Kerberos Security Support Provider (gehostet in lsass) verwendet Metadaten aus dem WHfB-Schlüssel, um einen Hinweis auf die Domäne des Benutzers zu erhalten.
3. Anhand dieses Hinweises nutzt der Provider den DClocator-Dienst, um einen Domänencontroller zu finden.

Phase B

4. Nach dem Finden eines DC sendet der Kerberos-Provider ein Teil-TGT, das er aus einer früheren Entra-Authentifizierung von Microsoft Entra ID erhalten hat, an den Domänencontroller.
5. Das Teil-TGT enthält nur die Benutzer-SID und ist von Microsoft Entra Kerberos signiert.
6. Der Domänencontroller prüft die Gültigkeit des Teil-TGTs.
7. Bei Erfolg sendet das KDC ein vollständiges TGT an den Client zurück.

Phase A: Windows ermittelt den Domain-Hint aus den Schlüssel-Metadaten und findet per DcLocator einen DC. Phase B: Das Teil-TGT wird per TGS_REQ übergeben, validiert und als vollständiges TGT zurückgegeben.

Funktionsweise: Hybrid-Joined Gerät

Beim Hybrid-Joined-Gerät ist der Ablauf umfangreicher, da die Anmeldung selbst über Windows Hello startet:

Phase A

1. Die Authentifizierung beginnt, wenn der Benutzer den Sperrbildschirm aufhebt. Winlogon zeigt daraufhin die WHfB-Anmeldung an.
2. Der Benutzer gibt seine Windows-Hello-Geste (PIN oder Biometrie) ein. Der Credential Provider sammelt diese Informationen und sendet sie an Winlogon zurück.
3. Winlogon übergibt die gesammelten Anmeldeinformationen an lsass.
4. lsass fragt die WHfB-Richtlinie ab, um zu prüfen, ob Cloud Kerberos Trust aktiviert ist.
5. Ist Cloud Kerberos Trust aktiviert, gibt lsass die Anmeldeinformationen an den Cloud Authentication Security Support Provider (Cloud AP) weiter.
6. Cloud AP fordert eine Nonce (eine einmalig definierte Zeichenfolge) von Microsoft Entra ID an.
7. Microsoft Entra ID gibt eine Nonce zurück.

Phase B

8. Cloud AP signiert die Nonce mit dem privaten Schlüssel des Benutzers und sendet die signierte Nonce an Microsoft Entra ID zurück.

Phase C

9. Microsoft Entra ID validiert die signierte Nonce mithilfe des sicher registrierten öffentlichen Schlüssels des Benutzers anhand der Nonce-Signatur.
10. Nach der Validierung der Signatur validiert Entra ID die zurückgegebene signierte Nonce.
11. Anschließend erstellt Entra ID ein PRT mit einem Sessionkey, der mit dem Transportschlüssel des Geräts verschlüsselt ist, sowie ein Teil-TGT von Microsoft Entra Kerberos, und sendet beides an Cloud AP zurück.

Phase D

12. Cloud AP empfängt das verschlüsselte PRT mit dem Sitzungsschlüssel.
13. Mit dem privaten Transportschlüssel des Geräts entschlüsselt Cloud AP den Sitzungsschlüssel und schützt ihn mit dem TPM des Geräts (falls vorhanden).
14. Cloud AP gibt eine erfolgreiche Authentifizierungsantwort an lsass zurück. lsass speichert das PRT und das partielle TGT.

Phase E

15. Der Kerberos Security Provider (in lsass) verwendet Metadaten aus dem WHfB-Schlüssel, um einen Hinweis auf die Domäne des Benutzers zu erhalten.
16. Anhand dieses Hinweises nutzt der Provider den DClocator-Dienst, um einen Domänencontroller zu finden.
17. Nach dem Finden eines aktiven DC sendet der Kerberos-Provider das Teil-TGT (nur Benutzer-SID, von Microsoft Entra Kerberos signiert) an den Domänencontroller.
18. Der Domänencontroller prüft die Gültigkeit des Teil-TGTs. Bei Erfolg sendet das KDC ein vollständiges TGT an den Client zurück.
19. Kerberos gibt das TGT an lsass zurück, wo es zwischengespeichert und für nachfolgende Service-Ticket-Anforderungen verwendet wird.
20. lsass informiert Winlogon über die erfolgreiche Authentifizierung.
21. Winlogon erstellt eine Anmeldesitzung, lädt das Benutzerprofil und startet explorer.exe.

Der vollständige Ablauf von der Windows-Hello-Geste (Phase A) über das Signieren der Nonce (B), die Validierung in Entra ID (C), das Entschlüsseln des Sessionkeys ins TPM (D) bis zum Eintausch des Teil-TGTs gegen ein vollständiges TGT am DC (E).

User Experience und Kontrolle

So erlebt der Endanwender die Einrichtung:

1. Bei der ersten Anmeldung an einem Client wird man aufgefordert, Windows Hello zu registrieren.
2. Danach wird die PIN vergeben – dabei kann direkt der MFA-Prompt erscheinen. Anschließend ist die Einrichtung abgeschlossen.

Bei der ersten Anmeldung bietet Windows optional die Gesichtserkennung an; als Fallback wird stets eine PIN eingerichtet.

Danach folgen noch zwei Schritte:

• Das Gerät muss einmal synchronisieren, damit es die Intune-Policys sowie – bei reinen Entra-Joined-Geräten – ein TGT erhält.
• Über dsregcmd /status lässt sich der aktuelle Status abfragen.

Das Gerät hat über Cloud Kerberos Trust nun ein On-Prem-TGT und ein Cloud-TGT erhalten. Damit kann man sich – ohne Passwort – gegen Kerberos-Ressourcen wie Fileserver oder SMB-Shares authentifizieren.

Funktion überprüfen

Es gibt mehrere Wege, die korrekte Funktion zu verifizieren:

• Event Viewer → User Device Registration-Log. Die Logs liegen unter Anwendungs- und Dienstprotokolle → Microsoft → Windows → User Device Registration. Zu suchen sind Events mit den Event-IDs 304, 305, 307 (und 358).
• klist cloud_debug → zeigt das verfügbare TGT an (Cloud Primary TGT Available).
• dsregcmd /status → unter SSO State sind OnPremTGT und CloudTGT auf YES verfügbar.

Zusammenfassungs-Skript: Kerberos-Account erstellen

Das folgende PowerShell-Skript fasst die Schritte zusammen, um den Cloud Kerberos Trust zu aktivieren und den Kerberos Server Encryption Key zu rotieren. Es enthält die sinnvollsten Befehle aus dem offiziellen Microsoft-Artikel zur passwortlosen Security-Key-Anmeldung on-premises:

<#
.SYNOPSIS
  Kerberos Account erstellen

.DESCRIPTION
  Zusammenfassung der Schritte, um den Cloud Kerberos Trust zu aktivieren
  und den Kerberos Server Verschlüsselungsschlüssel zu rotieren.

.NOTES
  Author:        MM
  Creation Date: 2024-04-25
#>

# First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

# Import Module
Import-Module -Name AzureADHybridAuthenticationManagement

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of an Entra ID global administrator
$userPrincipalName = "globaladmin@example.onmicrosoft.com"

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

# When prompted to provide domain credentials use the userPrincipalName
# format for the username instead of domain\username.
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

# Rotate the Entra Kerberos Server encryption key
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey

Muss der Hello-Container einmal komplett verworfen werden, hilft folgender Befehl in der Eingabeaufforderung (CMD):

certutil.exe -DeleteHelloContainer

Exkurs: Was ist ein Kerberos-Provider?

Ein Kerberos-Anbieter ist eine Instanz oder ein Dienst, der die Authentifizierungsfunktion des Kerberos-Protokolls implementiert und bereitstellt. Kerberos ist ein Netzwerk-Authentifizierungsprotokoll, das Benutzern eine sichere Authentifizierung gegenüber Diensten im Netzwerk ermöglicht. Es wurde vom MIT entwickelt und basiert auf der Idee der Tickets, die Benutzeridentitäten sicher verwalten.

Die Hauptkomponenten und Rollen:

1. Key Distribution Center (KDC) – der zentrale Bestandteil eines Kerberos-Systems, bestehend aus zwei Diensten:
   • Authentication Server (AS): authentifiziert Benutzer und stellt das Ticket Granting Ticket (TGT) aus, das zur weiteren Authentifizierung dient.
   • Ticket Granting Server (TGS): verwendet das TGT, um Service Tickets für den Zugriff auf spezifische Dienste auszustellen.
2. Kerberos-Clients – auf den Endgeräten installiert, interagieren mit dem KDC, um Authentifizierungs-Tickets zu erhalten und zu nutzen.
3. Anwendungsserver – akzeptieren und verifizieren die vom Client vorgelegten Service Tickets und gewähren so Zugang zu bestimmten Diensten.

Kerberos-Anbieter finden sich in vielen Kontexten: in Betriebssystemen (Windows mit Active Directory, macOS, diverse Linux-Distributionen) sowie in Middleware und Unternehmensanwendungen, die eigene Kerberos-Implementierungen mitbringen oder Kerberos-basierte Authentifizierung unterstützen.

Windows Hello for Business mit Cloud Kerberos Trust bringt passwortlose, phishing-resistente Anmeldung – ohne zusätzliche Zertifikatsinfrastruktur und als zentraler Baustein moderner Endpoint-Security.