Windows Hello for Business-Bereitstellung
Windows Hello for Business Bereitstellung ermöglicht es einem Benutzer, neue, starke zweistufige Anmeldeinformationen zu registrieren, die er für die kennwortlose Authentifizierung verwenden kann. Die Bereitstellungserfahrung variiert je nach:
- Wie das Gerät in Azure Active Directory eingebunden wird
- Der Windows Hello for Business-Bereitstellungstyp
- Wenn die Umgebung verwaltet oder verbundiert ist
Liste der Bereitstellungsflows:
- In Azure AD eingebundene Bereitstellung in einer verwalteten Umgebung
- In Azure AD eingebundene Bereitstellung in einer Verbundumgebung
- In Azure AD eingebundene Hybridbereitstellung in einer Cloudbereitstellung mit Kerberos-Vertrauensstellung in einer verwalteten Umgebung
- In Azure AD eingebundene Hybridbereitstellung in einer Schlüsselvertrauensbereitstellung in einer verwalteten Umgebung
- In Azure AD eingebundene Hybridbereitstellung in einer synchronen Zertifikatvertrauensbereitstellung in einer Verbundumgebung
- In eine Domäne eingebundene Bereitstellung in einer lokalen Schlüsselvertrauensstellungsbereitstellung
- In eine Domäne eingebundene Bereitstellung in einer lokalen Zertifikatvertrauensstellungsbereitstellung
Hinweis
Die Flows in diesem Abschnitt sind nicht für jedes mögliche Szenario erschöpfend. Beispielsweise ist verbundbasierte Schlüsselvertrauensstellung auch eine unterstützte Konfiguration.
In Azure AD eingebundene Bereitstellung in einer verwalteten Umgebung
| Phase | Beschreibung |
|---|---|
| A | Die bereitstellungsanwendung, die im Cloud Experience Host (CXH) gehostet wird, beginnt mit der Bereitstellung, indem sie ein Zugriffstoken für den Azure Device Registration Service (ADRS) anfordert. Die Anwendung stellt die Anforderung mithilfe des Azure Active Directory-Webkonto-Manager-Plug-Ins. Benutzer müssen zwei Authentifizierungsfaktoren angeben. In dieser Phase hat der Benutzer bereits einen Authentifizierungsfaktor angegeben, in der Regel Benutzername und Kennwort. Der Azure MFA-Dienst bietet den zweiten Authentifizierungsfaktor. Wenn der Benutzer azure MFA innerhalb der letzten 10 Minuten ausgeführt hat, z. B. bei der Registrierung des Geräts über die Out-of-Box-Experience (OOBE), wird er nicht zur MFA aufgefordert, da die aktuelle MFA gültig bleibt. Azure Active Directory überprüft die Zugriffstokenanforderung und den damit verbundenen MFA-Anspruch, erstellt ein ADRS-Zugriffstoken und gibt es an die Anwendung zurück. |
| B | Nach dem Empfang eines ADRS-Zugriffstokens erkennt die Anwendung, ob das Gerät über einen Windows Hello biometrischen kompatiblen Sensor verfügt. Wenn die Anwendung einen biometrischen Sensor erkennt, gibt sie dem Benutzer die Möglichkeit, biometrische Daten zu registrieren. Nach Abschluss oder Überspringen der biometrischen Registrierung erfordert die Anwendung, dass der Benutzer eine PIN und die Standard-(und Fallback-Geste) erstellt, wenn er mit biometrischen Daten verwendet wird. Der Benutzer stellt seine PIN bereit und bestätigt sie. Als Nächstes fordert die Anwendung ein Windows Hello for Business Schlüsselpaar aus dem Schlüsselpool vor der Generierung an, der Nachweisdaten enthält. Dies ist der Benutzerschlüssel (ukpub/ukpriv). |
| C | Die Anwendung sendet das ADRS-Token, ukpub, Nachweisdaten und Geräteinformationen zur Registrierung des Benutzerschlüssels an ADRS. Azure DRS überprüft, ob der MFA-Anspruch aktuell bleibt. Bei erfolgreicher Überprüfung sucht Azure DRS das Objekt des Benutzers in Azure Active Directory und schreibt die Schlüsselinformationen in ein Attribut mit mehreren Werten. Die Schlüsselinformationen enthalten einen Verweis auf das Gerät, von dem sie erstellt wurden. Azure Active Directory gibt eine Schlüssel-ID an die Anwendung zurück, die das Ende der Benutzerbereitstellung signalisiert und die Anwendung beendet. |
In Azure AD eingebundene Bereitstellung in einer Verbundumgebung
| Phase | Beschreibung |
|---|---|
| A | Die bereitstellungsanwendung, die im Cloud Experience Host (CXH) gehostet wird, beginnt mit der Bereitstellung, indem sie ein Zugriffstoken für den Azure Device Registration Service (ADRS) anfordert. Die Anwendung stellt die Anforderung mithilfe des Azure Active Directory-Webkonto-Manager-Plug-Ins. In einer Verbundumgebung sendet das Plug-In die Tokenanforderung an den lokalen STS, z. B. Active Directory-Verbunddienste (AD FS). Der lokale STS authentifiziert den Benutzer und bestimmt, ob der Benutzer einen anderen Authentifizierungsfaktor ausführen soll. Benutzer müssen zwei Authentifizierungsfaktoren angeben. In dieser Phase hat der Benutzer bereits einen Authentifizierungsfaktor angegeben, in der Regel Benutzername und Kennwort. Der Azure MFA-Dienst bietet den zweiten Authentifizierungsfaktor. Wenn der Benutzer azure MFA innerhalb der letzten 10 Minuten ausgeführt hat, z. B. bei der Registrierung des Geräts über die Out-of-Box-Experience (OOBE), wird er nicht zur MFA aufgefordert, da die aktuelle MFA gültig bleibt. Der lokale STS-Server gibt bei erfolgreicher MFA ein Unternehmenstoken aus. Die Anwendung sendet das Token an Azure Active Directory. Azure Active Directory überprüft die Zugriffstokenanforderung und den damit verbundenen MFA-Anspruch, erstellt ein ADRS-Zugriffstoken und gibt es an die Anwendung zurück. |
| B | Nach dem Empfang eines ADRS-Zugriffstokens erkennt die Anwendung, ob das Gerät über einen Windows Hello biometrischen kompatiblen Sensor verfügt. Wenn die Anwendung einen biometrischen Sensor erkennt, gibt sie dem Benutzer die Möglichkeit, biometrische Daten zu registrieren. Nach Abschluss oder Überspringen der biometrischen Registrierung erfordert die Anwendung, dass der Benutzer eine PIN und die Standard-(und Fallback-Geste) erstellt, wenn er mit biometrischen Daten verwendet wird. Der Benutzer stellt seine PIN bereit und bestätigt sie. Als Nächstes fordert die Anwendung ein Windows Hello for Business Schlüsselpaar aus dem Schlüsselpool vor der Generierung an, der Nachweisdaten enthält. Dies ist der Benutzerschlüssel (ukpub/ukpriv). |
| C | Die Anwendung sendet das ADRS-Token, ukpub, Nachweisdaten und Geräteinformationen zur Registrierung des Benutzerschlüssels an ADRS. Azure DRS überprüft, ob der MFA-Anspruch aktuell bleibt. Bei erfolgreicher Überprüfung sucht Azure DRS das Objekt des Benutzers in Azure Active Directory und schreibt die Schlüsselinformationen in ein Attribut mit mehreren Werten. Die Schlüsselinformationen enthalten einen Verweis auf das Gerät, von dem sie erstellt wurden. Azure Active Directory gibt die Schlüssel-ID an die Anwendung zurück, die das Ende der Benutzerbereitstellung signalisiert und die Anwendung beendet. |
In Azure AD eingebundene Hybridbereitstellung in einer Cloudbereitstellung mit Kerberos-Vertrauensstellung in einer verwalteten Umgebung
| Phase | Beschreibung |
|---|---|
| A | Die bereitstellungsanwendung, die im Cloud Experience Host (CXH) gehostet wird, beginnt mit der Bereitstellung, indem sie ein Zugriffstoken für den Azure Device Registration Service (ADRS) anfordert. Die Anwendung stellt die Anforderung mithilfe des Azure Active Directory-Webkonto-Manager-Plug-Ins. Benutzer müssen zwei Authentifizierungsfaktoren angeben. In dieser Phase hat der Benutzer bereits einen Authentifizierungsfaktor angegeben, in der Regel Benutzername und Kennwort. Der Azure MFA-Dienst bietet den zweiten Authentifizierungsfaktor. Wenn der Benutzer azure MFA innerhalb der letzten 10 Minuten ausgeführt hat, z. B. bei der Registrierung des Geräts über die Out-of-Box-Experience (OOBE), wird er nicht zur MFA aufgefordert, da die aktuelle MFA gültig bleibt. Azure Active Directory überprüft die Zugriffstokenanforderung und den damit verbundenen MFA-Anspruch, erstellt ein ADRS-Zugriffstoken und gibt es an die Anwendung zurück. |
| B | Nach dem Empfang eines ADRS-Zugriffstokens erkennt die Anwendung, ob das Gerät über einen Windows Hello biometrischen kompatiblen Sensor verfügt. Wenn die Anwendung einen biometrischen Sensor erkennt, gibt sie dem Benutzer die Möglichkeit, biometrische Daten zu registrieren. Nach Abschluss oder Überspringen der biometrischen Registrierung erfordert die Anwendung, dass der Benutzer eine PIN und die Standard-(und Fallback-Geste) erstellt, wenn er mit biometrischen Daten verwendet wird. Der Benutzer stellt seine PIN bereit und bestätigt sie. Als Nächstes fordert die Anwendung ein Windows Hello for Business Schlüsselpaar aus dem Schlüsselpool vor der Generierung an, der Nachweisdaten enthält. Dies ist der Benutzerschlüssel (ukpub/ukpriv). |
| C | Die Anwendung sendet das ADRS-Token, ukpub, Nachweisdaten und Geräteinformationen zur Registrierung des Benutzerschlüssels an ADRS. Azure DRS überprüft, ob der MFA-Anspruch aktuell bleibt. Bei erfolgreicher Überprüfung sucht Azure DRS das Objekt des Benutzers in Azure Active Directory und schreibt die Schlüsselinformationen in ein Attribut mit mehreren Werten. Die Schlüsselinformationen enthalten einen Verweis auf das Gerät, von dem sie erstellt wurden. Azure Active Directory gibt eine Schlüssel-ID an die Anwendung zurück, die das Ende der Benutzerbereitstellung signalisiert und die Anwendung beendet. |
Hinweis
Windows Hello for Business Cloud-Kerberos-Vertrauensstellung erfordert nicht, dass die Schlüssel der Benutzer von Azure AD mit AD synchronisiert werden. Benutzer können sich nach der Bereitstellung ihrer Anmeldeinformationen sofort bei Azure Active Directory und AD authentifizieren.
In Azure AD eingebundene Hybridbereitstellung in einer Schlüsselvertrauensbereitstellung in einer verwalteten Umgebung
| Phase | Beschreibung |
|---|---|
| A | Die bereitstellungsanwendung, die im Cloud Experience Host (CXH) gehostet wird, beginnt mit der Bereitstellung, indem sie ein Zugriffstoken für den Azure Device Registration Service (ADRS) anfordert. Die Anwendung stellt die Anforderung mithilfe des Azure Active Directory-Webkonto-Manager-Plug-Ins. Benutzer müssen zwei Authentifizierungsfaktoren angeben. In dieser Phase hat der Benutzer bereits einen Authentifizierungsfaktor angegeben, in der Regel Benutzername und Kennwort. Der Azure MFA-Dienst bietet den zweiten Authentifizierungsfaktor. Wenn der Benutzer azure MFA innerhalb der letzten 10 Minuten ausgeführt hat, z. B. bei der Registrierung des Geräts über die Out-of-Box-Experience (OOBE), wird er nicht zur MFA aufgefordert, da die aktuelle MFA gültig bleibt. Azure Active Directory überprüft die Zugriffstokenanforderung und den damit verbundenen MFA-Anspruch, erstellt ein ADRS-Zugriffstoken und gibt es an die Anwendung zurück. |
| B | Nach dem Empfang eines ADRS-Zugriffstokens erkennt die Anwendung, ob das Gerät über einen Windows Hello biometrischen kompatiblen Sensor verfügt. Wenn die Anwendung einen biometrischen Sensor erkennt, gibt sie dem Benutzer die Möglichkeit, biometrische Daten zu registrieren. Nach Abschluss oder Überspringen der biometrischen Registrierung erfordert die Anwendung, dass der Benutzer eine PIN und die Standard-(und Fallback-Geste) erstellt, wenn er mit biometrischen Daten verwendet wird. Der Benutzer stellt seine PIN bereit und bestätigt sie. Als Nächstes fordert die Anwendung ein Windows Hello for Business Schlüsselpaar aus dem Schlüsselpool vor der Generierung an, der Nachweisdaten enthält. Dies ist der Benutzerschlüssel (ukpub/ukpriv). |
| C | Die Anwendung sendet das ADRS-Token, ukpub, Nachweisdaten und Geräteinformationen zur Registrierung des Benutzerschlüssels an ADRS. Azure DRS überprüft, ob der MFA-Anspruch aktuell bleibt. Bei erfolgreicher Überprüfung sucht Azure DRS das Objekt des Benutzers in Azure Active Directory und schreibt die Schlüsselinformationen in ein Attribut mit mehreren Werten. Die Schlüsselinformationen enthalten einen Verweis auf das Gerät, von dem sie erstellt wurden. Azure Active Directory gibt eine Schlüssel-ID an die Anwendung zurück, die das Ende der Benutzerbereitstellung signalisiert und die Anwendung beendet. |
| D | Azure AD Connect fordert Updates für den nächsten Synchronisierungszyklus an. Azure Active Directory sendet den öffentlichen Schlüssel des Benutzers, der über die Bereitstellung sicher registriert wurde. Azure Active Directory Connect empfängt den öffentlichen Schlüssel und schreibt ihn in das Attribut msDS-KeyCredentialLink des Benutzers in Active Directory. |
Wichtig
Der neu bereitgestellte Benutzer kann sich erst dann mit Windows Hello for Business anmelden, wenn Azure AD Connect den öffentlichen Schlüssel erfolgreich mit dem lokales Active Directory synchronisiert hat.
In Azure AD eingebundene Hybridbereitstellung in einer synchronen Zertifikatvertrauensbereitstellung in einer Verbundumgebung
| Phase | Beschreibung |
|---|---|
| A | Die bereitstellungsanwendung, die im Cloud Experience Host (CXH) gehostet wird, beginnt mit der Bereitstellung, indem sie ein Zugriffstoken für den Azure Device Registration Service (ADRS) anfordert. Die Anwendung stellt die Anforderung mithilfe des Azure Active Directory-Webkonto-Manager-Plug-Ins. In einer Verbundumgebung sendet das Plug-In die Tokenanforderung an den lokalen STS, z. B. Active Directory-Verbunddienste (AD FS). Der lokale STS authentifiziert den Benutzer und bestimmt, ob der Benutzer einen anderen Authentifizierungsfaktor ausführen soll. Benutzer müssen zwei Authentifizierungsfaktoren angeben. In dieser Phase hat der Benutzer bereits einen Authentifizierungsfaktor angegeben, in der Regel Benutzername und Kennwort. Der Azure MFA-Dienst (oder ein MFA-Dienst eines Drittanbieters) stellt den zweiten Authentifizierungsfaktor bereit. Der lokale STS-Server gibt bei erfolgreicher MFA ein Unternehmenstoken aus. Die Anwendung sendet das Token an Azure Active Directory. Azure Active Directory überprüft die Zugriffstokenanforderung und den damit verbundenen MFA-Anspruch, erstellt ein ADRS-Zugriffstoken und gibt es an die Anwendung zurück. |
| B | Nach dem Empfang eines ADRS-Zugriffstokens erkennt die Anwendung, ob das Gerät über einen Windows Hello biometrischen kompatiblen Sensor verfügt. Wenn die Anwendung einen biometrischen Sensor erkennt, gibt sie dem Benutzer die Möglichkeit, biometrische Daten zu registrieren. Nach Abschluss oder Überspringen der biometrischen Registrierung erfordert die Anwendung, dass der Benutzer eine PIN und die Standard-(und Fallback-Geste) erstellt, wenn er mit biometrischen Daten verwendet wird. Der Benutzer stellt seine PIN bereit und bestätigt sie. Als Nächstes fordert die Anwendung ein Windows Hello for Business Schlüsselpaar aus dem Schlüsselpool vor der Generierung an, der Nachweisdaten enthält. Dies ist der Benutzerschlüssel (ukpub/ukpriv). |
| C | Die Anwendung sendet das ADRS-Token, ukpub, Nachweisdaten und Geräteinformationen zur Registrierung des Benutzerschlüssels an ADRS. Azure DRS überprüft, ob der MFA-Anspruch aktuell bleibt. Bei erfolgreicher Überprüfung sucht Azure DRS das Objekt des Benutzers in Azure Active Directory und schreibt die Schlüsselinformationen in ein Attribut mit mehreren Werten. Die Schlüsselinformationen enthalten einen Verweis auf das Gerät, von dem sie erstellt wurden. Azure Active Directory gibt eine Schlüssel-ID und eine Schlüsselbestätigung an die Anwendung zurück, die die Registrierung des Benutzerschlüssels darstellt. |
| D | Der Zertifikatanforderungsteil der Bereitstellung beginnt, nachdem die Anwendung eine erfolgreiche Antwort von der Schlüsselregistrierung erhalten hat. Die Anwendung erstellt eine PKCS#10-Zertifikatanforderung. Der in der Zertifikatanforderung verwendete Schlüssel ist derselbe Schlüssel, der sicher bereitgestellt wurde. Die Anwendung sendet den Schlüsselbeleg und die Zertifikatanforderung, die den öffentlichen Schlüssel enthält, an die Zertifikatregistrierungsstelle, die in der Active Directory-Verbunddienste (AD FS)-Farm (AD FS) gehostet wird. Nach Erhalt der Zertifikatanforderung fragt die Zertifizierungsstelle Active Directory nach msDS-KeyCredentialsLink ab, um eine Liste der registrierten öffentlichen Schlüssel zu erhalten. |
| E | Die Registrierungsstelle überprüft, ob der öffentliche Schlüssel in der Zertifikatanforderung mit einem registrierten Schlüssel für den Benutzer übereinstimmt. Wenn der öffentliche Schlüssel im Zertifikat nicht in der Liste der registrierten öffentlichen Schlüssel gefunden wird, wird der Schlüsselbeleg überprüft, um zu bestätigen, dass der Schlüssel sicher bei Azure registriert wurde. Nach der Überprüfung des Schlüsselbelegs oder des öffentlichen Schlüssels signiert die Registrierungsstelle die Zertifikatanforderung mit ihrem Registrierungs-Agent-Zertifikat. |
| F | Die Registrierungsstelle sendet die Zertifikatanforderung an die ausstellende Zertifizierungsstelle des Unternehmens. Die Zertifizierungsstelle überprüft, ob die Zertifikatanforderung von einem gültigen Registrierungs-Agent signiert ist, stellt bei Erfolg ein Zertifikat aus und gibt es an die Registrierungsstelle zurück, die das Zertifikat dann an die Anwendung zurückgibt. |
| G | Die Anwendung empfängt das neu ausgestellte Zertifikat und installiert es im persönlichen Speicher des Benutzers. Dies signalisiert das Ende der Bereitstellung. |
Wichtig
Die synchrone Zertifikatregistrierung ist nicht von Azure AD Connect abhängig, um den öffentlichen Schlüssel des Benutzers zu synchronisieren, um das Windows Hello for Business Authentifizierungszertifikat ausstellen zu können. Benutzer können sich sofort nach Abschluss der Bereitstellung mit dem Zertifikat anmelden. Azure AD Connect synchronisiert weiterhin den öffentlichen Schlüssel mit Active Directory, wird aber in diesem Flow nicht angezeigt.
In eine Domäne eingebundene Bereitstellung in einer lokalen Key Trust-Bereitstellung
| Phase | Beschreibung |
|---|---|
| A | Die bereitstellungsanwendung, die im Cloud Experience Host (CXH) gehostet wird, beginnt mit der Bereitstellung, indem sie ein Zugriffstoken für den Enterprise Device Registration Service (EDRS) anfordert. Die Anwendung stellt die Anforderung mithilfe des Azure Active Directory-Webkonto-Manager-Plug-Ins. In einer lokalen Bereitstellung sendet das Plug-In die Tokenanforderung an den lokalen STS, z. B. an Active Directory-Verbunddienste (AD FS). Der lokale STS authentifiziert den Benutzer und bestimmt, ob der Benutzer einen anderen Authentifizierungsfaktor ausführen soll. Benutzer müssen zwei Authentifizierungsfaktoren angeben. In dieser Phase hat der Benutzer bereits einen Authentifizierungsfaktor angegeben, in der Regel Benutzername und Kennwort. Der Azure MFA-Server (oder ein MFA-Dienst eines Drittanbieters) stellt den zweiten Authentifizierungsfaktor bereit. Der lokale STS-Server stellt bei erfolgreicher MFA ein UNTERNEHMENS-DRS-Token aus. |
| B | Nach dem Empfang eines EDRS-Zugriffstokens erkennt die Anwendung, ob das Gerät über einen Windows Hello biometrischen kompatiblen Sensor verfügt. Wenn die Anwendung einen biometrischen Sensor erkennt, gibt sie dem Benutzer die Möglichkeit, biometrische Daten zu registrieren. Nach Abschluss oder Überspringen der biometrischen Registrierung erfordert die Anwendung, dass der Benutzer eine PIN und die Standard-(und Fallback-Geste) erstellt, wenn er mit biometrischen Daten verwendet wird. Der Benutzer stellt seine PIN bereit und bestätigt sie. Als Nächstes fordert die Anwendung ein Windows Hello for Business Schlüsselpaar aus dem Schlüsselpool vor der Generierung an, der Nachweisdaten enthält. Dies ist der Benutzerschlüssel (ukpub/ukpriv). |
| C | Die Anwendung sendet das EDRS-Token, ukpub, Nachweisdaten und Geräteinformationen zur Registrierung des Benutzerschlüssels an das Enterprise DRS. Enterprise DRS überprüft, ob der MFA-Anspruch aktuell bleibt. Bei erfolgreicher Überprüfung sucht das Enterprise-DRS das Objekt des Benutzers in Active Directory und schreibt die Schlüsselinformationen in ein Attribut mit mehreren Werten. Die Schlüsselinformationen enthalten einen Verweis auf das Gerät, von dem sie erstellt wurden. Das Enterprise DRS gibt eine Schlüssel-ID an die Anwendung zurück, die die Registrierung des End-of-User-Schlüssels darstellt. |
In eine Domäne eingebundene Bereitstellung in einer lokalen Bereitstellung mit Zertifikatvertrauensstellung
| Phase | Beschreibung |
|---|---|
| A | Die bereitstellungsanwendung, die im Cloud Experience Host (CXH) gehostet wird, beginnt mit der Bereitstellung, indem sie ein Zugriffstoken für den Enterprise Device Registration Service (EDRS) anfordert. Die Anwendung stellt die Anforderung mithilfe des Azure Active Directory-Webkonto-Manager-Plug-Ins. In einer lokalen Bereitstellung sendet das Plug-In die Tokenanforderung an den lokalen STS, z. B. an Active Directory-Verbunddienste (AD FS). Der lokale STS authentifiziert den Benutzer und bestimmt, ob der Benutzer einen anderen Authentifizierungsfaktor ausführen soll. Benutzer müssen zwei Authentifizierungsfaktoren angeben. In dieser Phase hat der Benutzer bereits einen Authentifizierungsfaktor angegeben, in der Regel Benutzername und Kennwort. Der Azure MFA-Server (oder ein MFA-Dienst eines Drittanbieters) stellt den zweiten Authentifizierungsfaktor bereit. Der lokale STS-Server stellt bei erfolgreicher MFA ein UNTERNEHMENS-DRS-Token aus. |
| B | Nach dem Empfang eines EDRS-Zugriffstokens erkennt die Anwendung, ob das Gerät über einen Windows Hello biometrischen kompatiblen Sensor verfügt. Wenn die Anwendung einen biometrischen Sensor erkennt, gibt sie dem Benutzer die Möglichkeit, biometrische Daten zu registrieren. Nach Abschluss oder Überspringen der biometrischen Registrierung erfordert die Anwendung, dass der Benutzer eine PIN und die Standard-(und Fallback-Geste) erstellt, wenn er mit biometrischen Daten verwendet wird. Der Benutzer stellt seine PIN bereit und bestätigt sie. Als Nächstes fordert die Anwendung ein Windows Hello for Business Schlüsselpaar aus dem Schlüsselpool vor der Generierung an, der Nachweisdaten enthält. Dies ist der Benutzerschlüssel (ukpub/ukpriv). |
| C | Die Anwendung sendet das EDRS-Token, ukpub, Nachweisdaten und Geräteinformationen zur Registrierung des Benutzerschlüssels an das Enterprise DRS. Enterprise DRS überprüft, ob der MFA-Anspruch aktuell bleibt. Bei erfolgreicher Überprüfung sucht das Enterprise-DRS das Objekt des Benutzers in Active Directory und schreibt die Schlüsselinformationen in ein Attribut mit mehreren Werten. Die Schlüsselinformationen enthalten einen Verweis auf das Gerät, von dem sie erstellt wurden. Das Enterprise DRS gibt eine Schlüssel-ID an die Anwendung zurück, die die Registrierung des End-of-User-Schlüssels darstellt. |
| D | Der Zertifikatanforderungsteil der Bereitstellung beginnt, nachdem die Anwendung eine erfolgreiche Antwort von der Schlüsselregistrierung erhalten hat. Die Anwendung erstellt eine PKCS#10-Zertifikatanforderung. Der in der Zertifikatanforderung verwendete Schlüssel ist derselbe Schlüssel, der sicher bereitgestellt wurde. Die Anwendung sendet die Zertifikatanforderung, die den öffentlichen Schlüssel enthält, an die Zertifikatregistrierungsstelle, die in der Active Directory-Verbunddienste (AD FS)-Farm (AD FS) gehostet wird. Nach Erhalt der Zertifikatanforderung fragt die Zertifizierungsstelle Active Directory nach msDS-KeyCredentialsLink ab, um eine Liste der registrierten öffentlichen Schlüssel zu erhalten. |
| E | Die Registrierungsstelle überprüft, ob der öffentliche Schlüssel in der Zertifikatanforderung mit einem registrierten Schlüssel für den Benutzer übereinstimmt. Nach der Überprüfung des öffentlichen Schlüssels signiert die Registrierungsstelle die Zertifikatanforderung mit ihrem Registrierungs-Agent-Zertifikat. |
| F | Die Registrierungsstelle sendet die Zertifikatanforderung an die ausstellende Zertifizierungsstelle des Unternehmens. Die Zertifizierungsstelle überprüft, ob die Zertifikatanforderung von einem gültigen Registrierungs-Agent signiert ist, stellt bei Erfolg ein Zertifikat aus und gibt es an die Registrierungsstelle zurück, die das Zertifikat dann an die Anwendung zurückgibt. |
| G | Die Anwendung empfängt das neu ausgestellte Zertifikat und installiert es im persönlichen Speicher des Benutzers. Dies signalisiert das Ende der Bereitstellung. |