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

Windows Hallo fürs Geschäft Es hat sich zum Kernstück der passwortlosen Strategie von Microsoft entwickelt: Es kombiniert PINs, Biometrie und kryptografische Schlüssel, sodass sich Benutzer ohne Passworteingabe anmelden können, jedoch mit einem deutlich höheren Sicherheitsniveau. All dies wird unterstützt durch Hardware-Sicherheit, TPM und moderne SSO-Modelle sowohl in der Cloud als auch in hybriden und On-Premises-Umgebungen.

Es ist weit mehr als nur „die Windows-PIN“. Windows Hello for Business (WHfB) 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 unerlässlich, die Zusammenhänge – Registrierung, Bereitstellung, Schlüsselsynchronisierung, Zertifikate und Authentifizierung – zu verstehen, um eine reibungslose und effektive Implementierung zu gewährleisten. Robustes und phishingresistentes Single Sign-On.

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

Windows Hallo fürs Geschäft Es handelt sich um die Unternehmens- und Verwaltungsversion von Windows Hello. Sie ersetzt das Passwort 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 gegenüber Microsoft-Anmelde-ID, Active Directory oder AD FSDienste, die auf sie angewiesen sind.

Anstatt auf gemeinsame Geheimnisse (Passwörter, OTPs, SMS-Codes) zu setzen, generiert WHfB einen öffentliches/privates Schlüsselpaar Pro Benutzer und Gerät. 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 stellt lediglich mit seiner PIN oder seinen biometrischen Daten „Entropie“ bereit, um den privaten Schlüssel freizugeben, wenn er sich authentifizieren möchte.

Das Ergebnis ist ein Authentifizierungserlebnis resistent gegen Phishing, Zugangsdatendiebstahl und Brute-Force-AngriffeAufrechterhaltung von SSO sowohl in der Cloud (Microsoft 365, moderne Anwendungen) als auch bei lokalen Diensten (Kerberos, ältere Anwendungen, zertifikatsbasierte VPNs usw.).

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

Um WHfB vollständig zu verstehen Es empfiehlt sich, den Vorgang 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 Team einen Prozess durchlaufen, GeräteregistrierungDieser 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 Dies ermöglicht die Authentifizierung beim Identitätsanbieter (IdP) beim Anmelden eines Benutzers. Es gibt verschiedene Registrierungsarten (Domänenbeitritt, Microsoft Login-Beitritt, persönliche Registrierung usw.), die als Registrierungsarten bezeichnet werden. Beziehungstypen oder „Verknüpfungstypen“welche das nachfolgende Verhalten von WHfB und SSO bestimmen.

2. Beschaffungsphase

Während der Bereitstellung hört der Benutzer auf, ein „Passwortbenutzer“ zu sein, und wird zu einem Benutzer mit eigenem Passwort. Windows Hello-Container auf dem Gerät. Dieser Container gruppiert das kryptografische Material, das mit Ihren Konten (Firmen-, Bildungs- und Privatkonten) verknüpft ist, isoliert nach Identitätsanbieter.

Der typische Lieferfluss folge diesen Schritten:

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 Nutzung aus. dieser private Schlüssel von Hello um ihre Identität gegenüber dem Identitätsanbieter nachzuweisen.

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

Der Windows Hello-Container speichert nicht nur einen Schlüssel: Er kann mehrere Schlüssel gleichzeitig speichern. verschiedene Arten von kryptographischem MaterialJeder dieser Mechanismen hat seine eigene Funktion und seinen eigenen „Schutzmechanismus“. Jeder Schutzmechanismus verschlüsselt seine Kopie des Authentifizierungsschlüssels mit einer anderen Technik (zum Beispiel durch Versiegelung im TPM unter Verwendung der PIN als Entropie oder durch symmetrische Verschlüsselung, die von der PIN abgeleitet ist, falls kein TPM vorhanden ist).

Im Behälter wir können finden:

• 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.

Benutzeridentifikationsschlüssel werden verwendet, um Besitz des privaten Schlüssels nachweisen vor dem Dienst (z. B. Signieren einer Nonce). Active Directory, Microsoft Entra ID und persönliche Microsoft-Konten benötigen 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.

