Ist eine Windows-Hello-PIN schwächer als ein Kennwort?

Nein. Die PIN entsperrt nur einen privaten Schlüssel im TPM des Geräts; sie wird nie über das Netzwerk gesendet und ist auf jedem anderen Gerät nutzlos. Der Anti-Hammering-Schutz des TPM begrenzt Rateversuche. Ein gestohlenes Kennwort funktioniert von überall, eine gestohlene PIN nur auf genau diesem einen Gerät und nur in den Händen des Angreifers. Deshalb ist eine sechsstellige, TPM-gestützte PIN stärker als die meisten Kennwörter.

Welches Vertrauensmodell sollte eine hybride Organisation wählen?

In den meisten Fällen die Cloud-Kerberos-Vertrauensstellung. Sie braucht keine PKI für die Hello-Schlüssel, keine Zertifikate auf den Domänencontrollern für die Hello-Anmeldung und keine Wartezeit für die Schlüsselsynchronisierung, und Microsoft empfiehlt sie für hybride Bereitstellungen. Key Trust oder Certificate Trust bleiben für bestimmte Fälle relevant, etwa rein lokale Umgebungen oder Szenarien, die die Cloud-Kerberos-Vertrauensstellung nicht unterstützt. Prüfen Sie vor der Entscheidung den aktuellen Vergleich von Microsoft.

Sollten Administratoren Windows Hello for Business verwenden?

Für Admins, die sich an ihrer eigenen Privileged Access Workstation anmelden, passt es gut, weil es eingetippte Kennwörter und phishbare Anmeldedaten aus der täglichen Admin-Arbeit entfernt. Registrieren Sie das Admin-Konto des Tiers auf der PAW selbst, nicht auf einem Benutzer-Laptop. Für Admin-Konten, die auf vielen gemeinsam genutzten Systemen funktionieren müssen, ist ein FIDO2-Sicherheitsschlüssel oder eine Smartcard oft einfacher, weil Hello-Schlüssel an ein Gerät gebunden sind.

Windows Hello for Business: Vertrauensmodelle und PIN

Kennwörter sind die Anmeldedaten, die Angreifer am häufigsten stehlen: per Phishing, Password Spraying, Keylogger, Speicherauszug oder aus einem anderen Datenleck wiederverwendet. Windows Hello for Business ersetzt das Kennwort bei der Windows-Anmeldung durch ein asymmetrisches Schlüsselpaar, das auf dem Gerät erzeugt und durch dessen TPM geschützt wird. Der Benutzer entsperrt den Schlüssel per PIN oder biometrischer Geste; der private Schlüssel verlässt das Gerät nie, und es gibt nichts Wiederverwendbares, das sich abphishen ließe.

Dieser Leitfaden behandelt die sicherheitsrelevanten Entscheidungen: welches Vertrauensmodell, wie man hardwaregestützte Schlüssel erzwingt, wie man die PIN-Richtlinie festlegt und wie man bestätigt, dass sich Benutzer und Administratoren tatsächlich mit Hello anmelden, statt auf ein Kennwort zurückzufallen. Er baut auf der Reihe Schutz von Anmeldedaten auf, in der Credential Guard schützt, was im Speicher verbleibt.

So funktioniert es in Kürze

Bei der Bereitstellung erzeugt Windows für den Benutzer ein Schlüsselpaar im TPM und registriert den öffentlichen Schlüssel bei Microsoft Entra ID (und, je nach Vertrauensmodell, bei Active Directory). Bei der Anmeldung entsperrt der Benutzer den privaten Schlüssel lokal und authentifiziert sich damit: bei Entra ID für ein Primary Refresh Token und bei Active Directory für ein Kerberos-Ticket. Die PIN ist eine lokale Entsperrgeste, kein gemeinsames Geheimnis.

Zwei Eigenschaften machen es wertvoll:

Phishing-Resistenz. Es gibt kein Kennwort, das man auf einer gefälschten Seite eingeben könnte, und der Schlüssel funktioniert nur auf dem Gerät, auf dem er erzeugt wurde.
Kein wiederverwendbares Geheimnis auf der Leitung. Ein Angreifer, der Netzwerkverkehr mitschneidet oder Authentifizierungen weiterleitet, erhält nichts, was anderswo funktioniert.

Schritt 1: Das Vertrauensmodell wählen

