Windows Hello for Business für Active Directory – Konfiguration

Mittlerweile lässt sich Windows Hello for Business innerhalb einer On-Premises Active Directory Umgebung ohne erhöhtem Aufwand aktivieren. Welche Vorteile dabei die Konfiguration und Integration von Windows Hello for Business im Active Directory hat, haben wir uns bereits im ersten Artikel zu diesem Thema näher angeschaut. In diesem Beitrag behandeln wir die Konfiguration und gehen Schritt für Schritt auf die benötigten Komponenten ein.

WHfB Übersicht

Trust Deployments

Im ersten Artikel zu Windows Hello for Business haben wir bereits die unterschiedlichen Trust Deployments näher beleuchtet, daher gehe ich hier nicht weiter darauf ein. Die nachfolgende Anleitung bezieht sich auf das „Key Trust Deployment„. Sollte sich dieses Modell für eure Active Directory Umgebung nicht eignen, bleibt natürlich noch die Möglichkeit des „Certificate Trust Deployments„.

Voraussetzungen

Dieser Beitrag setzt bereits eine gewisse Grundkonfiguration folgender Komponenten voraus:

• On-Premises Active Directory
• Azure Active Directory
• Azure AD Connect inklusive Synchronisation der User- und Computer-Objekte (siehe Hybrid Joined Clients)
• Azure AD MFA (siehe Aktivieren von MFA in O365)
• On-Premises Certificate Authority (PKI)

WHfB Konfiguration & Integration

Active Directory

Wir behandeln in diesem Beitrag eine hybride Active Directory Umgebung, daher ist ein korrekt funktionierenden lokales AD notwendig. Die Computer müssen auch eben dieser On-Premises Domäne beigetreten sein. Eine Grundkonfiguration des ADs ist dabei ausreichend.

Setzt man auf ein reines Azure AD ohne lokaler Komponente, kann natürlich ebenfalls auf Windows Hello for Business gebaut werden. Dafür gibt es Anleitungen direkt in den Microsoft Docs.

Azure AD & Azure AD Connect

Zwar wäre eine reine On-Premises Integration von Windows Hello for Business ebenfalls möglich, allerdings wird dafür eine ADFS Umgebung zwingend vorausgesetzt. Da die meisten Unternehmen aber ohnehin bereits eine hybride Umgebung etabliert haben, ist dies meiner Meinung nach auch der beste Weg und vermeidet unnötigen Overhead.

Dieser Artikel setzt somit einen O365 Tenant mit Azure AD Connect zur Synchronisation der On-Premises User-, sowie Computer-Objekte voraus. Solltest du deine Clients noch nicht mit dem Azure AD synchronisieren, kannst du dir vorab folgenden Beitrag näher anschauen. Neben der Integration von WHfB kann ein Hybrid-Joined Client auch noch weitere Vorteile mit sich bringen, wie beispielsweise das Managen über Intune oder die Bereitstellung von Compliance Policies.

Certificate Authority – PKI

Anders als beim „Certificate Trust“ Modell benötigt nicht jeder Benutzer ein eigenes Zertifikat, was den Overhead schon massiv reduziert, allerdings müssen die Domain Controller ein gültiges und vertrauenswürdiges Zertifikat besitzen. Der Client muss beim Austausch mit dem Domain Controller verifizieren können, ob sein Kommunikationspartner tatsächlich vertrauenswürdig ist und genau hier kommt die PKI (Public Key Infrastructure) oder auch Certificate Authority ins Spiel.

Certificate Authority installieren

Sollte in eurer Umgebung noch keine Certificate Authority installiert sein, kann dies sehr einfach über die Windows Rollen auf einem Domain Controller oder Member Server installiert und konfiguriert werden. Eine ausführliche Anleitung wie man eine Windows CA installiert gibt es auf der Website SID-500.

Zertifikat ausrollen

Anschließend muss auf den Domain Controllern ein gültiges Zertifikat vom Template „Kerberos Authentication“ ausgerollt werden. Das kann entweder manuell angefordert oder über eine GPO automatisiert werden. Da Zertifikate regelmäßig auslaufen, ist die automatisierte Variante definitiv zu bevorzugen, da man hierbei dann auch nicht in die Gefahr läuft, auf das Erneuern des Zertifikats zu vergessen.

Dazu erstellen wir eine neue Gruppenrichtlinie in der Organisationseinheit „Domain Controllers“ und nennen sie „CA_AutomaticEnrollment„.

Nachdem die Richtlinie auf dem Domain Controller angewendet wurde (gpudpate /force) sollte man im Computer Zertifikatsspeicher auch schon das neue Kerberos Authentication Zertifikat sehen können.