Wenn Ihre Organisation über eine unternehmensweite PKI verfügt, können Sie Benutzeridentifikationsschlüssel zuordnen. von Ihrer Zertifizierungsstelle ausgestellte ZertifikateDies ermöglicht WHfB die Integration mit zertifikatsabhängigen Anwendungen (klassische VPNs, RDP mit Smartcards usw.). Falls keine PKI benötigt wird, kann der Identitätsanbieter (IdP) diese Identifikationsinformationen selbst generieren und verwalten, um die Komplexität zu reduzieren.

4. Schlüsselsynchronisation in hybriden Umgebungen

Bei hybriden BereitstellungenWenn Microsoft Entra ID und Active Directory gleichzeitig verwendet werden, ist eine zusätzliche Phase erforderlich: Synchronisieren Sie den öffentlichen Hello-Schlüssel von der Cloud zum 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 AnwendungenEine weitere Phase tritt in Erscheinung: die Registrierung der Zertifikate.

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

Tägliche Authentifizierung, SSO und die Rolle der Hardwaresicherheit

Im AlltagBeim Einschalten oder Entsperren des Computers erfolgt die Authentifizierung stets anhand des privaten Teils der Windows Hello-Anmeldeinformationen (Schlüssel oder Zertifikat) und der Geste des Benutzers (PIN oder biometrische Daten). Diese Geste wird niemals an den Identitätsanbieter (IdP) gesendet oder als solche im System gespeichert.

Authentifizierung ist de facto 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 die PIN eingibt oder die Fingerabdruck-/Gesichtserkennung verwendet, gibt Windows den Authentifizierungsschlüssel aus seinem Container frei und verwendet ihn, um Daten, die an den IdP gesendet werden, kryptografisch signierenDer Identitätsanbieter prü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.) benötigten Token aus.

Weder die PIN noch die biometrische Vorlage Gerät verlassenDie 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 Benutzer den registrierten privaten Schlüssel kontrolliert.

Master Refresh Token (PRT) und modernes SSO

El Einmalige Anmeldung In der modernen Microsoft-Welt gibt es ein Schlüsselsymbol: den Primäres Aktualisierungstoken (PRT)Es handelt sich um ein JSON Web Token, das Benutzer- und Geräteansprüche enthält und SSO für Anwendungen ermöglicht, die durch Microsoft Entra ID oder AD FS geschützt sind.

Die PRT wird erhalten bei Melden Sie sich an oder entsperren Sie das Gerät. mit einer vertrauenswürdigen Anmeldeinformation (WHfB oder traditionelle Anmeldeinformationen), auf eine Weise, die der Art und Weise, wie das Kerberos TGT zuvor in einer rein lokalen Umgebung erhalten wurde, analog ist. 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 ständig Anmeldeinformationen und bedingte Zugriffsrichtlinien basierend auf dem Gerätestatus eingeben. konnte nicht ausgewertet werdenMit WHfB und einem gültigen PRT wird ein reibungsloser SSO erreicht, der jedoch auch vom Zustand der Ausrüstung, der Compliance, dem Risiko usw. abhängt.

Wichtige Richtlinieneinstellungen: SSO und Hardwaresicherheit

WHfB bietet eine breite Palette von Richtlinieneinstellungen Sowohl über CSP (für MDM wie Intune) als auch über GPO. Viele davon konzentrieren sich auf die Stärkung von SSO und die Gewährleistung, 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 für Unternehmen nur in Geräte mit nutzbarem TPM (1.2 oder 2.0)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.

Durch CSP, diese Konfiguration Es wird kontrolliert von:

• ./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 ein GPO-Äquivalent unter den administrativen Vorlagen von Windows Hallo fürs Geschäft auf Teamebene. Falls aktiviert, Die WHfB-Bereitstellung ist auf Geräten ohne gültiges TPM nicht verfügbar.wodurch die Sicherheit der Umwelt drastisch erhöht wird.

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

Für SSO bei lokalen Ressourcen (Domänencontroller, lokale Anwendungen) kann WHfB Folgendes verwenden: drei Hauptmodelle des Vertrauens: zertifikatsbasiert, schlüsselbasiert (Key Trust) und, in jüngerer Zeit, Cloud Kerberos Trust (Vertrauen in die Cloud).

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, greift das System auf eine andere Methode zurück. Schlüssel oder ZertifikatAbhängig von den anderen aktiven Optionen. In der Gruppenrichtlinie befinden sich diese Optionen in den Abschnitten „Computer“ und „Benutzer“ unter „Windows-Komponenten“ > „Windows Hello for Business“.

Hauptsteuerung: Windows Hello for Business aktivieren oder deaktivieren