In hybriden Umgebungen (AD + Entra ID) entscheidet das Vertrauensmodell, wie eine Hello-Anmeldung ein Kerberos-Ticket von Ihren Domänencontrollern erhält.

Modell	Wie die lokale Authentifizierung funktioniert	Voraussetzungen	Typischer Einsatz
Cloud-Kerberos-Vertrauensstellung	Entra ID stellt ein Teilticket aus; der lokale DC tauscht es gegen ein vollständiges TGT	Entra-Kerberos-Serverobjekt in AD, unterstützte DCs und Clients	Empfohlen für hybride Umgebungen
Key Trust	Öffentlicher Schlüssel wird nach AD synchronisiert (`msDS-KeyCredentialLink`); der DC prüft ihn per PKINIT	DC-Zertifikate, Schlüsselsynchronisierung durch Entra Connect	Umgebungen, die keine Cloud-Kerberos-Vertrauensstellung nutzen können
Certificate Trust	Der Benutzer erhält ein über AD CS ausgestelltes Zertifikat	Unternehmens-PKI, AD FS als Registrierungsstelle für Zertifikate, Verbundauthentifizierung	Szenarien, die ein Benutzerzertifikat brauchen, etwa manche RDP-Nutzungen

Die Cloud-Kerberos-Vertrauensstellung beseitigt die beiden üblichen Schmerzpunkte: keine PKI für die Hello-Schlüssel und keine Bereitstellungsverzögerung, während der öffentliche Schlüssel nach AD synchronisiert wird. Ihre Anforderungen sind genau festgelegt: auf den Clients Windows 10 21H2 mit KB5010415 oder Windows 11 21H2 mit KB5010414 oder neuer; Domänencontroller unter Windows Server 2016 mit KB4534307, Server 2019 mit KB4534321 oder Server 2022/2025; genügend beschreibbare Domänencontroller an jedem Standort, an dem sich Benutzer authentifizieren; und nach Entra ID synchronisierte Benutzer. Mitglieder privilegierter integrierter Gruppen (Domain Admins und ähnliche) können sie nicht nutzen, weil die Kennwortreplikationsrichtlinie des Objekts AzureADKerberos sie ausschließt, und Microsoft rät davon ab, das zu lockern.

Reine Cloud-Bereitstellungen (in Entra eingebunden, kein lokales AD) brauchen überhaupt kein Vertrauensmodell.

Schritt 2: Das Entra-Kerberos-Objekt anlegen (Cloud-Kerberos-Vertrauensstellung)

Die Cloud-Kerberos-Vertrauensstellung beruht auf einem Objekt nach Art eines schreibgeschützten Domänencontrollers in jeder Domäne, mit dem Entra ID Kerberos-Teiltickets ausstellen kann, denen Ihre DCs vertrauen. Legen Sie es von einem Computer mit dem Modul AzureADHybridAuthenticationManagement aus an, als Mitglied von Domain Admins (und Enterprise Admins für die Gesamtstruktur) und mit einem Entra-Konto, das die Rolle Hybrid Identity Administrator besitzt:

PowerShell

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
$domain = $env:USERDNSDOMAIN
$upn    = "admin@contoso.com"
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn

Dadurch entstehen ein Computerobjekt AzureADKerberos in der OU Domain Controllers und ein Konto krbtgt_AzureAD. Behandeln Sie beide als Tier-0-Assets: Wer den Schlüssel von krbtgt_AzureAD kontrolliert, kann die Ticketausstellung beeinflussen. Rotieren Sie ihn regelmäßig mit demselben Modul (Set-AzureADKerberosServer -RotateServerKey) und führen Sie die Entra-Konten, die ihn verwalten können, in Ihrem Tier-0-Admin-Modell.

Schritt 3: Die Richtlinie konfigurieren

Per Gruppenrichtlinie befinden sich die Einstellungen unter Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Hello for Business:

Einstellung	Wert	Warum
Use Windows Hello for Business	Enabled	Schaltet die Bereitstellung ein
Use cloud Kerberos trust for on-premises authentication	Enabled	Cloud-Kerberos-Vertrauensstellung (für Key Trust nicht setzen; Use certificate for on-premises authentication muss unkonfiguriert bleiben, sonst gewinnt Certificate Trust)
Use a hardware security device	Enabled, und Do not allow TPM 1.2 aktivieren	Lehnt Softwareschlüssel ab; siehe Schritt 4
Use biometrics	Enabled oder Disabled gemäß Ihrer Richtlinie	Gesichtserkennung und Fingerabdruck als Entsperrgesten

