Windows Hello for Business für Active Directory – Aufbau

Immer mehr Unternehmen möchten auf Windows Hello for Business im eigenen Corporate Netzwerk setzen. Dabei ist vielen allerdings gar nicht klar, was Windows Hello for Business überhaupt ist und wie es sich in eine bereits bestehende Active Directory Umgebung integrieren lässt. Worin besteht eigentlich der Unterschied zwischen Windows Hello und Windows Hello for Business? In diesem Beitrag schauen wir uns die Grundsäulen von Windows Hello for Business an und zeigen anhand einer Schritt für Schritt Anleitung, wie es im Active Directory verwendet werden kann.

Windows Hello for Business Übersicht

Einleitung

Jeder kennt es: um sich im Corporate Netzwerk zu authentifizieren, benötigt man einen Nutzernamen und ein Kennwort. Mithilfe des Kennworts, welches im Optimalfall nur der Besitzer kennt, authentifiziert sich dieser gegenüber dem Active Directory. Das System hat sich in den letzten Jahrzehnten bewehrt, welche Vorteile erhoffen wir uns nun mit Windows Hello for Business?

Man stelle sich, dass die Zugangsdaten eines Nutzers über einen Leak an die Öffentlichkeit gelangen. Jeder Dritte, der Zugriff auf diesen Leak hat, könnte die Zugangsdaten nutzen, um sich innerhalb des Active Directories zu authentifizieren. Genau an dieser Stelle würde Windows Hello for Business Abhilfe schaffen. Warum das so ist, schauen wir uns im nächsten Kapitel näher an.

Funktionsweise

Windows Hello for Business setzt bei der Authentifizierung auf zwei Kernkomponenten:

• einem kryptografischen Keypair (Asymmetrisches Schlüsselpaar)
• PIN oder biometrisches Merkmal

Der Private-Key wird dabei im TPM 2.0 Modul des Geräts (falls vorhanden) oder am OS abgelegt. Zugriff auf diesen Key wird jedoch nur gewährt, wenn der Benutzer sich zuvor mit einer der folgenden Methoden am System authentifiziert hat:

• Gesichtserkennung
• Fingerabdruck
• PIN

Dabei verlässt der Private Key niemals den Client. Es werden ausschließlich Authenticiation Requests lokal (also direkt am Gerät) mit dem Private Key signiert. Nach erfolgter Authentifizierung gegenüber dem Active Directory (oder dem Azure AD) erhält der Client einen Authentication Token welcher wiederum zur Authentifizierung bei anderen Diensten verwendet werden kann.

Wo genau liegt nun der Vorteil? Wie oben angesprochen besteht Windows Hello for Business immer aus zwei Komponenten, dem Schlüsselpaar und dem biometrischen Merkmal oder PIN. Da das biometrische Merkmal und die PIN mit dem Schlüsselpaar verknüpft sind und der Private Key ausschließlich auf diesem Client gespeichert wird, müssen immer beide Faktoren vorhanden sein, damit eine Authentifizierung stattfinden kann. Man kann dieses Konstrukt auch mit seiner Bankomatkarte vergleichen: Selbst wenn die vierstellige PIN bekannt wäre, bräuchte ein Angreifer trotzdem die Bankomatkarte, um damit bezahlen zu können. Somit wäre ein Leak des PINs im Internet nicht weiter schlimm, solange der Angreifer keinen physischen Zugriff auf den Client selbst bekommt.

Es gibt auch noch einen weiteren Vorteil: Verwendet der Client nun den bereitgestellten Authentication Token, anstelle des Kennworts, um sich bei weiteren Services im Unternehmensnetzwerk zu authentifizieren, besteht ebenfalls nicht die Möglichkeit eines Leaks. Hätte sich der Nutzer im Gegensatz mit seinem Kennwort authentifiziert bestünde sehr wohl die Möglichkeit, das Kennwort abzugreifen.

Weiterführende Informationen zu der Funktionsweise: Windows Hello for Business Overview (Windows) | Microsoft Learn

Verfügbarkeit

Es passiert zwar selten aber Microsoft hat in diesem Bereich wirklich gute Arbeit geleistet. Der Fokus wurde nicht nur auf Cloud-Services gelegt, sondern Windows Hello for Business ist unter anderem auch in On-Premises-Only Umgebungen verfügbar. Somit werden Organisationen nicht erneut in ein hybrides Szenario gedrängt, auch wenn das Deployment in einer reinen lokalen Umgebung durchaus aufwendiger sein kann.

Windows Hello for Business ist mit folgenden Konstellationen abbildbar:

• Cloud-Only (Azure AD)
• Hybrid (Active Directory mit Azure AD Sync)
• On-Premises-Only (mittels AD und ADFS)

Dadurch sollte sich WHfB in jegliche Infrastruktur integrieren lassen. In dem weiteren Verlauf konzentrieren wir uns auf das Hybride Deployment, da dies wohl den größten Anklang finden wird.

Trust-Model

Wir haben uns jetzt schon über die wichtigsten Schnittstellen von Windows Hello for Business unterhalten. Nun müssen wir uns noch ein weiteres wichtiges Thema anschauen: den Vertrauensmodellen (Trust Models).

Im Grunde gibt es dabei drei relevante Modelle:

• Key Trust Model
• Certificate Trust Model
• Cloud Kerberos Trust

