Windows Hello for Business: Ein vollständiger Leitfaden zu SSO und Hardware-Sicherheit

Windows Hello for Business hat sich zum Eckpfeiler der passwortlosen Strategie von Microsoft entwickelt: Es kombiniert PINs, Biometrie und kryptografische Schlüssel, um Benutzern die Anmeldung ohne Passworteingabe bei deutlich erhöhter Sicherheit zu ermöglichen. Unterstützt wird dies durch Hardware-Sicherheit, TPM und moderne SSO-Modelle in Cloud-, Hybrid- und On-Premises-Umgebungen.

Windows Hello for Business (WHfB) ist weit mehr als nur die Windows-PIN. Es handelt sich um ein verteiltes System, das Microsoft Entra ID (ehemals Azure AD), Active Directory, PKI, Kerberos, FIDO2 sowie erweiterte Geräte- und Benutzerrichtlinien integriert. Für Windows- oder Identitätsadministratoren ist es daher unerlässlich zu verstehen, wie alle Komponenten – Registrierung, Bereitstellung, Schlüsselsynchronisierung, Zertifikate und Authentifizierung – zusammenwirken, um eine reibungslose Implementierung mit robustem, phishing-resistentem Single Sign-On zu gewährleisten.

Was genau ist Windows Hello for Business und wie verändert es die Authentifizierung?

Windows Hello for Business ist die verwaltete Unternehmensversion von Windows Hello. Es ersetzt das Kennwort durch einen öffentlichen Schlüssel, der mit dem Gerät verknüpft, durch ein TPM geschützt und per PIN oder biometrischer Geste entsperrt wird. Dieser Schlüssel ermöglicht die Authentifizierung bei Microsoft Enterprise ID, Active Directory, AD FS und anderen Diensten, die darauf basieren.

Anstatt auf gemeinsame Geheimnisse (Passwörter, Einmalpasswörter, SMS-Codes) zu setzen, generiert WHfB für jeden Benutzer und jedes Gerät ein öffentliches/privates Schlüsselpaar . Der öffentliche Schlüssel wird beim Identitätsanbieter (IdP) registriert, der private Schlüssel bleibt sicher auf dem Gerät gespeichert und kann nicht exportiert werden. Der Benutzer gibt lediglich mit seiner PIN oder seinen biometrischen Daten Informationen („Entropie“) an, um diesen privaten Schlüssel freizugeben, wenn er sich authentifizieren möchte.

Das Ergebnis ist ein Authentifizierungserlebnis, das resistent gegen Phishing, Anmeldeinformationsdiebstahl und Brute-Force-Angriffe ist und SSO sowohl in der Cloud (Microsoft 365, moderne Anwendungen) als auch bei lokalen Diensten (Kerberos, Legacy-Anwendungen, zertifikatsbasierte VPNs usw.) aufrechterhält.

Windows Hello for Business – Interne Phasen: Von Null auf SSO

Um WHfB vollständig zu verstehen, ist es hilfreich, seine Funktionsweise in mehrere chronologische Phasen zu unterteilen: Geräteregistrierung, Bereitstellung, Schlüsselsynchronisierung (falls zutreffend), Zertifikatsregistrierung (falls verwendet) und schließlich die tägliche Authentifizierung.

1. Geräteregistrierung

Zunächst muss das Gerät einen Geräteregistrierungsprozess durchlaufen . Dieser Schritt verknüpft das Gerät mit einem bestimmten Identitätsanbieter (IdP) und gibt ihm eine eigene Identität.

• Cloud- oder Hybrid-ImplementierungenDer Identitätsanbieter (IdP) ist Microsoft Enter ID und das Gerät ist beim Geräteregistrierungsdienst registriert.
• Rein lokale ImplementierungenDer Identitätsanbieter (IdP) ist AD FS, und die Registrierung erfolgt über den von AD FS bereitgestellten Unternehmensgeräteregistrierungsdienst.

Nach der Registrierung verfügt das Gerät über eine vertrauenswürdige Identität , die es ihm ermöglicht, sich beim Benutzer-Login beim Identitätsanbieter (IdP) zu authentifizieren. Es gibt verschiedene Registrierungsarten (Domänenbeitritt, Microsoft Entra-Beitritt, persönliche Registrierung usw.), die als Beitrittstypen bezeichnet werden und das weitere Verhalten von WHfB und SSO bestimmen.

