Windows Hello for Business ersetzt bei einem verwalteten Windows-PC die kennwortbasierte Anmeldung durch eine starke, gerätegebundene Anmeldeinformation. Die PIN ist dabei kein zweites Kennwort für das Firmenkonto: Sie entsperrt einen kryptografischen Schlüssel, der normalerweise auf dem jeweiligen Gerät geschützt wird. Ob zusätzlich ein Benutzerzertifikat benötigt wird, hängt vom gewählten Vertrauensmodell und der vorhandenen Unternehmensumgebung ab.
Vor der Einrichtung muss daher die Identität des Geräts geklärt sein: Ist es mit Microsoft Entra ID verbunden, hybrid eingebunden oder nur in einer lokalen Active-Directory-Domäne registriert? Erst danach lässt sich entscheiden, ob Cloud Kerberos Trust, Key Trust oder Certificate Trust zur Infrastruktur passt. Auf einem verwalteten Firmen-PC sollte diese Wahl nicht der einzelne Benutzer treffen, sondern die IT-Administration über Intune, Gruppenrichtlinien und die zugehörigen Identitätsdienste vorgeben.
PIN, Schlüssel, Zertifikat und Firmenkonto sind vier verschiedene Ebenen
Die Begriffe werden häufig vermischt, erfüllen aber unterschiedliche Aufgaben. Das Firmenkonto stellt die Identität bereit. Windows Hello for Business erzeugt oder registriert eine Anmeldeinformation für diese Identität. Die PIN beziehungsweise ein biometrisches Merkmal gibt den geschützten Schlüssel auf dem Gerät frei. Ein Zertifikat ist nur bei bestimmten Bereitstellungs- und Anwendungsszenarien Teil der Kette.
- Firmenkonto: Das Arbeits- oder Schulkonto liegt typischerweise in Microsoft Entra ID, im lokalen Active Directory oder in einer gekoppelten Umgebung. Es bestimmt, welcher Benutzer sich anmeldet und auf welche Unternehmensressourcen er zugreifen darf.
- PIN: Die PIN gilt auf dem eingerichteten Gerät. Sie wird nicht wie ein Kontokennwort an einen Server übertragen und kann nicht ohne Weiteres auf einem anderen PC verwendet werden.
- Kryptografischer Schlüssel: Windows Hello for Business verwendet ein Schlüsselpaar. Der private Teil bleibt auf dem Gerät und wird nach Möglichkeit durch das Trusted Platform Module, kurz TPM, geschützt. Der öffentliche Teil wird der Firmenidentität zugeordnet.
- Zertifikat: Beim Certificate-Trust-Modell wird ein Anmeldezertifikat bereitgestellt, das den Hello-Schlüssel mit der Benutzeridentität verbindet. Zertifikate können außerdem unabhängig von der Windows-Anmeldung für VPN, WLAN, E-Mail-Signaturen oder andere Unternehmensdienste eingesetzt werden.
Eine kurze PIN ist daher nicht automatisch schwächer als ein langes Firmenkennwort. Ihre Sicherheit hängt nicht nur von der Zeichenfolge ab, sondern auch von der Bindung an das Gerät, dem Schutz des privaten Schlüssels und den Richtlinien gegen wiederholte Fehlversuche. Das Firmenkennwort bleibt je nach Umgebung trotzdem für ältere Dienste, eine Wiederherstellung oder die erstmalige Registrierung erforderlich.
Welches Vertrauensmodell zur Firmenumgebung passt
Die Auswahl betrifft vor allem den Zugriff auf lokale Active-Directory-Ressourcen. Für reine Cloud-Anwendungen kann die Registrierung bei Microsoft Entra ID bereits ausreichen. Dateifreigaben, Druckdienste oder Anwendungen im lokalen Netzwerk benötigen hingegen ein Modell, mit dem die Hello-Anmeldung gegenüber der lokalen Domäne anerkannt wird.
Cloud Kerberos Trust
Cloud Kerberos Trust ist für viele hybride Umgebungen der weniger aufwendige Weg, weil für die Windows-Anmeldung weder individuelle Anmeldezertifikate noch die ältere Key-Trust-Synchronisierung im Mittelpunkt stehen. Das Gerät und der Benutzer müssen passend in Microsoft Entra ID sowie im lokalen Active Directory eingebunden sein, und die Domäneninfrastruktur muss die benötigten Funktionen unterstützen.
Dieses Modell eignet sich besonders, wenn Microsoft Entra ID bereits die zentrale Cloud-Identität bildet, Benutzer aber weiterhin auf Kerberos-geschützte Ressourcen im lokalen Netz zugreifen. Die genauen Voraussetzungen verändern sich mit der eingesetzten Windows- und Serverumgebung. Die IT sollte sie in der Microsoft-Dokumentation unter den Bereitstellungsmodellen für Windows Hello for Business und Cloud Kerberos Trust gegen die vorhandenen Systeme prüfen.
Key Trust
Beim Key-Trust-Modell erkennt das lokale Active Directory den öffentlichen Hello-Schlüssel des Benutzers an. Dieses Verfahren kann in bestehenden hybriden Installationen weiterhin relevant sein, verlangt aber eine sauber abgestimmte Verzeichnis- und Domänenstruktur. Zwischen Registrierung und nutzbarer Anmeldung kann außerdem eine Synchronisierung erforderlich sein.
Key Trust sollte nicht allein deshalb gewählt werden, weil kein Benutzerzertifikat gewünscht ist. Sind die Voraussetzungen für Cloud Kerberos Trust vorhanden, ist zuerst zu prüfen, welches Modell mit weniger Infrastruktur und geringerer betrieblicher Komplexität auskommt. Ein bereits produktiv eingesetztes Key-Trust-System muss jedoch nicht ohne fachlichen Grund umgebaut werden.
Certificate Trust
Certificate Trust stellt für den Benutzer ein Anmeldezertifikat aus. Dafür werden typischerweise eine Unternehmens-PKI, geeignete Zertifikatvorlagen sowie ein Verfahren zur automatischen Zertifikatsregistrierung benötigt. Das Modell ist sinnvoll, wenn die Umgebung ausdrücklich zertifikatsbasierte Anmeldung verlangt oder vorhandene Anwendungen und Sicherheitsvorgaben daran gebunden sind.
Eine vorhandene Zertifizierungsstelle allein ist noch kein Grund für Certificate Trust. Zertifikatvorlagen, Sperrprüfung, Erneuerung, Schlüsselverwendung und die Erreichbarkeit der PKI-Dienste erhöhen den Verwaltungsaufwand. Das Verfahren darf außerdem nicht mit einer beliebigen Smartcard-Anmeldung gleichgesetzt werden: Windows Hello for Business kann ein Zertifikat verwenden, während der private Hello-Schlüssel weiterhin gerätegebunden geschützt bleibt.
Die Ausgangslage am Windows-PC erfassen
Bevor Richtlinien verteilt werden, sollte ein Referenzgerät seinen tatsächlichen Registrierungszustand zeigen. Der folgende Befehl liest lediglich Informationen aus und verändert das System nicht. Er kann in einer normalen Eingabeaufforderung oder in PowerShell ausgeführt werden:
dsregcmd /statusFür die Planung sind vor allem die Bereiche Device State, User State und SSO State relevant. Die Bezeichnungen können je nach Windows-Stand und Einbindungsart unterschiedlich vollständig erscheinen.
- Zeigt
AzureAdJoinedden WertYES, ist das Gerät mit Microsoft Entra ID verbunden. Der historisch verwendete Anzeigename bleibt in diesem Diagnosewerkzeug teilweise erhalten. - Zeigt zusätzlich
DomainJoinedden WertYES, handelt es sich üblicherweise um eine hybride Einbindung. - Ein Eintrag bei
WorkplaceJoinedbeschreibt eine Registrierung des Kontos oder Geräts, ist aber nicht automatisch dasselbe wie ein vollständiger Entra-ID-Beitritt. AzureAdPrtmitYESweist auf ein vorhandenes Primary Refresh Token für die Cloudanmeldung hin. Ein fehlendes PRT kann die Registrierung und den einmaligen Zugriff auf Microsoft-Dienste beeinträchtigen.
Der Gerätename, die angemeldete Identität und die Join-Werte sollten zusammen betrachtet werden. Ein lokales Administratorkonto kann beispielsweise eine andere Benutzersicht liefern als das betroffene Firmenkonto. Bei Remotesitzungen oder Tests mit wechselnden Konten ist außerdem wichtig, den Befehl tatsächlich in der Sitzung des vorgesehenen Benutzers auszuführen.
Bereitstellung in einer sinnvollen Reihenfolge
Eine belastbare Einführung beginnt nicht am Dialog zum Erstellen der PIN. Zuerst werden Identitätsmodell und Vertrauensmodell festgelegt, anschließend die Geräte registriert und erst danach die Hello-Richtlinien aktiviert. So lässt sich vermeiden, dass Benutzer zwar eine PIN anlegen, aber nicht zuverlässig auf Unternehmensressourcen zugreifen können.
- Identitätsquelle bestimmen: Dokumentiere, ob die Benutzer in Microsoft Entra ID, im lokalen Active Directory oder synchronisiert in beiden Verzeichnissen geführt werden. Prüfe auch, ob die Geräte Entra-verbunden, hybrid verbunden oder ausschließlich Domänenmitglieder sind.
- Zugriffsziele erfassen: Trenne Cloud-Anwendungen von lokalen Kerberos-Diensten, zertifikatsgeschütztem VPN oder WLAN und älteren Anwendungen, die weiterhin ein Kennwort verlangen. Diese Liste entscheidet stärker über das Modell als die gewünschte PIN-Anmeldung am Sperrbildschirm.
- Vertrauensmodell auswählen: Prüfe Cloud Kerberos Trust zuerst für eine passende hybride Umgebung. Key Trust kommt für entsprechend aufgebaute Bestandsumgebungen infrage. Certificate Trust wird gewählt, wenn eine zertifikatsbasierte Anmeldung tatsächlich erforderlich ist.
- Geräteverwaltung festlegen: Cloudverwaltete Geräte erhalten die Einstellungen häufig über Intune, domänenverwaltete Geräte über Gruppenrichtlinien. Werden beide Wege eingesetzt, muss eindeutig dokumentiert sein, welche Instanz die maßgebliche Einstellung liefert.
- Richtlinie pilotieren: Aktiviere Windows Hello for Business zunächst für eine begrenzte Testgruppe. PIN-Regeln, biometrische Nutzung und weitere Sicherheitsvorgaben müssen zur Unternehmensrichtlinie passen, ohne widersprüchliche Konfigurationen aus verschiedenen Verwaltungssystemen zu erzeugen.
- Registrierung durchführen: Nach der Anmeldung mit dem Firmenkonto fordert Windows den Benutzer zur Einrichtung auf, sofern Richtlinie, Lizenzierung, Gerätebindung und Identitätszustand dies zulassen. Der Benutzer bestätigt seine Firmenidentität und legt anschließend die lokale PIN an. Abhängig von den Vorgaben kann eine zusätzliche Identitätsprüfung verlangt werden.
- Unternehmensressourcen testen: Eine erfolgreiche Anmeldung am Sperrbildschirm genügt nicht als Abnahme. Der Pilot muss eine Cloud-Anwendung, eine lokale Kerberos-Ressource und gegebenenfalls den zertifikatsabhängigen Dienst ohne unerwartete Kennwortabfrage erreichen.
In Intune befindet sich die organisationsweite Steuerung je nach Verwaltungsansatz in den Bereichen für Windows-Registrierung, Kontoschutz oder Richtlinienprofile. In einer Active-Directory-Umgebung ist die Gruppenrichtlinie Windows-Komponenten
gWindows Hello for Business der wiederauffindbare Ausgangspunkt. Da Menüstruktur und verfügbare Einstellungen vom Verwaltungsportal und dessen Stand abhängen, sollte die Administration die sichtbaren Richtliniennamen mit der offiziellen Dokumentationsrubrik zu Windows Hello for Business abgleichen, statt einen überlieferten Menüweg ungeprüft zu übernehmen.
Woran eine erfolgreiche Einrichtung erkennbar ist
Die erste Prüfung erfolgt unter Einstellungen, Konten und Anmeldeoptionen. Dort sollte die PIN als von Windows Hello verwaltete Anmeldeoption erscheinen. Auf verwalteten Geräten können einzelne Schalter ausgeblendet oder durch die Organisation vorgegeben sein; ein fehlender Schalter ist daher nicht automatisch ein Windows-Fehler.
Für die technische Kontrolle kann erneut der folgende reine Lesebefehl verwendet werden:
dsregcmd /statusIm Benutzerbereich kann NgcSet den Status der Windows-Hello-Bereitstellung anzeigen. YES spricht dafür, dass für den angemeldeten Benutzer eine Hello-Anmeldeinformation eingerichtet wurde. Dieser einzelne Wert beweist jedoch noch nicht, dass das gewählte Vertrauensmodell für alle lokalen Ressourcen richtig arbeitet.
Bei Certificate Trust sollte zusätzlich geprüft werden, ob das vorgesehene Benutzerzertifikat im Zertifikatspeicher des angemeldeten Benutzers vorhanden ist. Der folgende Befehl öffnet die Zertifikatverwaltung für diesen Benutzer und verändert keine Zertifikate:
certmgr.mscUnter Eigene Zertifikate und Zertifikate müssen Aussteller, Gültigkeit und vorgesehene Verwendung zur Unternehmensvorlage passen. Ein Zertifikat mit ähnlich klingendem Namen ist kein ausreichender Nachweis. Bei Cloud Kerberos Trust oder Key Trust muss dagegen nicht zwangsläufig ein persönliches Windows-Hello-Anmeldezertifikat in diesem Speicher auftauchen.
Wenn PIN-Anlage und Firmenzugriff auseinanderfallen
Fehler lassen sich schneller eingrenzen, wenn Anmeldung, Gerätebindung und Ressourcenzugriff getrennt bewertet werden. Die folgende Reihenfolge vermeidet vorschnelles Löschen der PIN oder eine erneute Geräteaufnahme.
- Keine Aufforderung zur Registrierung: Prüfe zuerst, ob das betroffene Benutzer- und Gerätekonto überhaupt im Geltungsbereich der Intune- oder Gruppenrichtlinie liegt. Ist die Richtlinie nicht wirksam, helfen Änderungen an der PIN-Oberfläche nicht.
- Registrierung startet, wird aber nicht abgeschlossen: Kontrolliere mit
dsregcmd /statusden Join-Zustand und das Primary Refresh Token. Schlägt bereits die Identitätsbestätigung fehl, liegt der nächste Prüfpunkt bei Konto, Mehrfaktorprüfung, Netzwerkzugriff oder Gerätekonformität und nicht beim PIN-Feld selbst. - PIN-Anmeldung funktioniert, lokale Freigabe verlangt ein Kennwort: Dann ist Windows Hello auf dem Gerät eingerichtet, aber der lokale Ressourcenzugriff wird nicht wie vorgesehen vermittelt. Prüfe das gewählte Trust-Modell, die Domänenanbindung, Kerberos und bei hybriden Geräten die Synchronisierung. Eine neue PIN ist in diesem Zweig gewöhnlich keine zielführende erste Maßnahme.
- Cloud-Zugriff funktioniert, ein zertifikatsabhängiges VPN jedoch nicht: Unterscheide das Hello-Anmeldeverfahren vom VPN-Zertifikat. Prüfe in
certmgr.msc, ob das für das VPN vorgesehene Zertifikat vorhanden, gültig und für den benötigten Zweck ausgestellt ist. Ein funktionierender Hello-Schlüssel ersetzt nicht automatisch jedes Anwendungszertifikat. - Certificate Trust scheitert nur bei einzelnen Benutzern: Vergleiche Zertifikatsvorlage, Ausstellung und Sperrprüfung mit einem funktionierenden Pilotkonto. Ein abgelaufenes oder nicht passend verwendbares Zertifikat muss über den vorgesehenen PKI-Prozess erneuert werden; manuelles Kopieren von Zertifikaten zwischen PCs ist kein geeigneter Ersatz.
PIN-Rücksetzung und Gerätewechsel richtig einordnen
Weil die PIN an den geschützten Schlüssel eines bestimmten Geräts gekoppelt ist, wird sie bei einem neuen PC nicht einfach vom alten Gerät übernommen. Der Benutzer registriert auf dem neuen Gerät eine neue Hello-Anmeldeinformation. Das Firmenkonto bleibt dieselbe Identität, der gerätegebundene Schlüssel ist jedoch ein anderer.
Auch eine PIN-Rücksetzung ist mehr als die Änderung einer zentral gespeicherten Zahlenfolge. Windows muss die Identität des Benutzers erneut bestätigen und die lokale Anmeldeinformation ordnungsgemäß aktualisieren. Auf einem Firmen-PC sollte dafür ausschließlich der von der Organisation bereitgestellte Ablauf über die Anmeldeoptionen beziehungsweise den Sperrbildschirm verwendet werden.
Das manuelle Löschen von NGC-Ordnern, Zertifikaten oder TPM-Inhalten ist keine reguläre Einrichtungsmaßnahme. Das Löschen des TPM kann weitere geschützte Schlüssel betreffen und bei aktivierter Geräteverschlüsselung einen Wiederherstellungsschlüssel erforderlich machen. Solche Eingriffe gehören in einen dokumentierten Supportprozess mit gesichertem BitLocker-Wiederherstellungsschlüssel und dürfen nicht als erste Fehlerbehebung dienen.
Abnahme der Unternehmensanmeldung
Eine Pilotbereitstellung ist erst abgeschlossen, wenn die gesamte Anmeldekette funktioniert. Der Testbenutzer sollte den PC nach einem Neustart mit der neuen PIN entsperren, eine vorgesehene Microsoft-Cloudanwendung ohne unnötige erneute Anmeldung öffnen und eine lokale Ressource erreichen, sofern diese zum Nutzungsszenario gehört. Bei Certificate Trust kommt die Kontrolle des ausgestellten Anmeldezertifikats hinzu; bei VPN- oder WLAN-Zertifikaten werden diese getrennten Anwendungsfälle separat geprüft.
