Windows Hello for Business SSO – Cloud Kerberos Trust – Part 2 - M365 Blog

Nachdem wir im ersten Teil dieser Serie die Grundlagen und Konzepte von Windows Hello for Business mit Cloud Kerberos Trust behandelt haben, widmen wir uns nun der praktischen Umsetzung. In diesem Teil zeige ich dir Schritt für Schritt, wie du Cloud Kerberos Trust in deiner Umgebung einrichtest und konfigurierst.

Voraussetzungen

Bevor wir mit der Konfiguration starten, solltest du sicherstellen, dass deine Umgebung die folgenden Voraussetzungen erfüllt:

Client-Betriebssystem: Windows 10 oder Windows 11 mit Pro/Enterprise Edition
Geräte: (Hybrid) Azure AD joined Geräte
Active Directory: Domain und Forest Functional Level mindestens Windows Server 2008 R2
Domain Controller: Read-Write Domain Controller (RWDC) in jedem Active Directory-Standort erforderlich – RODC reicht nicht aus
Entra ID Connect: Bereits implementiert und funktionsfähig
Berechtigungen: Globaler Administrator für Entra ID sowie Domänen-Administrator für das lokale Active Directory
Netzwerk: Konnektivität zwischen Clients und Domain Controllern
TLS 1.2: Aktiviert auf dem Verwaltungssystem

Wichtige Einschränkung: Benutzer, die Mitglieder von privilegierten integrierten Sicherheitsgruppen sind (z.B. Domain Admins, Enterprise Admins), können Cloud Kerberos Trust nicht verwenden. Dies ist eine Sicherheitsmaßnahme, um potenzielle Angriffsvektoren von Microsoft Entra ID zum lokalen Active Directory zu verhindern. OnPrem Admin-Konten sollten allerdings grundsätzlich nicht mit Entra ID Accounts synchronisiert werden.

Konfiguration und Einrichtung

Die Einrichtung ist erfreulich unkompliziert und besteht im Wesentlichen aus drei Hauptschritten: der Aktivierung des Microsoft Entra Kerberos Servers, der Bereitstellung der entsprechenden Intune-Policy und der abschließenden Validierung. Damit ist Cloud Kerberos Trust deutlich einfacher zu implementieren als die älteren Key Trust oder Certificate Trust Methoden.

Schritt 1: Microsoft Entra Kerberos aktivieren

Der erste Schritt besteht darin, Microsoft Entra Kerberos zu aktivieren. Dieses fungiert als Read-Only Domain Controller (RODC) in deinem lokalen Active Directory und ermöglicht die Ausstellung von Kerberos-Tickets basierend auf der Cloud-Authentifizierung.

PowerShell-Modul installieren

Zunächst benötigst du das PowerShell-Modul AzureADHybridAuthenticationManagement. Öffne eine PowerShell-Sitzung mit Administratorrechten und führe folgenden Befehl aus:

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Falls noch nicht geschehen, stelle sicher, dass TLS 1.2 aktiviert ist:

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

Kerberos Server konfigurieren

Nach der Installation des Moduls kannst du den Microsoft Entra Kerberos Server einrichten. Führe die folgenden Befehle aus – am besten vom Entra ID Connect Server aus:

$domain = $env:USERDNSDOMAIN
$userPrincipalName = "admin@deintenant.onmicrosoft.com"
$domainCred = Get-Credential

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

Du wirst aufgefordert, dich mit deinen Domänen-Administrator-Anmeldeinformationen und anschließend mit deinen Entra ID Anmeldeinformationen zu authentifizieren. Der Befehl erstellt ein RODC-Objekt in deinem Active Directory sowie ein entsprechendes krbtgt-Konto.

Wichtiger Hinweis: Das krbtgt-Konto ist standardmäßig deaktiviert – das ist beabsichtigt und korrekt so. Es dient lediglich als Platzhalter für die Cloud-basierte Kerberos-Ticketausstellung.