2. Beschaffungsphase

Während der Bereitstellung verliert der Benutzer seine Passwortauthentifizierung und verfügt stattdessen über einen eigenen Windows Hello-Container auf dem Gerät. Dieser Container gruppiert die mit seinen Konten (Firmen-, Bildungs- und Privatkonten) verknüpften kryptografischen Daten getrennt nach Identitätsanbieter.

Der typische Beschaffungsprozess umfasst folgende Schritte:

1. Im Benutzerassistenten (CXH) authentifiziert sich der Benutzer mithilfe des IdP beim IdP. MFA (in der Regel Benutzername/Passwort plus ein zweiter Faktor).
2. Nach erfolgreicher MFA-Prüfung fordert das System den Benutzer zur Konfiguration auf. PIN und, falls kompatible Hardware verfügbar ist, ein oder mehrere biometrische Gesten (Gesicht, Fußabdruck).
3. Der Windows Hello-Container wird erstellt auf dem Gerät.
4. Das Team generiert ein öffentliches/privates Authentifizierungsschlüsselpaar, vorzugsweise in Verbindung mit TPM; falls kein TPM vorhanden ist, wird es durch Softwareverschlüsselung geschützt.
5. Der private Schlüssel wird lokal gespeichert, vom TPM versiegelt, sofern ein solcher vorhanden ist, und als solcher gekennzeichnet. nicht exportierbar.
6. Der öffentliche Schlüssel ist im Identitätsanbieter (IdP) registriert, der mit dem Benutzerkonto verknüpft ist:
   • In Cloud-Umgebungen schreibt der Geräteregistrierungsdienst die ID in das Microsoft Enter ID-Benutzerobjekt.
   • In lokalen Szenarien speichert AD FS den Schlüssel in Active Directory.

Ab diesem Zeitpunkt, wenn der Benutzer das Gerät mit einer PIN oder biometrischen Daten entsperrt, "löst" er tatsächlich die Verwendung dieses privaten Hello-Schlüssels aus , um dem Identitätsanbieter seine Identität nachzuweisen.

3. Details zum Windows Hello-Container und zu den Schlüsseltypen

Der Windows Hello-Container speichert nicht nur einen Schlüssel: Er kann verschiedene Arten von kryptografischem Material enthalten , von denen jede ihre eigene Funktion und ihren eigenen „Schutzmechanismus“ hat. Jeder Schutzmechanismus verschlüsselt seine Kopie des Authentifizierungsschlüssels mit einer anderen Technik (z. B. durch Einbetten eines TPM unter Verwendung der PIN als Entropie oder durch symmetrische Verschlüsselung, die von der PIN abgeleitet ist, falls kein TPM vorhanden ist).

Im Inneren des Containers finden wir:

• Eine primärer AuthentifizierungsschlüsselBei der Registrierung wird stets ein asymmetrisches (öffentliches/privates) Paar erstellt. Dieses muss jedes Mal per PIN oder Biometrie entsperrt werden. Wenn der Benutzer die PIN zurücksetzt, … Neues Kennwort und sämtliches Material, das durch die vorherige Verschlüsselung geschützt war, wird mit der neuen Verschlüsselung erneut verschlüsselt.
• Ein oder mehrere Benutzerkennschlüssel (Benutzer-ID-Schlüssel): Diese können je nach Identitätsanbieter (IdP) und Vertrauensmodell symmetrisch oder asymmetrisch sein. In zertifikatsbasierten Implementierungen werden diese Schlüssel verwendet, um Anfragen an die Zertifizierungsstelle (CA) oder für RDP, VPN usw. zu generieren.
• Optional, a administrativer Schlüssel, konzipiert für Reset-Szenarien (z. B. PIN-Wiederherstellung) und Daten, die mit dem TPM des Geräts verknüpft sind.

Benutzer-ID-Schlüssel dienen dem Nachweis des Besitzes des privaten Schlüssels gegenüber dem Dienst (z. B. durch Signieren einer Nonce). Active Directory, Microsoft Entra ID und persönliche Microsoft-Konten erfordern asymmetrische Schlüsselpaare. Das Gerät generiert das Paar, speichert den öffentlichen Teil und schützt den privaten Teil, der das Gerät niemals verlässt.

