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

1. Öffne das Microsoft Intune Admin Center (https://intune.microsoft.com)
2. Navigiere zu Devices → Configuration profiles
3. Klicke auf Create profile
4. Wähle als Platform Windows 10 and later
5. Wähle als Profile type Settings catalog
6. 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:

1. Use Windows Hello for Business (Device)
   • Setze diese Einstellung auf Enabled
2. Use Cloud Trust For On Premises Auth
   • Setze diese Einstellung auf Enabled
3. 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!

Referenzen und weiterführende Links

Dieser Artikel basiert auf den offiziellen Microsoft Learn Dokumentationen:

• Windows Hello for Business cloud Kerberos trust deployment guide – Offizielle Deployment-Anleitung von Microsoft
• Introduction to Microsoft Entra Kerberos – Technische Details zu Microsoft Entra Kerberos
• Configure a tenant-wide Windows Hello for Business policy with Microsoft Intune – Intune-Konfigurationsanleitung
• Plan a Windows Hello for Business Deployment – Planungsleitfaden für Windows Hello for Business

Der Beitrag Windows Hello for Business SSO – Cloud Kerberos Trust – Part 2 erschien zuerst auf M365 Blog - Julian Stabentheiner.

CKT ist die aktuell letzte Ausbaustufe der Single-Sign-On (SSO) Lösungen für Windows Clients.

In diesem ersten Artikel zum Thema Cloud Kerberos Trust möchte ich zunächst die Grundlagen beschreiben und etwas in die Tiefe gehen. Im zweiten Teil geht es dann um die Einrichtung. Im letzten Part des Artikels beschäftige ich mich mit ein paar Problemen und wie man das Troubleshooting am effektivsten gestaltet (Folgt).

Windows Hello for Business? Was ist das überhaupt?

Windows Hello for Business (WHfB) ist eine im Unternehmensumfeld genutzte Technologie, um die Anmeldung an einem Windows Client für den Benutzer möglichst einfach und sicher zu gestalten.

Es gibt einige Gemeinsamkeiten mit dem im Consumer-Bereich genutzten Windows Hello (WH). Diese beschränken sich jedoch überwiegend auf die für den Benutzer sichtbaren Authentifizierungsmethoden.

Hauptmerkmale von Windows Hello (for Business)

Grundsätzlich basieren WHfB sowie WH auf folgende vier Hauptmerkmalen:

1. Biometrische Authentifizierung: Benutzer können sich per Fingerabdruck oder Kamera am Client anmelden.
2. Komfort und Benutzerfreundlichkeit: Die Anmeldung und das Entsperren des Clients ist für den User sehr bequem.
3. Sicherheit: Biometrische Daten werden lokal auf dem Gerät (muss eine TPM-Chip haben) gespeichert und nicht in die Cloud hochgeladen. Passwörter können bei der Anmeldung am Client nicht abgegriffen werden. Sogenanntes Shoulder Surfing (Abgreifen von Informationen durch direktes Zuschauen) wird damit großteils unterbunden, da sich der Benutzer nur biometrisch am Client anmeldet.
4. Integration: Windows Hello ist vollständig in Windows 10/11 integriert und muss nicht gesondert installiert, sondern nur konfiguriert werden.

Skepsis gegenüber Biometrischer Authentifizierung

Häufig begegnet mir die Sorge von Kunden, dass biometrische Daten bei WHfB abgegriffen werden könnten. Diese Angst führt oft dazu, dass weiterhin auf die weniger sichere Anmeldung mittels Benutzername und Passwort gesetzt wird.

Diese Bedenken sind unbegründet, da biometrische Daten bei WHfB verschlüsselt im TPM-Chip des Geräts gespeichert werden, was insgesamt eine höhere Sicherheit bietet. Es bedarf oft zusätzlicher Erklärungen, um diese Vorteile verständlich zu machen und Vorbehalte abzubauen. Sobald jedoch die Funktionsweise und Sicherheitsvorteile von WHfB klar sind, entscheiden sich die meisten Kunden für dessen Einsatz.

Erweiterte Features für Unternehmen

Die oben genannten Funktionen werden durch den Zusatz „for Business“ so ergänzt, dass die speziellen Anforderungen für Unternehmen bedient werden und eine passwortlose Anmeldung am Client ermöglicht wird. Folgende Zusatzfeatures bietet WHfB zusätzlich:

1. Multifaktor-Authentifizierung: Die biometrischen Daten werden durch einen PIN-Code ergänzt, um eine starke Authentifizierung zu gewährleisten. Eine Anmeldung an einem Unternehmensgerät mittels WHfB ist gleichzusetzen mit einer Anmeldung mittels MFA.
2. Zentrale Verwaltung: Alle relevanten Einstellungen für WHfB können zentral über Intune verwaltet werden.
3. Integration ins Unternehmensnetzwerk: WHfB ist so konzipiert, dass es nahtlose Anbindung ans Active Directory und andere Unternehmensressourcen ermöglicht.
4. Schlüsselbasierte Authentifizierung: Anstelle von Passwörtern verwendet WHfB asymmetrische Schlüsselpaare, um die Identität des Benutzers zu bestätigen. Diese Schlüsselpaare werden auf dem TPM-Chip des Rechners gespeichert. Der private Schlüssel verlässt niemals das Gerät und ist einmalig für jedes Gerät erstellt. Das macht WHfB so sicher.

Grundsätzlich kann man sagen, dass Passwörter unsicher sind. Identitätsdiebstahl spielt eine immer größere Rolle und ist gerade im Unternehmensumfeld eine der höchsten Sicherheitsherausforderungen.

WHfB ermöglicht es den Usern sich stets mit einer „starken“ Authentifizierung am Gerät anzumelden, ohne sich der ständigen Gefahr des Passwortdiebstahls auszusetzen. Selbst wenn der PIN gestohlen werden würde, würde dieser nur an diesem Gerät funktionieren und nicht wie das Passwort von überall. In einem solchen Fall kann gezielt nur die Authentifizierungsmethode des gestohlenen Clients deaktiviert werden.

Der Identityprovider (IDP) – hier Microsoft Entra – hat stets einen Teil des öffentliches Schlüssels, der bei der Einrichtung von WHfB zum Useraccount zugeordnet wird. Jeder durch den IDP ausgestellte Token funktioniert somit nur für das Gerät, für den er ausgestellt wurde. Sollte dieser abgefangen werden, ist dieser für den Angreifer nutzlos. WHfB ist dadurch „Phishing Resistent“ im Gegensatz zu einfachen One Time Passwords, die auch (kurzfristig) für andere Anmeldungen genutzt werden können, sofern Benutzername und Passwort ebenfalls bekannt sind.

WHfB ist eine sehr sichere Alternative zu Passwörtern. Es muss allerdings darauf geachtet werden, dass WHfB auch passend konfiguriert wird. Auch muss die Nutzungsrichtlinie den Nutzern vorschreiben, dass biometrische Methoden vorzugsweise genutzt werden. Denn wer immer die PIN benutzt, und vielleicht auch noch auf all seinen Geräten dieselbe PIN verwendet, der macht das Gerät wieder anfällig für „Shoulder Surfing“, wenn gleichzeitig das Gerät entwendet wird (z.B. im Zug). Die PIN sollte zudem nicht nur vier Nummern lang sein. Das kann aber in der WHfB Policy definiert werden.

SSO mit WHfB – Der Trust

Richtig interessant wird WHfB, wenn noch On-premises Ressourcen genutzt werden sollen. Dann stellt sich nämlich die Frage, wie der Client bzw. Benutzer ein Kerberos-Ticket bekommt, um sich z.B. an einem Fileserver, Proxyserver oder Printserver zu authentifizieren.

Unterschiede zu herkömmlicher Kerberos-Authentifizierung

1. Klassische Kerberos Anmeldung: Um an ein Kerberos Ticket zu kommen, muss der Client bei der klassischen Anmeldung seine Benutzername/Passwort-Kombination einem Domaincontroller präsentieren, um von ihm ein Kerberos Ticket ausgestellt zu bekommen. Dieses Token kann nun genutzt werden, um sich an weiteren Diensten im Netzwerk anzumelden.
2. WHfB Anmeldung: Wird der Client allerdings für WHfB konfiguriert ist, dann gibt der User beim Login nicht mehr seine Benutzername/Passwort-Kombination ein, sondern authentifiziert sich per biometrischem Merkmal bzw. als Fallback mit PIN. WHfB erstellt dann ein Schlüsselpaar, dass zur Authentifizierung an Entra genutzt werden kann. Mit diesen Daten kann der Domaincontroller nichts anfangen. Wir benötigen also eine Möglichkeit, an ein Kerberos Ticket zu kommen. Hier kommt der Trust ins Spiel. Mit dem zuvor ausgestellten Schlüsselpaar kann der User über Entra ein Kerberos-Ticket vom Domaincontroller der On-premises Infrastruktur ausgestellt bekommen und sich gleichermaßen an Cloud sowie On-premises Ressourcen anmelden, ohne dass der Benutzer sein Passwort eingeben muss. Details zur Funktionsweise und den unterschiedlichen Trust Typen folgen später.

Vorteile von Windows Hello for Business bei der Nutzung von SSO

Windows Hello for Business bietet erhebliche Vorteile, wenn es um die Integration von Single Sign-On (SSO) in Unternehmensumgebungen geht, die sowohl Cloud-basierte als auch On-Premises Ressourcen nutzen:

1. Gleichzeitige Integration mit Entra ID (Azure ID) und Active Directory: Am Client meldet man sich mit seinem (Hybrid) Entra Account an und bekommt für beide Directorys Authentifizierungsmerkmale ausgestellt.
2. Erhöhte Sicherheit: WHfB entspricht einer Multi-Faktor-Authentifizierung und bietet somit eine zusätzliche Sicherheitsebene für die Ausstellung eines Kerberos-Tickets. Klassisches Kerberos ist durch kompromittierte Passwörter anfällig für Angriffe.
3. Komfort: Es ist keine Zusätzliche Anmeldung an On-premises Diensten mehr nötig und die User können effektiver arbeiten.

Voraussetzungen für den Trust

Um einen Trust einzurichten, benötigen wir synchronisierte Hybrid-Identitäten. Das bedeutet, Entra Accounts, die mittels Entra Connect vom Active Directory Richtung Entra synchronisiert wurden. Dies wird benötigt, damit ein Kerberos-Ticket für den On-Premises AD Account ausgestellt werden kann.

WHfB mit Key Trust – Ein Rückblick

Einige Firmen haben in Vergangenheit bereits die inzwischen durch Cloud Kerberos Trust abgelöste Technologie Key Trust eingesetzt. Bei dieser Technik liegt das größte Problem bei der Ersteinrichtung und dem komplexeren technischen Hintergrund.

Bei der Inbetriebnahme von WHfB finden im Hintergrund einige Tasks statt, von denen der User nichts mitbekommt. Durch den Entra Connect Sync vergeht etwas Zeit, bis sich der Benutzer nach Einrichtung an lokalen Ressourcen anmelden kann. Dies liegt daran, da die im Entra ausgestellten Next Generation Credentials (NGC) erst beim nächsten Sync (dieser läuft im Standard alle 30 Minuten) Richtung Active Directory synchronisiert werden. Das zuständige Attribut heißt msDS-KeyCredentialLink. Solange dies noch nicht gefüllt ist, wird kein Kerberos Ticket auf dem Client landen.

Um den Ablauf aber besser zu verstehen, schauen wir uns nachfolgendes Diagramm an:

Neben Key Trust wurde auch Certificate Trust eingesetzt. Darauf möchte ich aber nicht genauer eingehen. Die Ausführungen zu Key Trust sollen lediglich die Probleme des Systems zeigen, um die Unterschiede zu Cloud Kerberos Trust zu verstehen und sind recht ähnlich beim Certificate Trust vorhanden.

Key Trust Probleme

Es ergeben sich folgende Nachteile des veralteten Key Trust:

• Domänencontroller benötigen spezielle Zertifikate für die Authentifizierung, die verteilt und verwaltet werden müssen.
• Die öffentlichen Schlüssel müssen zwischen Entra ID und Active Directory synchronisiert werden, was zu Verzögerungen führt.
• SSO funktioniert nicht unmittelbar nach dem ersten Login des Users, sondern erst nach dem nächsten Entra Connect Sync (standardmäßig 30 Minuten).

Hinweis: Certificate Trust hat ähnliche Probleme, benötigt aber zusätzlich eine vollständige PKI-Infrastruktur mit Certificate Authority (CA) und Certificate Revocation List (CRL).

Cloud Kerberos Trust – Der Goldstandard

Die vorangegangene Authentifizierungsmethoden haben alle Ihre Nachteile. Das wusste auch Microsoft und hat eine Methode entwickelt, die für den User und Admin möglichst einfach zu konfigurieren ist.

Eine Herausforderung lag darin, die Abhängigkeit von der Synchronisierung der Anmeldeinformationen aufzulösen und die Konfiguration der vielen Komponenten zu vereinfachen.

Entra Kerberos (vormals Azure AD Kerberos)

Entra Kerberos wurde eingeführt, um FIDO2 Authentifizierung an Hybrid Azure AD Joined (HAADJ) zu ermöglichen. Es wird ein Kerberos-Ticket von Entra statt dem On-Premises AD ausgestellt. Somit erhält der Client ein Ticket Granting Ticket (TGT) inklusive Primary Refresh Token (PRT) von Entra.

Daraus resultieren folgende Vorteile:

• Es müssen keine öffentliche Schlüssel mehr zwischen Entra und AD synchronisiert werden. Demnach keine Verzögerung nach der Inbetriebnehme.
• Es muss keine PKI dafür erstellt oder erweitert werden.
• Passwortlose Anmeldung an allen Ressourcen ohne Verzögerungen wird mit wenigen Konfigurationsschritten erstmals möglich.
• Die On-premises DCs werden stark entlastet, da die Ticketausstellung nun von Entra übernommen wird. Das zeigt überwiegend in größeren Firmen einen Effekt, da weniger DCs benötigt werden.

Wir haben also eine Vertrauenskette, die als Kernkomponente Entra (Azure AD) hat. Es wird also kein Kerberos Ticket mehr vom On-premises AD selbst ausgestellt, sondern die On-premises Ressourcen vertrauen jetzt dem Entra Kerberos Ticket.

Vergleich der Trust Typen

Für die bessere Übersichtlichkeit kann man in der nachfolgenden Tabelle die Unterschiede zusammengefasst vergleichen.

Trust Type	Beschreibung
Cloud Kerberos Trust	Benutzer authentifizieren sich bei Active Directory, indem sie ein TGT von Microsoft Entra ID unter Verwendung von Microsoft Entra Kerberos anfordern. Die lokalen Domänencontroller sind nach wie vor für die Kerberos-Diensttickets und die Autorisierung zuständig. Cloud Kerberos Trust nutzt dieselbe Infrastruktur, die für die Anmeldung mit FIDO2-Sicherheitsschlüsseln erforderlich ist, und kann für neue oder bestehende Windows Hello for Business-Bereitstellungen verwendet werden.
Key Trust	Benutzer authentifizieren sich beim lokalen Active Directory mit einem gerätegebundenen Schlüssel (Hardware oder Software), der während der Windows Hello-Bereitstellung erstellt wird. Es ist erforderlich, Zertifikate an Domänencontroller zu verteilen.
Certificate Trust	Der Certificate Trust stellt Authentifizierungszertifikate für Benutzer aus. Benutzer authentifizieren sich mit einem Zertifikat, das mit einem gerätegebundenen Schlüssel (Hardware oder Software) angefordert wurde, der während der Windows Hello-Bereitstellung erstellt wurde.

WHfB Cloud Kerberos Authentifizierungsworkflow

Wollen wir uns nun einmal in der Tiefe ansehen, wie die Authentifizierung im Endausbau funktioniert. Sobald ein User versucht auf eine On-premises Ressource zuzugreifen, läuft folgender Prozess ab:

• Da der User weiterhin ein synchronisierter Hybrid User sein muss, sind die Informationen zur On-premises Domain im Useraccount enthalten. Diese Information wird benötigt, um den Domainnamen für das Anfordern von Tickets vom KDC zu identifizieren.
• Der Prozess startet erst, wenn der User das erste mal versucht auf eine On-premises Ressource zuzugreifen.
• Mit den Metadaten aus dem WHfB Schlüssel kann der Domainname identifiziert werden.
• Über den DCLocator Service kann nun der nächstgelegene Domaincontroller mit KDC Dienst identifiziert werden.
• Mit dem von Entra erstellten partiellen TGT wendet sich der Client nun an den Domain Controller.
• Dieses partielle TGT ist von Entra signiert und enthält die SID des Users.
• Der Domain Controller verfiziert nun, ob das partielle TGT valide ist.
• Ist die Prüfung erfolgreich, wird vom Domain Controller ein vollwertiges TGT für den User ausgestellt und dieser kann sich damit an anderen On-premises Diensten anmelden.

Zusammengefasst erstellt Entra ein partielles TGT für den User. Dieses kann nun an einem KDC gegen ein vollwertiges TGT eingetauscht werden mit dem dann Service Tickets an den einzelnen Diensten ausgestellt werden können.

Zusammenfassung

Wir haben gelernt, was Windows Hello for Business vom Consumer Produkt Windows Hello unterscheidet und wie es im Detail funktioniert. Zusätzlich wurde die genaue Funktionsweise von WHfB erklärt und die Evolution der verschiedenen Trust Typen aufgezeigt.

Im zweiten Teil dieser Serie beschäftige ich mich genauer mit der Einrichtung und Konfiguration von WHfB Cloud Kerberos Trust.

Referenzen und weiterführende Links

Dieser Artikel basiert auf den offiziellen Microsoft Learn Dokumentationen und Praxiserfahrungen:

• Plan a Windows Hello for Business Deployment – Planungsleitfaden und Übersicht der Trust-Typen
• Windows Hello for Business cloud Kerberos trust deployment guide – Offizielle Deployment-Anleitung
• Introduction to Microsoft Entra Kerberos – Technische Details zu Microsoft Entra Kerberos
• Windows Hello for Business Overview – Allgemeine Übersicht und Features

Der Beitrag Windows Hello for Business SSO – Cloud Kerberos Trust – Part 1 erschien zuerst auf M365 Blog - Julian Stabentheiner.