Windows Hello for Business-Authentifizierung
Windows Hello for Business Authentifizierung ist eine kennwortlose, zweistufige Authentifizierung. Die Authentifizierung mit Windows Hello for Business bietet eine bequeme Anmeldeoberfläche, die den Benutzer sowohl bei Microsoft Entra ID- als auch bei Active Directory-Ressourcen authentifiziert.
Microsoft Entra verbundenen Geräte authentifizieren sich bei Microsoft Entra ID während der Anmeldung und können sich optional bei Active Directory authentifizieren. Microsoft Entra hybrid eingebundene Geräte authentifizieren sich während der Anmeldung bei Active Directory und authentifizieren sich bei Microsoft Entra ID im Hintergrund.
Microsoft Entra der Authentifizierung in Microsoft Entra ID
Hinweis
Alle Microsoft Entra verbundenen Geräte authentifizieren sich bei Windows Hello for Business, um auf die gleiche Weise zu Microsoft Entra ID. Der Windows Hello for Business Vertrauenstyp wirkt sich nur darauf aus, wie sich das Gerät bei der lokalen AD-Instanz authentifiziert.
| Phase | Beschreibung |
|---|---|
| A | Die Authentifizierung beginnt, wenn der Benutzer den Sperrbildschirm schließt, wodurch Winlogon ausgelöst wird, um den Windows Hello for Business Anmeldeinformationsanbieter anzuzeigen. Der Benutzer stellt seine Windows Hello Geste (PIN oder Biometrie) bereit. Der Anmeldeinformationsanbieter packt diese Anmeldeinformationen und gibt sie an Winlogon zurück. Winlogon übergibt die gesammelten Anmeldeinformationen an lsass. Lsass übergibt die gesammelten Anmeldeinformationen an den Cloudauthentifizierungs-Sicherheitssupportanbieter, der als Cloud-AP-Anbieter bezeichnet wird. |
| B | Der Cloud-AP-Anbieter fordert eine Nonce von Microsoft Entra ID an. Microsoft Entra ID gibt eine Nonce zurück. Der Cloud-AP-Anbieter signiert die Nonce mithilfe des privaten Schlüssels des Benutzers und gibt die signierte Nonce an die Microsoft Entra ID zurück. |
| C | Microsoft Entra ID überprüft die signierte Nonce mithilfe des sicher registrierten öffentlichen Schlüssels des Benutzers anhand der Noncesignatur. Microsoft Entra ID überprüft dann die zurückgegebene signierte Nonce und erstellt einen PRT mit Sitzungsschlüssel, der mit dem Transportschlüssel des Geräts verschlüsselt ist, und gibt ihn an den Cloud-AP-Anbieter zurück. |
| D | Der Cloud-AP-Anbieter empfängt das verschlüsselte PRT mit Sitzungsschlüssel. Mithilfe des privaten Transportschlüssels des Geräts entschlüsselt der Cloud-AP-Anbieter den Sitzungsschlüssel und schützt den Sitzungsschlüssel mithilfe des TPM des Geräts. |
| E | Der Cloud-AP-Anbieter gibt eine erfolgreiche Authentifizierungsantwort an lsass zurück. Lsass speichert das PRT zwischen und informiert Winlogon über die erfolgreiche Authentifizierung. Winlogon erstellt eine Anmeldesitzung, lädt das Profil des Benutzers und startet explorer.exe. |
Microsoft Entra die Authentifizierung in Active Directory mithilfe einer Kerberos-Cloud-Vertrauensstellung einbinden
| Phase | Beschreibung |
|---|---|
| A | Die Authentifizierung bei Active Directory von einem Microsoft Entra verbundenen Gerät beginnt damit, dass der Benutzer zuerst versucht, eine Ressource zu verwenden, die eine Kerberos-Authentifizierung erfordert. Der Kerberos-Sicherheitsunterstützungsanbieter, der in lsass gehostet wird, verwendet Metadaten aus dem Windows Hello for Business Schlüssel, um einen Hinweis auf die Domäne des Benutzers zu erhalten. Mithilfe des Hinweises verwendet der Anbieter den DClocator-Dienst, um einen Domänencontroller zu suchen. |
| B | Nach dem Suchen eines Domänencontrollers sendet der Kerberos-Anbieter ein partielles TGT, das er von Microsoft Entra ID einer vorherigen Microsoft Entra Authentifizierung an den Domänencontroller empfangen hat. Das partielle TGT enthält nur die Benutzer-SID und wird von Microsoft Entra Kerberos signiert. Der Domänencontroller überprüft, ob das partielle TGT gültig ist. Bei Erfolg gibt der KDC ein TGT an den Client zurück. |
Microsoft Entra die Authentifizierung mit Active Directory mithilfe eines Schlüssels einbinden
| Phase | Beschreibung |
|---|---|
| A | Die Authentifizierung bei Active Directory von einem Microsoft Entra verbundenen Gerät beginnt damit, dass der Benutzer zuerst versucht, eine Ressource zu verwenden, die eine Kerberos-Authentifizierung erfordert. Der Kerberos-Sicherheitsunterstützungsanbieter, der in lsass gehostet wird, verwendet Metadaten aus dem Windows Hello for Business Schlüssel, um einen Hinweis auf die Domäne des Benutzers zu erhalten. Mithilfe des Hinweises verwendet der Anbieter den DClocator-Dienst, um einen Domänencontroller zu suchen. Nachdem der Anbieter einen Domänencontroller gefunden hat, verwendet der Anbieter den privaten Schlüssel, um die Kerberos-Vorauthentifizierungsdaten zu signieren. |
| B | Der Kerberos-Anbieter sendet die signierten Vorauthentifizierungsdaten und seinen öffentlichen Schlüssel (in Form eines selbstsignierten Zertifikats) in Form eines KERB_AS_REQ an den Auf dem Domänencontroller ausgeführten KDC-Dienst (Key Distribution Center). Der Domänencontroller bestimmt, dass das Zertifikat ein selbstsigniertes Zertifikat ist. Es ruft den öffentlichen Schlüssel aus dem Zertifikat ab, das im KERB_AS_REQ enthalten ist, und sucht in Active Directory nach dem öffentlichen Schlüssel. Es überprüft, ob der UPN für die Authentifizierungsanforderung mit dem in Active Directory registrierten UPN übereinstimmt, und die signierten Vorauthentifizierungsdaten werden mithilfe des öffentlichen Schlüssels aus Active Directory überprüft. Bei Erfolg gibt der KDC ein TGT an den Client mit seinem Zertifikat in einem KERB_AS_REP zurück. |
| C | Der Kerberos-Anbieter stellt sicher, dass er der Antwort vom Domänencontroller vertrauen kann. Zunächst wird sichergestellt, dass das KDC-Zertifikat mit einem Stammzertifikat verkettet wird, dem das Gerät vertraut. Als Nächstes wird sichergestellt, dass das Zertifikat innerhalb seines Gültigkeitszeitraums liegt und nicht widerrufen wurde. Der Kerberos-Anbieter überprüft dann, ob für das Zertifikat die KDC-Authentifizierung vorhanden ist, und ob der alternative Antragstellername, der im Zertifikat des KDC aufgeführt ist, dem Domänennamen entspricht, bei dem der Benutzer sich authentifiziert. Nach dem Übergeben dieses Kriteriums gibt Kerberos das TGT an lsass zurück, wo es zwischengespeichert und für nachfolgende Serviceticketanforderungen verwendet wird. |
Hinweis
Möglicherweise verfügen Sie über eine lokale Domäne, die mit Microsoft Entra ID verbunden ist. Nachdem Sie erfolgreich Windows Hello for Business PIN/Bio auf dem Microsoft Entra verbundenen Gerät bereitgestellt haben, wird jede zukünftige Anmeldung bei Windows Hello for Business (PIN/Bio)-Anmeldung direkt bei Microsoft Entra ID , um PRT zu erhalten und die Authentifizierung bei Ihrem Domänencontroller auszulösen (sofern LOS to DC verfügbar ist), um Kerberos zu erhalten. Ad FS wird nicht mehr für die Authentifizierung für Windows Hello for Business Anmeldungen verwendet.
Microsoft Entra die Authentifizierung mit Active Directory mithilfe eines Zertifikats einbinden
| Phase | Beschreibung |
|---|---|
| A | Die Authentifizierung bei Active Directory von einem Microsoft Entra verbundenen Gerät beginnt damit, dass der Benutzer zuerst versucht, eine Ressource zu verwenden, die eine Kerberos-Authentifizierung erfordert. Der Kerberos-Sicherheitsunterstützungsanbieter, der in lsass gehostet wird, verwendet Informationen aus dem Zertifikat, um einen Hinweis auf die Domäne des Benutzers zu erhalten. Kerberos kann den Distinguished Name des Benutzers verwenden, der sich im Antragsteller des Zertifikats befindet, oder es kann den Benutzerprinzipalnamen des Benutzers verwenden, der sich im alternativen Antragstellernamen des Zertifikats befindet. Mithilfe des Hinweises verwendet der Anbieter den DClocator-Dienst, um einen Domänencontroller zu suchen. Nachdem der Anbieter einen aktiven Domänencontroller gefunden hat, verwendet der Anbieter den privaten Schlüssel zum Signieren der Kerberos-Vorauthentifizierungsdaten. |
| B | Der Kerberos-Anbieter sendet die signierten Vorauthentifizierungsdaten und das Zertifikat des Benutzers, das den öffentlichen Schlüssel enthält, an den Schlüsselverteilungscenterdienst (Key Distribution Center, KDC), der auf dem Domänencontroller in Form eines KERB_AS_REQ ausgeführt wird. Der Domänencontroller bestimmt, dass das Zertifikat kein selbstsigniertes Zertifikat ist. Der Domänencontroller stellt sicher, dass das Zertifikat mit dem vertrauenswürdigen Stammzertifikat verkettet ist, innerhalb seines Gültigkeitszeitraums liegt, für die Authentifizierung verwendet werden kann und nicht widerrufen wurde. Es ruft den öffentlichen Schlüssel und den UPN aus dem Zertifikat ab, das im KERB_AS_REQ enthalten ist, und sucht in Active Directory nach dem UPN. Es überprüft die signierten Vorauthentifizierungsdaten mithilfe des öffentlichen Schlüssels aus dem Zertifikat. Bei Erfolg gibt der KDC ein TGT an den Client mit seinem Zertifikat in einem KERB_AS_REP zurück. |
| C | Der Kerberos-Anbieter stellt sicher, dass er der Antwort vom Domänencontroller vertrauen kann. Zunächst wird sichergestellt, dass das KDC-Zertifikat mit einem Stammzertifikat verkettet wird, dem das Gerät vertraut. Als Nächstes wird sichergestellt, dass das Zertifikat innerhalb seines Gültigkeitszeitraums liegt und nicht widerrufen wurde. Der Kerberos-Anbieter überprüft dann, ob für das Zertifikat die KDC-Authentifizierung vorhanden ist, und ob der alternative Antragstellername, der im Zertifikat des KDC aufgeführt ist, dem Domänennamen entspricht, bei dem der Benutzer sich authentifiziert. Nach dem Übergeben dieses Kriteriums gibt Kerberos das TGT an lsass zurück, wo es zwischengespeichert und für nachfolgende Serviceticketanforderungen verwendet wird. |
Hinweis
Möglicherweise verfügen Sie über eine lokale Domäne, die mit Microsoft Entra ID verbunden ist. Nachdem Sie Windows Hello for Business PIN/Bio erfolgreich bereitgestellt haben, werden alle zukünftigen Anmeldungen bei Windows Hello for Business (PIN/Bio) direkt bei Microsoft Entra ID , um PRT zu erhalten und sich bei Ihrem Domänencontroller zu authentifizieren (wenn LOS zu DC verfügbar ist), um Kerberos wie zuvor erwähnt zu erhalten. Der AD FS-Verbund wird nur verwendet, wenn PRT-Enterprise-Aufrufe vom Client gesendet werden. Sie müssen das Zurückschreiben von Geräten aktiviert haben, um "Enterprise PRT" aus Ihrem Verbund zu erhalten.
Microsoft Entra der Hybrideinbindungsauthentifizierung mithilfe der Kerberos-Vertrauensstellung in der Cloud
| Phase | Beschreibung |
|---|---|
| A | Die Authentifizierung beginnt, wenn der Benutzer den Sperrbildschirm schließt, wodurch Winlogon ausgelöst wird, um den Windows Hello for Business Anmeldeinformationsanbieter anzuzeigen. Der Benutzer stellt seine Windows Hello Geste (PIN oder Biometrie) bereit. Der Anmeldeinformationsanbieter packt diese Anmeldeinformationen und gibt sie an Winlogon zurück. Winlogon übergibt die gesammelten Anmeldeinformationen an lsass. Lsass-Abfragen Windows Hello for Business Richtlinie, um zu überprüfen, ob die Kerberos-Vertrauensstellung in der Cloud aktiviert ist. Wenn die Kerberos-Cloudvertrauensstellung aktiviert ist, übergibt Lsass die gesammelten Anmeldeinformationen an den Cloudauthentifizierungs-Sicherheitssupportanbieter oder Cloud-AP. Cloud-AP fordert eine Nonce von Microsoft Entra ID an. Microsoft Entra ID gibt eine Nonce zurück. |
| B | Cloud AP signiert die Nonce mithilfe des privaten Schlüssels des Benutzers und gibt die signierte Nonce an Microsoft Entra ID zurück. |
| C | Microsoft Entra ID überprüft die signierte Nonce mithilfe des sicher registrierten öffentlichen Schlüssels des Benutzers anhand der Noncesignatur. Nach dem Überprüfen der Signatur überprüft Microsoft Entra ID dann die zurückgegebene signierte Nonce. Nach dem Überprüfen der Nonce erstellt Microsoft Entra ID ein PRT mit Sitzungsschlüssel, der mit dem Transportschlüssel des Geräts verschlüsselt ist, und erstellt ein Partielles TGT aus Microsoft Entra Kerberos und gibt sie an Cloud-AP zurück. |
| D | Cloud-AP empfängt das verschlüsselte PRT mit Sitzungsschlüssel. Mithilfe des privaten Transportschlüssels des Geräts entschlüsselt Cloud AP den Sitzungsschlüssel und schützt den Sitzungsschlüssel mithilfe des TPM des Geräts (sofern verfügbar). Cloud-AP gibt eine erfolgreiche Authentifizierungsantwort an lsass zurück. Lsass speichert das PRT und das partielle TGT zwischen. |
| E | Der Kerberos-Sicherheitsunterstützungsanbieter, der in lsass gehostet wird, verwendet Metadaten aus dem Windows Hello for Business Schlüssel, um einen Hinweis auf die Domäne des Benutzers zu erhalten. Mithilfe des Hinweises verwendet der Anbieter den DClocator-Dienst, um einen Domänencontroller zu suchen. Nachdem ein aktiver Domänencontroller gesucht wurde, sendet der Kerberos-Anbieter das partielle TGT, das er von Microsoft Entra ID empfangen hat, an den Domänencontroller. Das partielle TGT enthält nur die Benutzer-SID und wird von Microsoft Entra Kerberos signiert. Der Domänencontroller überprüft, ob das partielle TGT gültig ist. Bei Erfolg gibt der KDC ein TGT an den Client zurück. Kerberos gibt den TGT an lsass zurück, wo er zwischengespeichert und für nachfolgende Dienstticketanforderungen verwendet wird. Lsass informiert Winlogon über die erfolgreiche Authentifizierung. Winlogon erstellt eine Anmeldesitzung, lädt das Profil des Benutzers und startet explorer.exe. |
Microsoft Entra der Hybridjoin-Authentifizierung mithilfe eines Schlüssels
| Phase | Beschreibung |
|---|---|
| A | Die Authentifizierung beginnt, wenn der Benutzer den Sperrbildschirm schließt, wodurch Winlogon ausgelöst wird, um den Windows Hello for Business Anmeldeinformationsanbieter anzuzeigen. Der Benutzer stellt seine Windows Hello Geste (PIN oder Biometrie) bereit. Der Anmeldeinformationsanbieter packt diese Anmeldeinformationen und gibt sie an Winlogon zurück. Winlogon übergibt die gesammelten Anmeldeinformationen an lsass. Lsass übergibt die gesammelten Anmeldeinformationen an den Kerberos-Sicherheitssupportanbieter. Der Kerberos-Anbieter ruft Domänenhinweise von der in die Domäne eingebundenen Arbeitsstation ab, um einen Domänencontroller für den Benutzer zu suchen. |
| B | Der Kerberos-Anbieter sendet die signierten Vorauthentifizierungsdaten und den öffentlichen Schlüssel des Benutzers (in Form eines selbstsignierten Zertifikats) in Form eines KERB_AS_REQ an den Schlüsselverteilungscenterdienst (Key Distribution Center, KDC), der auf dem Domänencontroller ausgeführt wird. Der Domänencontroller bestimmt, dass das Zertifikat ein selbstsigniertes Zertifikat ist. Es ruft den öffentlichen Schlüssel aus dem Zertifikat ab, das im KERB_AS_REQ enthalten ist, und sucht in Active Directory nach dem öffentlichen Schlüssel. Es überprüft, ob der UPN für die Authentifizierungsanforderung mit dem in Active Directory registrierten UPN übereinstimmt, und die signierten Vorauthentifizierungsdaten werden mithilfe des öffentlichen Schlüssels aus Active Directory überprüft. Bei Erfolg gibt der KDC ein TGT an den Client mit seinem Zertifikat in einem KERB_AS_REP zurück. |
| C | Der Kerberos-Anbieter stellt sicher, dass er der Antwort vom Domänencontroller vertrauen kann. Zunächst wird sichergestellt, dass das KDC-Zertifikat mit einem Stammzertifikat verkettet wird, dem das Gerät vertraut. Als Nächstes wird sichergestellt, dass das Zertifikat innerhalb seines Gültigkeitszeitraums liegt und nicht widerrufen wurde. Der Kerberos-Anbieter überprüft dann, ob für das Zertifikat die KDC-Authentifizierung vorhanden ist, und ob der alternative Antragstellername, der im Zertifikat des KDC aufgeführt ist, dem Domänennamen entspricht, bei dem der Benutzer sich authentifiziert. |
| D | Nach dem Übergeben dieses Kriteriums gibt Kerberos das TGT an lsass zurück, wo es zwischengespeichert und für nachfolgende Serviceticketanforderungen verwendet wird. |
| E | Lsass informiert Winlogon über die erfolgreiche Authentifizierung. Winlogon erstellt eine Anmeldesitzung, lädt das Profil des Benutzers und startet explorer.exe. |
| F | Während Windows den Desktop des Benutzers lädt, übergibt lsass die gesammelten Anmeldeinformationen an den Cloud Authentication-Sicherheitssupportanbieter, der als Cloud-AP-Anbieter bezeichnet wird. Der Cloud-AP-Anbieter fordert eine Nonce von Microsoft Entra ID an. Microsoft Entra ID gibt eine Nonce zurück. |
| G | Der Cloud-AP-Anbieter signiert die Nonce mithilfe des privaten Schlüssels des Benutzers und gibt die signierte Nonce an die Microsoft Entra ID zurück. Microsoft Entra ID überprüft die signierte Nonce mithilfe des sicher registrierten öffentlichen Schlüssels des Benutzers anhand der Noncesignatur. Nach dem Überprüfen der Signatur überprüft Microsoft Entra ID dann die zurückgegebene signierte Nonce. Nach dem Überprüfen der Nonce erstellt Microsoft Entra ID einen PRT mit Sitzungsschlüssel, der mit dem Transportschlüssel des Geräts verschlüsselt ist, und gibt ihn an den Cloud-AP-Anbieter zurück. Der Cloud-AP-Anbieter empfängt das verschlüsselte PRT mit Sitzungsschlüssel. Mithilfe des privaten Transportschlüssels des Geräts entschlüsselt der Cloud-AP-Anbieter den Sitzungsschlüssel und schützt den Sitzungsschlüssel mithilfe des TPM des Geräts. Der Cloud-AP-Anbieter gibt eine erfolgreiche Authentifizierungsantwort an lsass zurück. Lsass speichert das PRT zwischen. |
Wichtig
Im obigen Bereitstellungsmodell kann sich ein neu bereitgestellter Benutzer erst dann mit Windows Hello for Business anmelden, wenn (a) Microsoft Entra Connect erfolgreich den öffentlichen Schlüssel mit dem lokales Active Directory synchronisiert und (b) das Gerät zum ersten Mal über Sichtverbindung zum Domänencontroller verfügt.
Microsoft Entra hybrider Join-Authentifizierung mithilfe eines Zertifikats
| Phase | Beschreibung |
|---|---|
| A | Die Authentifizierung beginnt, wenn der Benutzer den Sperrbildschirm schließt, wodurch Winlogon ausgelöst wird, um den Windows Hello for Business Anmeldeinformationsanbieter anzuzeigen. Der Benutzer stellt seine Windows Hello Geste (PIN oder Biometrie) bereit. Der Anmeldeinformationsanbieter packt diese Anmeldeinformationen und gibt sie an Winlogon zurück. Winlogon übergibt die gesammelten Anmeldeinformationen an lsass. Lsass übergibt die gesammelten Anmeldeinformationen an den Kerberos-Sicherheitssupportanbieter. Der Kerberos-Anbieter ruft Domänenhinweise von der in die Domäne eingebundenen Arbeitsstation ab, um einen Domänencontroller für den Benutzer zu suchen. |
| B | Der Kerberos-Anbieter sendet die signierten Vorauthentifizierungsdaten und das Zertifikat des Benutzers, das den öffentlichen Schlüssel enthält, an den Schlüsselverteilungscenterdienst (Key Distribution Center, KDC), der auf dem Domänencontroller in Form eines KERB_AS_REQ ausgeführt wird. Der Domänencontroller bestimmt, dass das Zertifikat kein selbstsigniertes Zertifikat ist. Der Domänencontroller stellt sicher, dass das Zertifikat mit dem vertrauenswürdigen Stammzertifikat verkettet ist, innerhalb seines Gültigkeitszeitraums liegt, für die Authentifizierung verwendet werden kann und nicht widerrufen wurde. Es ruft den öffentlichen Schlüssel und den UPN aus dem Zertifikat ab, das im KERB_AS_REQ enthalten ist, und sucht in Active Directory nach dem UPN. Es überprüft die signierten Vorauthentifizierungsdaten mithilfe des öffentlichen Schlüssels aus dem Zertifikat. Bei Erfolg gibt der KDC ein TGT an den Client mit seinem Zertifikat in einem KERB_AS_REP zurück. |
| C | Der Kerberos-Anbieter stellt sicher, dass er der Antwort vom Domänencontroller vertrauen kann. Zunächst wird sichergestellt, dass das KDC-Zertifikat mit einem Stammzertifikat verkettet wird, dem das Gerät vertraut. Als Nächstes wird sichergestellt, dass das Zertifikat innerhalb seines Gültigkeitszeitraums liegt und nicht widerrufen wurde. Der Kerberos-Anbieter überprüft dann, ob für das Zertifikat die KDC-Authentifizierung vorhanden ist, und ob der alternative Antragstellername, der im Zertifikat des KDC aufgeführt ist, dem Domänennamen entspricht, bei dem der Benutzer sich authentifiziert. |
| D | Nach dem Übergeben dieses Kriteriums gibt Kerberos das TGT an lsass zurück, wo es zwischengespeichert und für nachfolgende Serviceticketanforderungen verwendet wird. |
| E | Lsass informiert Winlogon über die erfolgreiche Authentifizierung. Winlogon erstellt eine Anmeldesitzung, lädt das Profil des Benutzers und startet explorer.exe. |
| F | Während Windows den Desktop des Benutzers lädt, übergibt lsass die gesammelten Anmeldeinformationen an den Cloud Authentication-Sicherheitssupportanbieter, der als Cloud-AP-Anbieter bezeichnet wird. Der Cloud-AP-Anbieter fordert eine Nonce von Microsoft Entra ID an. Microsoft Entra ID gibt eine Nonce zurück. |
| G | Der Cloud-AP-Anbieter signiert die Nonce mithilfe des privaten Schlüssels des Benutzers und gibt die signierte Nonce an die Microsoft Entra ID zurück. Microsoft Entra ID überprüft die signierte Nonce mithilfe des sicher registrierten öffentlichen Schlüssels des Benutzers anhand der Noncesignatur. Nach dem Überprüfen der Signatur überprüft Microsoft Entra ID dann die zurückgegebene signierte Nonce. Nach dem Überprüfen der Nonce erstellt Microsoft Entra ID einen PRT mit Sitzungsschlüssel, der mit dem Transportschlüssel des Geräts verschlüsselt ist, und gibt ihn an den Cloud-AP-Anbieter zurück. Der Cloud-AP-Anbieter empfängt das verschlüsselte PRT mit Sitzungsschlüssel. Mithilfe des privaten Transportschlüssels des Geräts entschlüsselt der Cloud-AP-Anbieter den Sitzungsschlüssel und schützt den Sitzungsschlüssel mithilfe des TPM des Geräts. Der Cloud-AP-Anbieter gibt eine erfolgreiche Authentifizierungsantwort an lsass zurück. Lsass speichert das PRT zwischen. |
Wichtig
Im obigen Bereitstellungsmodell kann sich ein neu bereitgestellter Benutzer nicht mit Windows Hello for Business anmelden, es sei denn, das Gerät verfügt über Sichtverbindung zum Domänencontroller.