Verfügt Ihr Unternehmen über eine unternehmensweite PKI, können Sie Benutzer-ID-Schlüssel mit von Ihrer Zertifizierungsstelle ausgestellten Zertifikaten verknüpfen . Dadurch lässt sich WHfB in zertifikatsabhängige Anwendungen (klassische VPNs, RDP mit Smartcards usw.) integrieren. Benötigen Sie keine PKI, kann der Identitätsanbieter (IdP) diese Identifikationsdaten selbst generieren und verwalten, um die Komplexität zu reduzieren.

4. Schlüsselsynchronisation in hybriden Umgebungen

Bei Hybridbereitstellungen , bei denen Microsoft Entra ID und Active Directory parallel existieren, ist ein zusätzlicher Schritt erforderlich: die Synchronisierung des öffentlichen Hello-Schlüssels aus der Cloud mit dem lokalen Verzeichnis, damit Domänencontroller Benutzer authentifizieren können.

Der öffentliche Schlüssel ist im Attribut gespeichert. msDS-KeyCredentialLink des Benutzerobjekts in Active Directory, und die Synchronisierung wird verwaltet von Microsoft Connect SyncOhne diese Replikation wäre es für eine lokale Domäne unmöglich, die WHfB-basierte Authentifizierung von einem in Microsoft Entra eingebundenen Gerät zu überprüfen.

5. Zertifikatsregistrierung (bei Verwendung von Certificate Trust)

In Modellen, in denen WHfB auf Zertifikate für die Kerberos-Authentifizierung oder lokale Anwendungen angewiesen ist , kommt eine zusätzliche Phase hinzu: die Zertifikatsregistrierung.

Sobald der Schlüssel registriert ist, generiert der Client eine Zertifikatsanforderung und sendet diese an die Zertifizierungsstelle (CRA) , die sich üblicherweise auf dem AD FS-Server befindet und die Anforderung mit der Unternehmens-PKI koordiniert. Die Zertifizierungsstelle stellt das Zertifikat aus, das im Hello-Container des Benutzers auf dem Gerät gespeichert und zur Authentifizierung bei lokalen Ressourcen verwendet wird, die ein Smartcard-Zertifikat oder Ähnliches erwarten.

Tägliche Authentifizierung, SSO und die Rolle der Hardwaresicherheit

Im alltäglichen Gebrauch basiert die Authentifizierung beim Einschalten oder Entsperren des Computers stets auf dem privaten Teil der Windows Hello-Anmeldeinformationen (Schlüssel oder Zertifikat) sowie der Geste des Benutzers (PIN oder biometrische Daten). Diese Geste wird weder an den Identitätsanbieter (IdP) gesendet noch als solche im System gespeichert.

Die Authentifizierung erfolgt tatsächlich über zwei Faktoren :

• Etwas, das der Benutzer besitzt: der Schlüssel oder das Zertifikat, das mit dem Gerät verknüpft ist.
• Etwas, das der Benutzer weiß oder ist: eine lokale PIN oder biometrische Daten.

Wenn der Benutzer seine PIN eingibt oder seinen Fingerabdruck/sein Gesicht verwendet, gibt Windows den Authentifizierungsschlüssel aus seinem Container frei und signiert damit kryptografisch die an den Identitätsanbieter (IdP) gesendeten Daten . Der Identitätsanbieter überprüft diese Signatur anhand des gespeicherten öffentlichen Schlüssels und stellt, falls alles übereinstimmt, die für den Zugriff auf Ressourcen (Microsoft 365, SaaS-Anwendungen, lokale Ressourcen usw.) erforderlichen Token aus.

Weder die PIN noch das biometrische Profil verlassen das Gerät . Die PIN wird nicht einmal als Text gespeichert: Sie dient als Entropie für kryptografische Operationen und zum Entsperren von TPM-geschützten Daten. Der Identitätsanbieter (IdP) sieht lediglich den kryptografischen Nachweis, dass der Nutzer den registrierten privaten Schlüssel kontrolliert.

Master Refresh Token (PRT) und modernes SSO

Single Sign- On ( SSO) in der modernen Microsoft-Welt basiert auf einem Schlüsseltoken: dem Primary Refresh Token (PRT) . Es handelt sich um ein JSON Web Token, das Benutzer- und Geräteinformationen enthält und SSO für Anwendungen ermöglicht, die durch Microsoft Entra ID oder AD FS geschützt sind.