Welches Modell gewählt werden soll, hängt stark von der bestehenden Infrastruktur ab. Kurz gesagt: Besitzt das Unternehmen eine redundante ADFS Umgebung und jedem User wird bereits ein User-Zertifikat ausgestellt, dann sollte das Certificate Trust Model gewählt werden. Möchte man auf diesen Overhead verzichten, ist das Key Trust Model die richtige Wahl.

Wenn man noch stärker auf das Azure AD setzen möchte, kann auch der Cloud Kerberos Trust eingesetzt werden. Da hierbei allerdings jeder Logon im Azure AD authentifiziert werden muss, rate ich persönlich davon ab. Domain Clients sollten sich meiner Meinung nach auch am Domain Controller und nicht im Azure AD authentifizieren. Wem dieser Fakt egal ist, kann durchaus auf diese Variante setzen, da es das Deployment noch etwas vereinfacht.

In den meisten Fällen werden ADFS Farmen und User Zertifikaten nur in sehr großen oder sehr sicheren Umgebungen ausgerollt und gewartet. Somit dürfte für den Großteil der Unternehmen das Key Trust Model die richtige Wahl sein und wir konzentrieren uns auch in diesem Beitrag darauf.

Eine genauere Deployment Übersicht kann auch wieder direkt aus den Microsoft Docs entnommen werden.

Registrierungs- & Authentifizierungs-Flow

Dieser Artikel richtet sich vor allem an die Integration von Windows Hello for Business im On-Premises Bereich. Daher erläutere ich in dem Fall auch nur den Registrierungs- und Authentifizierungs-Flow zu einer hybriden Active Directory Umgebung mit dem Key Trust Model.

Damit Windows Hello for Business funktioniert, sind zwei grundlegende Schritte notwendig:

• Device Registration – dabei wird das Gerät im Azure AD für WHfB registriert. In einem hybriden Deployment ist dabei eine Verbindung zu den Microsoft Servern zwingend erforderlich. Sobald die Registrierung des Clients im Azure AD abgeschlossen ist, werden die dadurch generierten Informationen durch den Azure AD Connect in das On-Premises Active Directory synchronisiert.
• Authentication – jedes Mal, wenn sich der Nutzer am Gerät anmeldet findet natürlich auch eine Authentifizierung am Domain Controller via Kerberos statt. Da die WHfB Informationen nach der Registrierung ins lokale Active Directory geschrieben worden sind, muss der Client dafür auch nicht mehr mit dem Azure AD kommunizieren.

Der genaue Ablauf sieht dabei wie folgt aus:

Der Prozess startet, indem der Nutzer sich entweder mit dem PIN oder seinem biometrischen Merkmal am Sperrbildschirm authentifiziert.

1. Der Kerberos Provider sucht innerhalb der Umgebung nach einem Domain Controller (KDC Rolle).
2. Anschließend sendet der Kerberos Provider die vor-authentifizierten Daten (inkl. Public Key des Users) zum Domain Controller.
3. Der Domain Controller validiert den Public Key im Active Directory und prüft, ob der UPN übereinstimmt. Falls dem so ist, generiert dieser ein TGT (Ticket Granting Ticket) und schickt es dem Client.
4. Der Kerberos Provider prüft, ob er dem Domain Controller vertrauen kann (anhand des Zertifikats des Domain Controllers).
5. Das Ticket wird anschließend zum Local Security Authority Service (LSA) weitergereicht. Dort bleibt es für zukünftige Authentifizierungsanfragen gespeichert.
6. Winlogon erstellt eine User Session und der Desktop wird geladen. Der Nutzer hat sich nun erfolgreich mittels Windows Hello for Business authentifiziert.

Wenn dir diese High-Level Beschreibung zu schnell ging, kannst du dir auch noch die detailliertere Dokumentation von Microsoft dazu ansehen.

Windows Hello vs Windows Hello for Business

Vielleicht hattest du bereits ein Microsoft Surface Gerät im Einsatz oder verwendest auf deinem privaten Gerät Windows Hello. Auch wenn die beiden Features zum Verwechseln ähnlich klingen, bringen sie gerade im Bereich der Sicherheit einen riesigen Unterschied mit sich.

Steht Windows Hello for Business ausschließlich im Enterprise Bereich zur Verfügung und setzt zum Speichern der Zugangsdaten auf eine asymmetrische Verschlüsselung, bringt Windows Hello eben genau diese Funktion nicht mit. Je nach Account-Typ kann bei WH ein reiner Passworthash zum Einsatz kommen und dementsprechend fehlt hier das wichtigste Securityfeature. Wird der Passworthash bei einem Angriff abgegriffen, besteht die gleiche Problematik, als hätte man sich mit den Active Directory Zugangsdaten authentifiziert.

Abseits davon können aber sowohl WH als auch WHfB mit den biometrischen Merkmalen, als auch der PIN arbeiten.

Fazit

Das war jetzt sehr viel Theorie auf einmal und vermutlich wird nicht jedes Detail auf den ersten Blick Sinn machen. Gerade hier ist es aber wichtig, den Ablauf grundlegend zu verstehen, denn Windows Hello for Business kann eine Bereicherung sowohl für den Nutzer, als auch der IT-Security sein. In diesem Beitrag haben wir nur an der Oberfläche des Themas gekratzt. Sollten dir die hier zusammengefassten Informationen daher zu wenig sein und du möchtest die geballte Dokumentation lesen, dann empfehle ich dir direkt dich direkt in den Microsoft Docs zu dem Thema einzulesen.

Im nächsten Teil schauen wir uns die tatsächliche Implementation anhand einer hybriden Umgebung mit dem Key Trust Model an. Der Artikel kann bereits über folgenden Link aufgerufen werden.