Konfiguration verifizieren

Um zu überprüfen, ob die Einrichtung erfolgreich war, führe folgenden Befehl aus:

Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Du solltest nun die Details des Microsoft Entra Kerberos Servers sehen, einschließlich der Domain, des Cloud-Objekts und des Erstellungsdatums. Zusätzlich kannst du in deinem Active Directory unter den Domain Controllers das neue RODC-Objekt mit dem Namen „AzureADKerberos“ finden.

Schritt 2: Intune-Policy konfigurieren

Der zweite Schritt besteht darin, Windows Hello for Business mit Cloud Kerberos Trust über eine Intune-Policy auf den Geräten zu aktivieren. Hierfür verwenden wir den Settings Catalog in Microsoft Intune.

Settings Catalog Policy erstellen

Öffne das Microsoft Intune Admin Center (https://intune.microsoft.com)
Navigiere zu Devices → Configuration profiles
Klicke auf Create profile
Wähle als Platform Windows 10 and later
Wähle als Profile type Settings catalog
Vergib einen aussagekräftigen Namen wie „Windows Hello for Business – Cloud Kerberos Trust“

Erforderliche Einstellungen hinzufügen

Sofern nicht schon geschehen, muss Windows Hello for Business (WhfB) aktiviert werden. Hier einmal im Schnelldurchlauf:

Im Settings Catalog suchst du nach „Windows Hello for Business“ und fügst die folgenden Einstellungen hinzu:

Use Windows Hello for Business (Device)
- Setze diese Einstellung auf Enabled
Use Cloud Trust For On Premises Auth
- Setze diese Einstellung auf Enabled
Use a hardware security device (Optional, aber empfohlen)
- Setze diese Einstellung auf Enabled oder Required
- Erzwingt die Verwendung von TPM (Trusted Platform Module) für zusätzliche Sicherheit

Hinweis: Die Bezeichnungen der Einstellungen haben sich im Laufe der Zeit geändert. In älteren Portal-Versionen hießen sie „Use Passport for Work“ und „Use Cloud Trust For On Prem Auth“. Die Funktionalität ist jedoch identisch.

Policy zuweisen

Weise die Policy den gewünschten Benutzer- oder Gerätegruppen zu. Nach der Zuweisung wird die Policy beim nächsten Check-in der Geräte ausgerollt.

Schritt 3: Testing und Validierung

Nachdem beide Konfigurationsschritte abgeschlossen sind, ist es Zeit, die Implementierung zu testen und zu validieren.

Policy-Anwendung überprüfen

Auf einem Client-Gerät kannst du im Event Viewer unter Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin nach der Event ID 358 suchen. Dieses Event bestätigt, dass die Policy erfolgreich angewendet wurde.

Alternativ kannst du in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork prüfen, ob der Wert UseCloudTrustForOnPremAuth auf 1 gesetzt ist.

DSREGCMD zur Validierung nutzen

Das wichtigste Tool zur Validierung ist DSREGCMD. Öffne eine Eingabeaufforderung und führe folgende Befehle aus:

DSREGCMD /REFRESHPRT
DSREGCMD /STATUS

In der Ausgabe solltest du im Abschnitt SSO State folgende Werte sehen:

AzureAdPrt : YES
AzureAdPrtUpdateTime : [Zeitstempel]
AzureAdPrtExpiryTime : [Zeitstempel]
CloudTgt : YES
OnPremTgt : YES

Wenn sowohl CloudTgt als auch OnPremTgt auf YES stehen, funktioniert Cloud Kerberos Trust einwandfrei. Das Cloud TGT wird von Entra ID ausgestellt, während das On-Premises TGT vom lokalen Domain Controller bereitgestellt wird.

Kerberos-Tickets überprüfen

Mit dem Befehl klist cloud_debug kannst du zusätzlich die Details der Kerberos-Tickets einsehen und überprüfen, ob sowohl Cloud- als auch On-Premises-Tickets vorhanden sind.

Troubleshooting: Häufige Probleme und Lösungen

Trotz der einfachen Implementierung kann es zu einigen typischen Problemen kommen. Hier sind die häufigsten Herausforderungen und deren Lösungen:

CloudTgt zeigt NO

Problem: Das Cloud TGT wird nicht ausgestellt.
Lösung: Führe DSREGCMD /REFRESHPRT aus, um das Primary Refresh Token manuell zu aktualisieren. Dadurch wird ein neues Cloud TGT von Entra ID angefordert.

OnPremTgt zeigt NO

Problem: Das On-Premises TGT wird nicht ausgestellt.
Lösung:

Überprüfe, ob die Policy korrekt angewendet wurde (Event ID 358)
Stelle sicher, dass das Gerät die Mindestanforderungen erfüllt (Windows 10 oder Windows 11)
Prüfe die Netzwerkkonnektivität zum Domain Controller
Verifiziere, dass der Microsoft Entra Kerberos Server korrekt im Active Directory registriert ist

Policy wird nicht angewendet

Problem: Die Intune-Policy scheint nicht anzukommen.
Lösung:

Bestätige, dass beide erforderlichen Einstellungen im Settings Catalog vorhanden sind
Überprüfe die Gruppenzuweisungen
Warte auf den nächsten Check-in oder erzwinge eine Synchronisation über das Intune-Portal
Prüfe im Intune-Portal unter Device Configuration, ob Konflikte mit anderen Policies bestehen

Fehler „Operation not supported“ beim Set-AzureADKerberosServer

Problem: Der PowerShell-Befehl schlägt mit einer Fehlermeldung fehl.
Lösung:

Führe den Befehl vom Entra ID Connect Server aus, nicht direkt vom Domain Controller
Stelle sicher, dass du über die erforderlichen Administratorrechte verfügst
Bei Child Domains verwende dedizierte Domänen-Administrator-Anmeldeinformationen für die jeweilige Domain

Certificate Trust wird statt Cloud Kerberos Trust verwendet

Problem: Trotz korrekter Konfiguration wird Certificate Trust statt Cloud Kerberos Trust verwendet.
Lösung:

Kritisch: Wenn die Einstellung „Use certificate for on-premises authentication“ aktiviert ist, hat Certificate Trust Priorität vor Cloud Kerberos Trust
Diese Einstellung muss auf Not configured gesetzt sein
Prüfe sowohl Intune-Policies als auch Group Policies auf diese Einstellung
Nach der Änderung: Gerät neu starten und Windows Hello neu registrieren

Zusammenfassung und Ausblick

Cloud Kerberos Trust bietet eine elegante und moderne Lösung für Single Sign-On in hybriden Umgebungen. Die Implementierung ist im Vergleich zu älteren Trust-Methoden deutlich vereinfacht:

Keine PKI erforderlich – im Gegensatz zu Certificate Trust
Keine Synchronisierungsverzögerungen – im Gegensatz zu Key Trust
Minimaler Konfigurationsaufwand – nur drei Hauptschritte notwendig
Native Cloud-Integration – nahtlose Integration mit Entra ID und Intune

Mit der Aktivierung von Microsoft Entra Kerberos und der Bereitstellung der entsprechenden Intune-Policy hast du die Grundlage für eine sichere, passwortlose Authentifizierung gelegt, die sowohl Cloud- als auch On-Premises-Ressourcen abdeckt.

In Teil 3 dieser Serie (folgt) werden wir uns mit erweiterten Szenarien und Best Practices beschäftigen, einschließlich Multi-Forest-Umgebungen, Monitoring und Reporting sowie der Migration von bestehenden Trust-Modellen zu Cloud Kerberos Trust.

Hast du Fragen oder Anregungen zu diesem Artikel? Schreib mir gerne in den Kommentaren!