Das PRT wird durch Anmelden oder Entsperren des Geräts mit vertrauenswürdigen Anmeldeinformationen (WHfB oder herkömmlichen Anmeldeinformationen) erhalten, ähnlich wie das Kerberos TGT zuvor in einer rein lokalen Umgebung bezogen wurde. Auf Geräten :

• Treten Sie Microsoft bei. oder Hybride, die mit Microsoft Enter verknüpft sind: Die PRT wird beim Login selbst ausgegeben.
• Registrierte persönliche Geräte (BYOD): Das PRT wird generiert, wenn ein Arbeits- oder Bildungskonto zum Gerät hinzugefügt wird.

Ohne PRT müssten Benutzer ihre Anmeldeinformationen ständig neu eingeben, und bedingte Zugriffsrichtlinien basierend auf dem Gerätestatus könnten nicht ausgewertet werden . Mit WHfB und einem gültigen PRT wird nahtloses SSO erreicht, das gleichzeitig bedingt auf Gerätestatus, Compliance, Risiko und anderen Faktoren basiert.

Wichtige Richtlinieneinstellungen: SSO und Hardwaresicherheit

WHfB bietet umfassende Richtlinienkonfigurationen sowohl über CSP (für MDM wie Intune) als auch über GPO. Viele dieser Konfigurationen zielen darauf ab, SSO zu stärken und sicherzustellen, dass die verfügbare Sicherheitshardware auf dem Gerät stets genutzt wird.

Obligatorische Verwendung von Hardware-Sicherheitsgeräten (TPM)

Eine der wichtigsten Richtlinien schreibt vor, dass die Bereitstellung von Windows Hello for Business nur auf Geräten mit einem nutzbaren TPM (1.2 oder 2.0) erfolgen darf . Ein TPM bietet zusätzlichen Schutz, da der private Schlüssel an diese physische Komponente gebunden ist; selbst wenn ein Angreifer die Festplatte kopiert, kann er den Schlüssel nicht auf einem anderen Computer verwenden.

Mithilfe von CSP wird diese Konfiguration gesteuert mit:

• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice
• Und optional der Ausschluss bestimmter TPM 1.2 mit:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/ExcludeSecurityDevices/TPM12

Zusätzlich gibt es eine entsprechende Gruppenrichtlinie (GPO) unter den administrativen Vorlagen für Windows Hello for Business auf Computerebene. Durch Aktivierung dieser Richtlinie wird die Bereitstellung von WHfB auf Computern ohne gültiges TPM verhindert , wodurch die Sicherheit der Umgebung erheblich erhöht wird.

Lokales SSO konfigurieren: Zertifikat vs. Cloud-Vertrauenswürdigkeit

Für SSO gegenüber lokalen Ressourcen (Domänencontroller, lokale Anwendungen) kann WHfB drei Hauptvertrauensmodelle verwenden : zertifikatsbasiert, schlüsselbasiert (Key Trust) und seit Kurzem Cloud Kerberos Trust.

Es gibt zwei grundlegende Richtlinien :

• Verwendung eines Zertifikats zur lokalen Authentifizierung:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCertificateForOnPremAuth
  Wenn diese Option aktiviert ist, registriert WHfB ein Anmeldezertifikat innerhalb des Containers und verwendet es zur lokalen Authentifizierung.
• Verwendung von Cloud Trust für die lokale Authentifizierung:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth
  Wenn diese Funktion aktiviert ist, verwendet WHfB ein aus der Authentifizierung in Microsoft Entra ID abgeleitetes Kerberos-Ticket zur Authentifizierung gegenüber lokalen Ressourcen, ohne dass zusätzliche Zertifikate ausgestellt werden müssen.

Wenn diese Richtlinien deaktiviert oder nicht konfiguriert werden, verwendet das System – abhängig von den anderen aktiven Optionen – einen Schlüssel oder ein Zertifikat . In den Gruppenrichtlinien befinden sich diese Optionen unter „Windows-Komponenten“ > „Windows Hello for Business“ im Abschnitt „Computer und Benutzer“.

Hauptsteuerung: Windows Hello for Business aktivieren oder deaktivieren

Es gibt eine globale Richtlinie, die festlegt, ob ein Gerät WHfB verwendet und ob der Bereitstellungsassistent nach der Anmeldung gestartet wird:

• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork
• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/DisablePostLogonProvisioning

Mit ihnen können Sie :

