Gotcha: Windows Hello for Business

Mein heutiges Gotcha zum Thema MS365 und Windows Hello for Business.

Ein Kunde möchte in einer hybriden Active Directory (AD) / Azure Active Directory (AAD) Umgebung Windows Hello for Business nutzen. So kann man die Multifaktor Authentifizierung für alle Benutzer verpflichtend machen, ohne dass man ständig den zweiten Faktor manuell eingeben oder bestätigen muss. Das geht, da das Gerät dabei ja zum zweiten Faktor wird. Netter Nebeneffekt: Wenn die Hardware vorhanden ist, kann man biometrische Authentifizierung nutzen. Also zum Beispiel Gesichterkunnung oder Fingerabdruck.

Außerdem ist Windows Hello for Business eine phishing-sichere Authentfizierungsmethode, da man sich ohne das Gerät ja eben nicht authentifizieren kann. Kurzer Einschub: Die beiden anderen phishing-sicheren Authentifizierungsmethoden in Microsoft 365 sind Zertifikate und FIDO2 Sticks.

Eine der Voraussetzungen ist ein Active Directory Schema von 2016 oder höher. Das AD musste der Kunde erst einmal hochstufen.

Nach Erfüllung aller anderen Voraussetzungen konnte man dann tatsächlich eine Windows Hello for Business PIN festlegen. Aber die Authentifizierung klappte trotzdem nicht (“This option is currently not available”).

Jetzt muss man wissen, dass der öffentliche Authentifizierungsschlüssel nach der Einrichtung auf dem Gerät im AD gespeichert wird. nämlich im Benutzerobkect im Attribut msDS-KeyCredentialLink. Beim nächsten Sync durch Azure AD Connect wird das Attribut dann in’s AAD geschrieben. Damit dieser Sync aber überhaupt möglich ist, muss Azure AD Connect das Attribut kennen. Kannte es in unserem Fall aber nicht, da das Schema ja erst nach der Installation von Azure AD Connect aktualisiert wurde.

Aber die Lösung ist ganz einfach, man muss nur im Azure AD Connect Assistenten das Schema aktualisieren.

Kategorie: