Wenn du noch nie von Cloud Kerberos Trust (CKT) gehört hast, dann solltest du definitiv weiterlesen! Denn wer einmal verstanden hat, was CKT ist, wie es funktioniert und vor allem, welchen enormen Nutzen es für das Unternehmen bietet, der wird es auf jeden Fall im Unternehmen nutzen wollen.
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 beschreiben und etwas in die Tiefe gehen. Im zweiten Teil geht es dann um die Einrichtung (Folgt). Im letzten Part des Artikels beschäftige ich mich mit ein paar Problemen und wie man das Troubleshooting am effektivsten gestaltet (Folgt ebenfalls).
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:
- Biometrische Authentifizierung: Benutzer können sich per Fingerabdruck oder Kamera am Client anmelden.
- Komfort und Benutzerfreundlichkeit: Die Anmeldung und das Entsperren des Clients ist für den User sehr bequem.
- 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.
- 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:
- 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.
- Zentrale Verwaltung: Alle relevanten Einstellungen für WHfB können zentral über Intune verwaltet werden.
- Integration ins Unternehmensnetzwerk: WHfB ist so konzipiert, dass es nahtlose Anbindung ans Active Directory und andere Unternehmensressourcen ermöglicht.
- Schlüsselbasierte Authentifizierung: Anstelle von Passwörtern verwendet WHfB asynnetrische Schlüsselpare, 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
- 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.
- 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:
- 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.
- 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.
- 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 beduetet, 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:
- Es wird eine Certificate Authority (CA) benötigt, inklusive einer dem Client bekannten vollständigen Zertifikatskette vom Gerät bis zum Domain Controller.
- Es wird eine Certificate Revokation List (CRL) benötigt und muss gepflegt werden.
- SSO funktioniert nicht unmittelbar nach dem ersten Login des Users (siehe oben).
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 besser Ü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 Evulotion der verschiedenen Trust Typen aufgezeit.
In Part 2 (folgt) dieser Serie beschäftige ich mich genauer mit der Einrichtung und Konfiguration von WHfB Cloud Kerberos Trust.