Somit wurden seitens PKI alle Voraussetzungen getroffen, damit Clients eine vertrauenswürdige und gesicherte Verbindung mit der Domäne aufbauen können.

Windows Hello for Business ausrollen

Die Vorkehrungen wurden getroffen und wir können nun Windows Hello for Business auf den Clients ausrollen. Wie so oft empfiehlt es sich hierbei, das Ausrollen neuer Funktionen in Batches durchzuführen. Man startet mit einigen Test-Clients und erweitert die Batches Schritt für Schritt auf weitere Benutzer, Abteilungen oder Standorte.

Wie die Richtlinie auf den Clients aktiviert wird, hängt dabei maßgeblich davon ab, welches Device Management eurerseits bevorzugt wird. Zur Auswahl steht natürlich das gewohnte Deployment über Gruppenrichtlinien oder das Management über Intune. Da der Client ohnehin eine Line-of-Sight zum Domain Controller benötigt, bevorzuge ich dabei GPOs.

GPO konfigurieren

Wir wechseln in das GPO MMC und erstellen eine neue Richtlinie mit dem Namen „O365_WindowsHelloforBusiness„. Im Richtlinieneditor wechseln wir in das Verzeichnis Administrative Templates > Windows Component > Windows Hello for Business.

Hierbei legen wir den Hauptaugenmerk auf folgender Richtlinie:

• Use Windows Hello for Business -> Enabled

Wer nicht möchte, dass Nutzer dazu aufgefordert werden, WHfB einzurichten, kann zusätzlich die Option „Do not start Windows Hello provisioning after sign-in“ aktivieren. Damit kann jeder Nutzer über die Einstellungen WHfB aktivieren, wird aber nicht dazu aufgefordert.

Anschließend verknüpfen wir die soeben erstellte GPO mit jener Organisationseinheit, in der auch unsere Computer-Objekte liegen. Somit wird für den Nutzer beim nächsten Logon automatisch die Konfiguration von Windows Hello for Business gestartet.

Wer die GPO nicht auf Computer-, sondern Nutzer-Objekte binden möchte, kann dies übrigens ebenfalls tun. Die bereitstehenden Konfigurationsmöglichkeiten sind dabei aber reduziert und daher bevorzuge ich die Computer Richtlinien.

Benutzerexperience am Client

Ersteinrichtung

Da wir bei der Konfiguration der GPO das automatische Starten der Windows Hello for Business Einrichtung ausgewählt haben, bekommt der Nutzer beim nächsten Logon folgende Maske angezeigt.

Hierüber hat der Nutzer nun die Möglichkeit, WHfB mit den jeweiligen Komponenten (Metriken) des Clients zu konfigurieren. Hat der Client beispielsweise eine kompatible Kamera oder einen Fingerabdrucksensor, kann auch auf eben diese biometrischen Merkmale zurückgegriffen werden. Sind weder Kamera noch Sensor vorhanden, kann jedenfalls die PIN eingerichtet werden.

Nach erfolgter Einrichtung hat der Nutzer ab jetzt die Wahl, ob er sich mit seinem Active Directory Kennwort oder Windows Hello for Business authentifizieren möchte.

Ein wichtiger Hinweis hierzu noch: Windows Hello for Business mit dem Key Trust Modell funktioniert leider nicht über RDP. Wird diese Funktion zwingend auch für Remote Zugriffe benötigt, kann aber auf das Certificate Trust Modell zurückgreifen.

Active Directory Writeback

Nachdem der Nutzer WHfB am Client eingerichtet hat, liegen die Informationen initial nur im Azure AD. Da sich On-Premises Clients aber weiterhin im Active Directory authentifizieren, muss diese Information zurück in die lokale Domäne synchronisiert werden. Diese Aufgabe übernimmt natürlich der Azure AD Connect.

Beim nächsten Sync (kann auch manuell getriggert werden), wird beim Benutzer ein Attribut „msDS-KeyCredentialLink“ angelegt:

Das ist auch der Grund, warum die Authentifizierung mittels WHfB unmittelbar nach der Ersteinrichtung noch nicht funktioniert. Das Attribut muss zuerst mit der Domäne synchronisiert werden und da der Azure AD Connect nur alle 30 Minuten ausgeführt wird, kann es hier zu einer Verzögerung kommen.

Fazit

Somit wäre die Konfiguration von Windows Hello for Business innerhalb einer Active Directory Umgebung abgeschlossen. Es gibt noch weitere Punkte, die man ansprechen kann, darunter das Troubleshooting oder auch das Dual Enrollment für Adminbenutzer. Gerade hier kann der zusätzliche Sicherheitsfaktor eine entscheidende Rolle spielen. Diese Themen würden aber den Rahmen dieses Artikels sprengen und werden in zukünftigen Beiträgen näher behandelt.