Es gibt eine globale Richtlinie, um zu entscheiden, ob ein Gerät WHfB nutzen oder nicht Und wenn 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 Es ist eine der Säulen der Lösung. Obwohl viele es mit einem „kurzen“ Passwort verwechseln, handelt es sich tatsächlich um einen lokalen, gerätegebundenen 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, Ihre Lebenszyklus und Komplexität ähnlich – wenn auch detaillierter – wie herkömmliche Passwörter:

• 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, gilt das Standardverhalten. bis zu 127 Zeichen und erfordert eine PIN von mindestens 6, ohne weitere Anforderungen über die von Ihnen definierten Komplexitätsregeln hinaus.

Anforderungen an die PIN-Zusammensetzung

du kannst entscheiden Welche Zeichentypen werden für die Windows Hello-PIN akzeptiert und welche sind erforderlich?

• 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 (! " # $ % & ' ( ) + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~).

Mithilfe dieser Regeln können Sie das Gleichgewicht zwischen Benutzerfreundlichkeit und RobustheitWird die Komplexität jedoch übertrieben, steigt das Risiko, PINs und Support-Tickets zu vergessen – etwas, das viele Organisationen gerade bei der Einführung von WHfB vermeiden wollen.

PIN-Wiederherstellung

La PIN-Wiederherstellung Es ermöglicht dem Benutzer, 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. Dazu verschlüsselt Windows Hello ein Wiederherstellungsgeheimnis, das lokal gespeichert wird, sodass es nur vom Wiederherstellungsdienst und dem Gerät selbst entschlüsselt werden kann.

Diese Funktionalität erfordert, dass der Benutzer Folgendes ausführt Multifaktor-Authentifizierung versus Microsoft Enter ID Um die PIN wiederherzustellen, muss die entsprechende Richtlinie (über CSP oder GPO) aktiviert sein. Windows generiert und speichert dann das Wiederherstellungsgeheimnis. Wenn Sie die Richtlinie deaktivieren oder nicht konfigurieren, wird das Gerät Es wird weder erschaffen noch erhalten Das Geheimnis und, falls der Benutzer die PIN vergisst, muss er sie vollständig löschen und eine neue PIN festlegen sowie sich erneut für die Dienste registrieren, zu denen die vorherige PIN Zugang gewährte.

Biometrie, Anti-Spoofing-Schutz und ESS

Biometrie bei WHfB Gesichtserkennung, Fingerabdruckerkennung und Iriserkennung ergänzen die PIN, ersetzen sie aber nicht vollständig. Es gibt immer eine Backup-PIN für den Fall, dass der Sensor ausfällt oder die Situation seine Verwendung nicht zulässt.

Verbesserter Schutz vor Spoofing

Es gibt eine spezifische Richtlinie, die Folgendes vorschreibt verbesserter Schutz vor Spoofing (Verbesserter Anti-Spoofing-Schutz) bei der Gesichtserkennung. Wenn diese Funktion aktiviert ist, lässt Windows die Gesichtsauthentifizierung nur dann zu, wenn Sensor und Protokolldatenbank diese erweiterten Anforderungen an die Angriffserkennung erfüllen (z. B. Verhinderung der Anmeldung mit 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

La Erweiterte Anmeldesicherheit (ESS) Es handelt sich um eine zusätzliche Schicht, die VBS (Virtualization Based Security), TPM 2.0 und spezifische Komponenten kombiniert, um biometrische Vorlagen und Vergleichsvorgänge hardwareseitig zu isolieren.

Mit ESS werden biometrische Daten (Gesicht, Fingerabdruck) und Vergleiche durchgeführt in isolierte und geschützte SpeicherregionenHierbei handelt es sich um Datenpunkte, 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 es deaktiviert oder nicht konfiguriert ist, wird es auf ESS-Geräten Sie blockieren die Sensoren. die nicht mit ESS kompatibel sind, wodurch ein konservativer Sicherheitsansatz beibehalten wird.

Allgemeine Verwendung von Biometrie

Politik Biometrie nutzen Steuert, ob Windows Hello for Business biometrische Gesten zulässt oder nur PINs unterstützt. Ist diese Option aktiviert oder nicht konfiguriert, sind biometrische Daten zulässig; ist sie deaktiviert, ist ihre Verwendung untersagt und Benutzer müssen sich immer mit einer PIN authentifizieren. PIN oder andere Faktoren.

Auf jeden Fall, biometrische 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 sind nach wie vor darauf angewiesen. Smartcards und Anwendungen, die auf Zertifikate vom Typ „Smartcard“ wartenWHfB bietet Optionen zur Emulation oder Integration dieser Umgebungen, ohne die Vorteile moderner Authentifizierungsmethoden zu verlieren.

Emulation und Aufzählung von Smartcards

standardmäßigWindows verhindert, dass Benutzer desselben Computers die für andere Benutzer bereitgestellten Windows Hello-Anmeldeinformationen sehen. Eine Richtlinie ermöglicht es Ihnen, dies in folgenden Fällen zu 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 von Smartcard-Emulation deaktivierenWenn diese Option aktiviert ist, sind WHfB-Anmeldeinformationen nicht mehr mit Anwendungen kompatibel, die eine Smartcard erwarten. Wenn sie deaktiviert oder nicht konfiguriert bleibt, 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 es nicht konfiguriert oder deaktiviert istDie Anwendungen nutzen Hello-Zertifikate nicht auf diese Weise, und biometrische Daten stehen dem Benutzer weiterhin zur Verfügung. Diese Option kann nicht gleichzeitig mit der Richtlinie aktiviert werden, die die Smartcard-Emulation deaktiviert.

PKI-, CRL- und Domänencontroller-Zertifikatsanforderungen

Bei Bereitstellungen, bei denen WHfB SSO für lokale Ressourcen bereitstellen muss, Zertifikate und KerberosDie PKI- und Zertifikatsinfrastruktur muss ordnungsgemäß konfiguriert sein, insbesondere wenn es Nur Geräte, die mit Microsoft verbunden sind. Eingabe das sich gegenüber Active Directory authentifizieren wird.

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

Einer der entscheidenden Punkte ist der Zertifikatssperrliste (CRL)Wenn eine Zertifizierungsstelle ein Zertifikat widerruft, fügt sie dieser Liste Informationen hinzu, und Windows konsultiert diese Liste, um zu überprüfen, ob das Zertifikat noch gültig ist.

In vielen On-Premise-Umgebungen CDP (CRL-Verteilerpunkt) wird als Route veröffentlicht LDAP in Active DirectoryDies funktioniert einwandfrei für in eine Domäne eingebundene Rechner, 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 in einem zu veröffentlichen. Webserver, erreichbar über HTTP (nicht HTTPS).die keine vorherige Authentifizierung erfordert. Das typische Verfahren 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

Bereits ausgestellte Zertifikate werden nicht automatisch mit dem neuen CDP aktualisiert; erneuernKonkret geht es um Domänencontrollerzertifikate, die für die Kerberos-Authentifizierung verwendet werden. WHfB erzwingt diese Funktion. "Strenge KDC-Validierung" Wenn sich ein in Microsoft Entra eingebundenes Gerät gegenüber einer lokalen Domäne authentifiziert, muss das DC-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 für Geräte, die nur mit Entra-Vertrauensdomänencontrollern verbunden sind bei der Authentifizierung mit WHfB.

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

Schließlich können auch Geräte, die mit Microsoft Entra verbunden sind, … Sie müssen der Root-Zertifizierungsstelle vertrauen. des Unternehmens. Dies wird erreicht, indem das Stammzertifikat aus der Vertrauenskette des DC-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, vertrauen die Geräte den Domänencontrollern und Authentifizierungen mit WHfB nicht, selbst wenn alle anderen Elemente korrekt konfiguriert sind. Sie werden auf der TLS-/Zertifikatsebene scheitern..

Windows Hello für Unternehmen stellt einen bedeutenden Fortschritt in puncto Sicherheit und Anmeldeerfahrung dar.Es ersetzt Passwörter durch gerätegebundene Anmeldeinformationen, die durch Hardware geschützt und zentral verwaltet werden und so ein modernes, phishing-resistentes Single Sign-On (SSO) in Cloud- und On-Premise-Umgebungen ermöglichen. Damit es jedoch optimal funktioniert, muss die Vorbereitung der Identitäts- und PKI-Infrastruktur sorgfältig erfolgen. Es müssen geeignete Richtlinien für PINs, Biometrie und die obligatorische Nutzung von TPMs definiert werden. Die Einführung muss schrittweise und mit transparenter Kommunikation an die Nutzer erfolgen, damit die Umstellung als Verbesserung und nicht als zusätzliche IT-Komplikation wahrgenommen wird.