In Intune können Sie unter Devices > Enrollment > Windows Hello for Business einen mandantenweiten Standard setzen; für Kontrolle und gezielte Zuweisung verwenden Sie jedoch eine Richtlinie unter Endpoint security > Account protection oder den Einstellungskatalog. Beide nutzen den CSP PassportForWork mit Einstellungen wie Use Windows Hello For Business, Use Cloud Trust For On Prem Auth und Require Security Device. Vermeiden Sie es, dasselbe Gerät sowohl über den mandantenweiten Standard als auch über eine zugewiesene Richtlinie zu konfigurieren, das erschwert die Fehlersuche. Erhält ein Gerät Einstellungen für Windows Hello for Business sowohl per Gruppenrichtlinie als auch per Intune, gewinnt die Gruppenrichtlinie, und die Intune-Einstellungen werden ignoriert.

Schritt 4: TPM-gestützte Schlüssel verlangen

Hat ein Gerät kein nutzbares TPM, kann Windows auf einen Softwareschlüssel ausweichen, der für Malware im Benutzerkontext oder einen Angreifer mit Zugriff auf den Datenträger weit leichter angreifbar ist. Use a hardware security device (Intune: Require Security Device) verhindert diesen Rückfall: Geräte ohne geeignetes TPM stellen Hello überhaupt nicht bereit.

Prüfen Sie den TPM-Zustand, bevor Sie das erzwingen, besonders auf älteren Desktops und VMs:

PowerShell

Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, ManufacturerVersion

Das Ablehnen von TPM 1.2 vermeidet ältere Chips mit schwächeren Algorithmen und einer Vorgeschichte von Firmwareproblemen. Dasselbe TPM schützt die BitLocker-Schlüssel; eine TPM-Inventur dient also beiden Projekten.

Auf Windows-11-Hardware, die es unterstützt, ergänzt Enhanced Sign-in Security die VBS-Isolierung für biometrische Daten und den Anmeldepfad. Das hängt von bestimmten Sensoren und Firmware ab; prüfen Sie also die Geräteunterstützung, bevor Sie es als Anforderung aufnehmen.

Schritt 5: Die PIN-Richtlinie festlegen

Die PIN-Komplexität befindet sich unter Computer Configuration > Policies > Administrative Templates > System > PIN Complexity (Intune: Einstellungen PIN Complexity im selben Kontoschutzprofil).

Einstellung	Empfohlen	Hinweise
Minimum PIN length	6	Standard ist 6. Mehr bringt wenig, weil das TPM Rateversuche begrenzt
Maximum PIN length	127 (Standard)	Benutzer, die eine längere PIN wollen, nicht einschränken
Require digits / lowercase / uppercase / special characters	Ziffern zulässig; übrige optional	Komplexität erzeugt Reibung ohne viel Sicherheitsgewinn bei einem TPM-gebundenen Schlüssel
Expiration	Nicht konfiguriert	Erzwungene PIN-Wechsel treiben Benutzer zu vorhersehbaren Mustern
History	0, sofern kein Audit es verlangt	Nur relevant, wenn ein Ablauf verwendet wird

Der eigentliche Schutz gegen Raten ist das Anti-Hammering des TPM, das nach wiederholt falschen PINs sperrt. Belassen Sie dafür die Standardwerte, sofern Sie keinen konkreten Grund haben.

Aktivieren Sie die PIN-Wiederherstellung (Use PIN Recovery in der Richtlinie, EnablePinRecovery im CSP), damit Benutzer eine vergessene PIN über den Microsoft-PIN-Zurücksetzungsdienst zurücksetzen können, ohne ihren Schlüssel zu vernichten und neu bereitzustellen. So wird aus „Ich habe meine PIN vergessen“ kein Kennwort-Reset am Helpdesk.

Schritt 6: Administratoren und das verbleibende Kennwort

Windows Hello löscht das Kennwort des Benutzers nicht; es sorgt nur dafür, dass Benutzer es nicht mehr eintippen. Für den vollen Nutzen:

Aktivieren Sie die kennwortlose Umgebung, die den Kennwort-Anmeldeinformationsanbieter für den letzten Benutzer ausblendet, der sich mit Hello oder einem FIDO2-Schlüssel angemeldet hat (Authentication/EnablePasswordlessExperience im Policy-CSP). Sie erfordert Windows 11 22H2 mit KB5030310 oder neuer, Microsoft-Entra-Join und MDM-Verwaltung; hybrid eingebundene und in AD eingebundene Geräte sind nicht abgedeckt.
Stellen Sie für Admins Hello für das Admin-Konto des Tiers auf der PAW bereit und verlangen Sie per bedingtem Zugriff phishingresistente Authentifizierung für Admin-Rollen in Entra ID. Unter der Cloud-Kerberos-Vertrauensstellung können Tier-0-Konten in privilegierten integrierten Gruppen auf diesem Weg kein lokales TGT erhalten; planen Sie für sie eine andere Anmeldemethode, etwa Smartcards.
Bedenken Sie, dass RDP zu einem Server in der Regel weiterhin Anmeldedaten braucht, die der Server akzeptiert. Remote Credential Guard kann Ihre Hello-Anmeldung nutzen, weil die Kerberos-Anfragen auf dem Client bleiben; testen Sie Ihre konkrete Kombination.

Was kaputtgeht

Geräte ohne nutzbares TPM stellen Hello nicht mehr bereit, sobald Hardwareschlüssel verlangt werden.
Benutzer, die sich nie im Unternehmensnetzwerk angemeldet haben, müssen unter Key Trust unter Umständen auf die Schlüsselsynchronisierung warten, bevor lokale Ressourcen funktionieren. Die Cloud-Kerberos-Vertrauensstellung vermeidet diese Verzögerung.
Gemeinsam genutzte Geräte mit vielen Benutzern: Jeder Benutzer stellt seinen eigenen Schlüssel bereit, und die Zahl der Hello-Registrierungen pro Gerät ist begrenzt.
Anwendungen, die direkt nach dem Windows-Kennwort fragen (alte VPN-Clients, manche Fachanwendungen), statt die integrierte Anmeldung zu nutzen.

Überprüfen

Bereitstellungszustand. Führen Sie dsregcmd /status als Benutzer aus. Unter User State bedeutet NgcSet : YES, dass ein Hello-Schlüssel existiert. Bei der Cloud-Kerberos-Vertrauensstellung zeigt OnPremTgt : YES (unter SSO State), dass der Benutzer über Entra ID ein lokales Ticket erhalten hat.
Bereitstellungsereignisse. Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin protokolliert, ob die Bereitstellung gestartet wurde: Ereignis 358, wenn die Voraussetzungen erfüllt sind, und 360, wenn nicht, mit Angabe der fehlenden Voraussetzung.
Anmeldemethode. Filtern Sie in den Entra-Anmeldeprotokollen nach Windows-Anmeldungen und prüfen Sie, ob als Authentifizierungsmethode Windows Hello for Business angezeigt wird. Ein hoher Anteil von Kennwortanmeldungen auf bereitgestellten Geräten bedeutet, dass Benutzer Hello umgehen.
Abdeckung mit Hardwareschlüsseln. Mit aktiver Richtlinie für Hardware-Sicherheitsgeräte stellen Geräte ohne bereites TPM überhaupt nichts bereit. Vergleichen Sie die NgcSet-Abdeckung mit der Get-Tpm-Inventur aus Schritt 4, um Geräte zu finden, die sich stillschweigend nie registriert haben.

Checkliste

Vertrauensmodell gewählt; Cloud-Kerberos-Vertrauensstellung für hybride Umgebungen, sofern keine dokumentierte Ausnahme
Objekt AzureADKerberos pro Domäne angelegt und als Tier 0 behandelt, Schlüsselrotation eingeplant
Hello über eine einzige Richtlinienquelle aktiviert, Hardware-Sicherheitsgerät verlangt, TPM 1.2 abgelehnt
PIN mindestens 6 Zeichen, kein Ablauf, PIN-Wiederherstellung aktiviert
Admins auf PAWs bereitgestellt; phishingresistente Authentifizierung für Admin-Rollen verlangt
Kennwortlose Umgebung aktiviert, wo unterstützt
dsregcmd und Ereignisse 358/360 zur Verfolgung der Bereitstellungsabdeckung genutzt

Windows Hello for Business nimmt die am häufigsten gestohlenen Anmeldedaten unter Windows aus dem täglichen Gebrauch. Eine Definition für Ihre Stakeholder finden Sie unter Windows Hello for Business im Glossar.