Funktionsweise der 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 mit Microsoft Entra ID verknüpft wird
• Der Windows Hello for Business-Bereitstellungstyp
• Wenn die Umgebung verwaltet oder verbundiert ist

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.

Bereitstellung für Microsoft Entra verbundene Geräte mit verwalteter Authentifizierung

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 Microsoft Entra Web Account 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 Microsoft Entra Multi-Faktor-Authentifizierungsdienst stellt den zweiten Authentifizierungsfaktor bereit. Wenn der Benutzer Microsoft Entra mehrstufige Authentifizierung 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. Microsoft Entra ID ü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üsselvorgenerationspool 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 Microsoft Entra ID 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. Microsoft Entra ID gibt eine Schlüssel-ID an die Anwendung zurück, die das Ende der Benutzerbereitstellung angibt und die Anwendung beendet wird.

Bereitstellung für Microsoft Entra verbundene Geräte mit Verbundauthentifizierung

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 Microsoft Entra Web Account Manager-Plug-Ins. In einer Verbundumgebung 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 Microsoft Entra Multi-Faktor-Authentifizierungsdienst stellt den zweiten Authentifizierungsfaktor bereit. Wenn der Benutzer Microsoft Entra mehrstufige Authentifizierung 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 Microsoft Entra ID. Microsoft Entra ID ü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üsselvorgenerationspool 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 Microsoft Entra ID 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. Microsoft Entra ID gibt die Schlüssel-ID an die Anwendung zurück, die das Ende der Benutzerbereitstellung angibt und die Anwendung beendet wird.

Bereitstellung in einem Kerberos-vertrauenswürdigen Cloudbereitstellungsmodell mit verwalteter Authentifizierung

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 Microsoft Entra Web Account 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 Microsoft Entra Multi-Faktor-Authentifizierungsdienst stellt den zweiten Authentifizierungsfaktor bereit. Wenn der Benutzer Microsoft Entra mehrstufige Authentifizierung 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. Microsoft Entra ID ü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üsselvorgenerationspool 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 Microsoft Entra ID 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. Microsoft Entra ID gibt eine Schlüssel-ID an die Anwendung zurück, die das Ende der Benutzerbereitstellung angibt und die Anwendung beendet wird.

Hinweis

Windows Hello for Business Kerberos-Vertrauensstellung in der Cloud erfordert nicht, dass die Schlüssel der Benutzer aus Microsoft Entra ID mit Active Directory synchronisiert werden. Benutzer können sich nach der Bereitstellung ihrer Anmeldeinformationen sofort bei Microsoft Entra ID und AD authentifizieren.

Bereitstellung in einem Hybridschlüssel-Vertrauensstellungsmodell mit verwalteter Authentifizierung

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 Microsoft Entra Web Account 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 Microsoft Entra Multi-Faktor-Authentifizierungsdienst stellt den zweiten Authentifizierungsfaktor bereit. Wenn der Benutzer Microsoft Entra mehrstufige Authentifizierung 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. Microsoft Entra ID ü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üsselvorgenerationspool 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 Microsoft Entra ID 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. Microsoft Entra ID gibt eine Schlüssel-ID an die Anwendung zurück, die das Ende der Benutzerbereitstellung angibt und die Anwendung beendet wird.
D	Microsoft Entra Connect fordert Updates für den nächsten Synchronisierungszyklus an. Microsoft Entra ID sendet den öffentlichen Schlüssel des Benutzers, der über die Bereitstellung sicher registriert wurde. Microsoft Entra Connect empfängt den öffentlichen Schlüssel und schreibt ihn in das Attribut des msDS-KeyCredentialLink Benutzers in Active Directory.

Wichtig

Der neu bereitgestellte Benutzer kann sich erst dann mit Windows Hello for Business anmelden, wenn Microsoft Entra Connect den öffentlichen Schlüssel erfolgreich mit dem lokales Active Directory synchronisiert hat.

Bereitstellung in einem hybriden Bereitstellungsmodell mit Zertifikatvertrauensstellung mit Verbundauthentifizierung

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 Microsoft Entra Web Account Manager-Plug-Ins. In einer Verbundumgebung 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 Microsoft Entra mehrstufige Authentifizierungsdienst (oder ein Nicht-Microsoft MFA-Dienst) stellt den zweiten Authentifizierungsfaktor bereit. Der lokale STS-Server gibt bei erfolgreicher MFA ein Unternehmenstoken aus. Die Anwendung sendet das Token an Microsoft Entra ID. Microsoft Entra ID ü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üsselvorgenerationspool 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 Microsoft Entra ID 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. Microsoft Entra ID gibt eine Schlüssel-ID und eine Schlüsselbestätigung an die Anwendung zurück, die das Ende der Benutzerschlüsselregistrierung 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 hängt nicht von Microsoft Entra Connect ab, 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. Microsoft Entra Connect den öffentlichen Schlüssel weiterhin mit Active Directory synchronisiert, wird in diesem Flow jedoch nicht angezeigt.

Bereitstellung in einem lokalen Bereitstellungsmodell für Schlüsselvertrauensstellungen

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 Microsoft Entra Web Account 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. Microsoft Entra Multi-Faktor-Authentifizierungsserver (oder ein Nicht-Microsoft MFA-Dienst) 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üsselvorgenerationspool 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 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.

Bereitstellung in einem lokalen Bereitstellungsmodell mit Zertifikatvertrauen

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 Microsoft Entra Web Account 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. Microsoft Entra Multi-Faktor-Authentifizierungsserver (oder ein Nicht-Microsoft MFA-Dienst) 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üsselvorgenerationspool 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 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.