• Alle Benutzer müssen WHfB auf dem Gerät bereitstellen.
• Die Nutzung von WHfB vollständig unterbinden.
• Jeder Benutzer kann selbst entscheiden, ob er Hello konfigurieren möchte.
• Verhindern Sie, dass der Assistent nach der ersten Anmeldung automatisch gestartet wird; dies ist hilfreich, wenn Sie verwenden eine Drittanbieterlösung um WHfB bereitzustellen.

PIN-Richtlinien, Wiederherstellung und Komplexitätskontrollen

Die Windows Hello-PIN ist ein zentraler Bestandteil der Lösung. Obwohl viele sie fälschlicherweise für ein kurzes Passwort halten, handelt es sich tatsächlich um einen gerätespezifischen Faktor, der durch das TPM geschützt ist und deutlich weniger wiederverwendbar als ein herkömmliches Passwort.

Ablaufdatum, Verlauf und Länge der PIN

PIN-Richtlinien ermöglichen es Ihnen, deren Lebenszyklus und Komplexität auf ähnliche Weise – wenn auch detaillierter – wie bei herkömmlichen Passwörtern anzupassen :

• AblaufSie können die Gültigkeitsdauer der PIN auf 1 bis 730 Tage festlegen. Ist der Wert 0, läuft die PIN nie ab (Standardwert).
• Rekord: Gibt an, wie viele vorherige PINs nicht wiederverwendet werden dürfen (zwischen 0 und 50). Ein Wert von 0 bedeutet, dass kein Verlauf gespeichert wird.
• Minimale und maximale Länge: Konfigurierbare Mindestlänge ab 4 Zeichen; Höchstlänge bis zu 127 Zeichen, wobei stets zu beachten ist, dass die Mindestlänge kleiner als die Höchstlänge ist und standardmäßig, falls nicht anders konfiguriert, eine Mindestlänge von 6 Zeichen erforderlich ist.

Wenn diese Richtlinien nicht festgelegt sind, erlaubt das Standardverhalten bis zu 127 Zeichen und erfordert eine PIN von mindestens 6 Zeichen, ohne dass über die von Ihnen definierten Komplexitätsregeln hinaus weitere Durchsetzungsmaßnahmen erfolgen.

Anforderungen an die PIN-Zusammensetzung

Sie können festlegen, welche Zeichentypen unterstützt und welche für die Windows Hello-PIN erforderlich sind:

• ZiffernWenn Sie die Richtlinie so einstellen, dass Ziffern erforderlich sind, muss die PIN mindestens eine Ziffer enthalten. Wenn Sie diese Einstellung deaktivieren, sind Ziffern nicht zulässig. Ohne diese Einstellung sind Ziffern zwar erlaubt, aber nicht erforderlich.
• Kleinbuchstaben: ermöglicht es Ihnen, mindestens eine dieser Optionen vorzuschreiben, sie vollständig zu verbieten oder sie optional zu lassen.
• Letras mayúsculasGleiches Schema wie bei Kleinbuchstaben.
• Spezielle CharaktereMindestens eines davon kann erforderlich sein, sie können verboten oder erlaubt sein. Es handelt sich um einen breit gefächerten Satz von Symbolen (! " # $ % & ' ( ) + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~).

Diese Regeln ermöglichen es Ihnen, das Gleichgewicht zwischen Benutzerfreundlichkeit und Robustheit anzupassen . Ist die Komplexität jedoch zu hoch, steigt das Risiko vergessener PINs und Support-Tickets – etwas, das viele Organisationen gerade bei der Einführung von WHfB vermeiden möchten.

PIN-Wiederherstellung

Die PIN-Wiederherstellung ermöglicht es Benutzern, eine vergessene PIN zurückzusetzen, ohne die zugehörigen Anmeldeinformationen oder Zertifikate (einschließlich der Schlüssel zu persönlichen Konten auf diesem Computer) zu verlieren. Windows Hello verschlüsselt dazu ein Wiederherstellungsgeheimnis, das lokal gespeichert wird und nur vom Wiederherstellungsdienst und dem Gerät selbst entschlüsselt werden kann.

Diese Funktion erfordert die Durchführung einer Multi-Faktor-Authentifizierung mit Microsoft Enterprise ID, um die PIN wiederherzustellen. Wenn Sie die entsprechende Richtlinie (über CSP oder GPO) aktivieren, generiert und speichert Windows dieses Wiederherstellungsgeheimnis. Wenn Sie die Richtlinie deaktivieren oder nicht konfigurieren, erstellt oder speichert das Gerät das Geheimnis nicht . Im Falle eines vergessenen PIN-Eintrags muss der Benutzer die alte PIN vollständig löschen, eine neue PIN vergeben und sich für die Dienste, auf die er mit der alten PIN zugegriffen hat, erneut registrieren.

Biometrie, Anti-Spoofing-Schutz und ESS

Biometrische Daten in WHfB (Gesicht, Fingerabdruck, Iris) ergänzen die PIN, ersetzen sie aber nicht vollständig. Es gibt immer eine Backup-PIN, falls der Sensor ausfällt oder die Situation seine Verwendung nicht zulässt.

Verbesserter Schutz vor Spoofing

Es gibt eine spezielle Richtlinie, die einen verbesserten Schutz vor Manipulationen bei der Gesichtserkennung vorschreibt. Ist diese aktiviert, lässt Windows die Gesichtsauthentifizierung nur dann zu, wenn Sensor und Protokolldatenbank diese erweiterten Anforderungen an die Angriffserkennung erfüllen (z. B. die Verhinderung von Anmeldungen mithilfe von Fotos, Videos oder einfachen Deepfakes).

Wenn es deaktiviert oder nicht konfiguriert ist, Windows wird diesen verstärkten Schutz nicht erfordern. Die Gesichtserkennung wird weniger restriktiv sein. Der zugehörige CSP-Pfad ist ./Device/Vendor/MSFT/PassportForWork/Biometrics/FacialFeaturesUseEnhancedAntiSpoofingDas Äquivalent findet sich auch in den Gruppenrichtlinien unter den Biometrieoptionen von Windows Hello for Business.

ESS: Verbesserte Anmeldesicherheit mit Peripheriegeräten

Enhanced Sign-in Security (ESS) ist eine zusätzliche Ebene, die VBS (Virtualization Based Security), TPM 2.0 und spezifische Komponenten kombiniert, um biometrische Vorlagen und Vergleichsvorgänge hardwareseitig zu isolieren.

Bei ESS werden biometrische Daten (Gesicht, Fingerabdruck) und deren Vergleich in isolierten und geschützten Speicherbereichen durchgeführt , auf die das übrige Betriebssystem keinen direkten Zugriff hat. Auch die Verbindung zwischen den Sensoren und dem Algorithmus ist geschützt, sodass Schadsoftware oder Angreifer keine falschen biometrischen Daten einschleusen oder reproduzieren können, um Anmeldungen zu simulieren oder Benutzer auszusperren.

Politik EnableESSwithSupportedPeripherals ermöglicht zwei Hauptwerte:

• 0ESS ist auch dann aktiviert, wenn periphere oder integrierte Sensoren vorhanden sind, die ESS nicht unterstützen. Authentifizierungsvorgänge sind mit diesen Geräten unter bestimmten Einschränkungen möglich. Dies ist nicht die empfehlenswerteste Option.
• 1ESS aktiviert Sünde Es akzeptiert periphere oder integrierte Sensoren, die nicht ESS unterstützen. Das bedeutet, dass biometrische Vorgänge von Geräten, die ESS nicht unterstützen, für Windows Hello blockiert sind. Dies ist die Konfiguration mit größere Sicherheit.

Wenn ESS deaktiviert oder nicht konfiguriert ist, blockieren die Geräte Sensoren , die nicht mit ESS kompatibel sind, und verfolgen so einen konservativen Sicherheitsansatz.

Allgemeine Verwendung von Biometrie

Die Richtlinie „Biometrie verwenden“ steuert, ob Windows Hello for Business biometrische Gesten zulässt oder nur PINs unterstützt. Ist die Richtlinie aktiviert oder nicht konfiguriert, sind biometrische Daten zulässig; ist sie deaktiviert, ist ihre Verwendung untersagt, und Benutzer müssen sich stets mit einer PIN oder anderen Authentifizierungsfaktoren authentifizieren.

In jedem Fall die biometrischen Daten:

• Sie werden gelagert nur auf dem lokalen Gerät (Datenbank in C:\Windows\System32\WinBioDatabase).
• Jeder Sensor verfügt über eine eigene Datei und einen eindeutigen, zufällig generierten Schlüssel, der mit AES im CBC-Modus und einem SHA-256-Hash verschlüsselt ist.
• Sie werden weder an externe Server gesendet noch zwischen Computern synchronisiert, wodurch es Angreifern unmöglich ist, zentrale Sammelpunkte zu schaffen.

Integration mit Smartcards und älteren Anwendungen

Viele Organisationen setzen weiterhin auf Smartcards und Anwendungen, die „Smartcard-ähnliche“ Zertifikate erwarten . WHfB bietet Optionen zur Emulation oder Integration dieser Umgebungen, ohne die Vorteile moderner Authentifizierungsmethoden zu beeinträchtigen.

Emulation und Aufzählung von Smartcards

Standardmäßig verhindert Windows, dass Benutzer desselben Computers die für andere Benutzer bereitgestellten Windows Hello-Anmeldeinformationen sehen. Mithilfe einer Richtlinie können Sie dies in folgenden Fällen deaktivieren:

• Ein Benutzer kann auf demselben Computer Konten mit und ohne Berechtigungen haben.
• Er möchte sich mit dem "normalen" Konto anmelden, aber vor dem Abmelden seine Berechtigungen mit seinen Hello-Zugangsdaten erhöhen.

Es besteht auch die Möglichkeit, die Smartcard-Emulation zu deaktivieren . Ist diese Option aktiviert, sind WHfB-Anmeldeinformationen nicht mehr mit Anwendungen kompatibel, die eine Smartcard voraussetzen. Bleibt die Option deaktiviert oder nicht konfiguriert, stellt Windows diese Emulation weiterhin automatisch bereit.

Verwenden Sie Hello-Zertifikate als Smartcard-Zertifikate

Eine weitere wichtige Richtlinie es UseHelloCertificatesAsSmartCardCertificatesWenn diese Option aktiviert ist, können Anwendungen die folgenden Aufgaben übernehmen: Windows Hello-Zertifikate für Unternehmen, wie z. B. Smartcard-Zertifikate.In diesem Zusammenhang spielen jedoch biometrische Faktoren eine wichtige Rolle. Sind nicht verfügbar wenn die Autorisierung zur Verwendung des privaten Schlüssels des Zertifikats angefordert wird.

Wenn diese Einstellung nicht konfiguriert oder deaktiviert ist , verwenden Anwendungen Hello-Zertifikate nicht auf diese Weise, und die biometrische Authentifizierung steht dem Benutzer weiterhin zur Verfügung. Diese Option kann nicht gleichzeitig mit der Richtlinie aktiviert sein, die die Smartcard-Emulation deaktiviert.

PKI-, CRL- und Domänencontroller-Zertifikatsanforderungen

Bei Bereitstellungen, bei denen WHfB SSO für lokale Ressourcen mittels Zertifikaten und Kerberos bereitstellen muss , muss die PKI- und Zertifikatsinfrastruktur gut abgestimmt sein, insbesondere wenn es Geräte gibt, die nur mit Microsoft Entra verbunden sind und sich gegenüber Active Directory authentifizieren.

CRL-Verteilerpunkt, der von mit Entra verbundenen Geräten zugänglich ist

Ein entscheidender Punkt ist die Zertifikatssperrliste (CRL) . Wenn eine Zertifizierungsstelle ein Zertifikat widerruft, trägt sie entsprechende Informationen in diese Liste ein, und Windows konsultiert diese, um zu überprüfen, ob das Zertifikat noch gültig ist.

In vielen lokalen Umgebungen wird der CDP (CRL-Verteilungspunkt) als LDAP-Pfad in Active Directory veröffentlicht . Dies funktioniert gut für Domänencomputer, jedoch nicht für Geräte, die nur mit Microsoft Entra verbunden sind, da diese Active Directory vor der Authentifizierung nicht lesen können. Dadurch entsteht eine Zirkelabhängigkeit: Um das Domänencontrollerzertifikat zu validieren, muss Active Directory gelesen werden, was jedoch ohne vorherige Authentifizierung nicht möglich ist.

Die Lösung besteht darin, das CDP auf einem Webserver zu veröffentlichen, der über HTTP (nicht HTTPS) erreichbar ist und keine vorherige Authentifizierung erfordert. Das typische Vorgehen umfasst Folgendes:

• Installieren Sie IIS oder einen anderen Webserver auf einem internen Server.
• Erstellen Sie ein virtuelles Verzeichnis (zum Beispiel, cdp) das auf einen freigegebenen Ordner verweist, in dem die Zertifizierungsstelle die CRLs veröffentlichen kann.
• Passen Sie die NTFS- und Freigabeberechtigungen so an, dass die Zertifizierungsstelle in diesen Ordner schreiben kann.
• Erstellen Sie einen DNS-Eintrag (zum Beispiel, crl.midominio.com) verweist auf diesen Server.
• Konfigurieren Sie den Broadcasting AC so, dass er Folgendes enthält: CDP HTTP in den Erweiterungen der ausgestellten Zertifikate und um die CRL und die Delta-CRL an diesem Ort zu veröffentlichen.

Nach Sie müssen die Veröffentlichung einer neuen CRL erzwingen und überprüfen, ob diese über einen Browser aufgerufen werden kann. http://crl.tudominio.com/cdp und die Dateien ansehen .crl generiert.

Neuausstellung des Domänencontrollerzertifikats und strenge KDC-Validierung

Vorhandene Zertifikate werden nicht automatisch mit dem neuen CDP aktualisiert; sie müssen erneuert werden . Dies gilt insbesondere für Domänencontroller-Zertifikate, die für die Kerberos-Authentifizierung verwendet werden. WHfB erzwingt die Funktion „Strenge KDC-Validierung“, wenn sich ein in Microsoft Entra eingebundenes Gerät an einer lokalen Domäne authentifiziert. Daher muss das Domänencontroller-Zertifikat mehrere Anforderungen erfüllen:

• Der DC muss den privaten Schlüssel des vorgelegten Zertifikats besitzen.
• Die Stammzertifizierungsstelle, die das DC-Zertifikat ausgestellt hat, muss sich im Wurzeln des Vertrauens Vorrichtung.
• Sie müssen die verwenden Kerberos-Authentifizierungszertifikatvorlagekeine alten Vorlagen.
• Das Zertifikat muss die EKU enthalten. KDC-Authentifizierung.
• Der alternative Subjektname muss einen DNS-Namen enthalten, der den Domänennamen abgleichen.
• Der Signaturalgorithmus muss mindestens SHA256.
• Der öffentliche Schlüssel muss sein 2048-Bit-RSA.

Nach der Konfiguration der Zertifizierungsstelle und der Erneuerung der Domänencontroller-Zertifikate müssen Sie in der Registerkarte „Details“ jedes Zertifikats überprüfen, ob der korrekte HTTP-CDP vorhanden ist. Dies ist unerlässlich, damit in Entra eingebundene Geräte den Domänencontrollern bei der Authentifizierung mit WHfB vertrauen können.

Implementieren Sie das CA-Root-Zertifikat auf den mit Entra verbundenen Geräten

Schließlich müssen Geräte, die mit Microsoft Entra verbunden sind, der Stammzertifizierungsstelle des Unternehmens vertrauen. Dies wird erreicht, indem das Stammzertifikat aus der Vertrauenskette des Domänencontroller-Zertifikats exportiert und an die Computer verteilt wird, beispielsweise mithilfe von:

• Eine Politik von Ausrüstungsvertrauenszertifikat in Microsoft Intune, wobei auf den vertrauenswürdigen Stammspeicher des Teams verwiesen wird.
• Oder gleichwertige Methoden in anderen MDM-/Managed-Lösungen.

Wird dieser Schritt ausgelassen, so vertrauen die Geräte den DCs auch dann nicht, wenn alle anderen Elemente korrekt konfiguriert sind, und die WHfB-Authentifizierung schlägt auf der TLS-/Zertifikatsebene fehl.

Windows Hello for Business stellt einen bedeutenden Fortschritt in puncto Sicherheit und Anmeldeerfahrung dar : Es ersetzt Passwörter durch hardwarebasierte, zentral verwaltete Anmeldeinformationen und bietet so modernes, phishing-resistentes Single Sign-On (SSO) in Cloud- und On-Premises-Umgebungen. Damit es jedoch optimal funktioniert, ist es entscheidend, die Identitäts- und PKI-Infrastruktur ernst zu nehmen, geeignete Richtlinien für PINs, Biometrie und die obligatorische Nutzung von TPMs festzulegen und die Einführung schrittweise mit transparenter Kommunikation an die Benutzer durchzuführen. So wird die Umstellung als Verbesserung und nicht als zusätzliche Belastung für die IT wahrgenommen.