mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-27 20:57:23 +00:00
Delete pin-reset related images and update TOC for pin-reset
This commit is contained in:
Paolo Matarazzo
parent
44225edca3
commit
973d53ba4f
@ -8049,6 +8049,11 @@
|
||||
"source_path": "windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md",
|
||||
"redirect_url": "/windows/security/identity-protection/hello-for-business/rdp-sign-in",
|
||||
"redirect_document_id": false
|
||||
},
|
||||
{
|
||||
"source_path": "windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md",
|
||||
"redirect_url": "/windows/security/identity-protection/hello-for-business/pin-reset",
|
||||
"redirect_document_id": false
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -1,10 +1,12 @@
|
||||
---
|
||||
title: How Windows Hello for Business works - Provisioning
|
||||
title: How Windows Hello for Business provisioning works
|
||||
description: Explore the provisioning flows for Windows Hello for Business, from within a variety of environments.
|
||||
ms.date: 2/15/2022
|
||||
ms.topic: overview
|
||||
ms.date: 12/12/2022
|
||||
ms.topic: reference
|
||||
appliesto:
|
||||
---
|
||||
# Windows Hello for Business Provisioning
|
||||
|
||||
# How Windows Hello for Business provisioning works
|
||||
|
||||
Windows Hello for Business provisioning enables a user to enroll a new, strong, two-factor credential that they can use for passwordless authentication. Provisioning experience vary based on:
|
||||
|
||||
@ -25,8 +27,6 @@ List of provisioning flows:
|
||||
> [!NOTE]
|
||||
> The flows in this section are not exhaustive for every possible scenario. For example, Federated Key Trust is also a supported configuration.
|
||||
|
||||
<a name='azure-ad-joined-provisioning-in-a-managed-environment'></a>
|
||||
|
||||
## Microsoft Entra joined provisioning in a managed environment
|
||||
|
||||
|
||||
@ -34,110 +34,89 @@ List of provisioning flows:
|
||||
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
|B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|
||||
|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application which signals the end of user provisioning and the application exits.|
|
||||
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
|
||||
<a name='azure-ad-joined-provisioning-in-a-federated-environment'></a>
|
||||
| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
|B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|
||||
|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application, which signals the end of user provisioning and the application exits.|
|
||||
|
||||
## Microsoft Entra joined provisioning in a federated environment
|
||||
|
||||
|
||||
[Full size image](images/howitworks/prov-aadj-federated.png)
|
||||
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
|B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|
||||
|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns key ID to the application which signals the end of user provisioning and the application exits.|
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
|
||||
<a name='hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment'></a>
|
||||
| Phase | Description |
|
||||
|:-:|:-|
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns key ID to the application, which signals the end of user provisioning and the application exits. |
|
||||
|
||||
## Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment
|
||||
|
||||
|
||||
[Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png)
|
||||
|
||||
| Phase | Description |
|
||||
|:-----:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application which signals the end of user provisioning and the application exits. |
|
||||
| Phase | Description |
|
||||
|:-:|:-|
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application, which signals the end of user provisioning and the application exits. |
|
||||
|
||||
> [!NOTE]
|
||||
> Windows Hello for Business cloud Kerberos trust does not require users' keys to be synced from Microsoft Entra ID to Active Directory. Users can immediately authenticate to Microsoft Entra ID and AD after provisioning their credential.
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
|
||||
<a name='hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment'></a>
|
||||
|
||||
## Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment
|
||||
|
||||
|
||||
[Full size image](images/howitworks/prov-haadj-keytrust-managed.png)
|
||||
|
||||
| Phase | Description |
|
||||
|:-----:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application which signals the end of user provisioning and the application exits. |
|
||||
| D | Microsoft Entra Connect requests updates on its next synchronization cycle. Microsoft Entra ID sends the user's public key that was securely registered through provisioning. Microsoft Entra Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. |
|
||||
| Phase | Description |
|
||||
|:-:|:-|
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application, which signals the end of user provisioning and the application exits. |
|
||||
| D | Microsoft Entra Connect requests updates on its next synchronization cycle. Microsoft Entra ID sends the user's public key that was securely registered through provisioning. Microsoft Entra Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. |
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The newly provisioned user will not be able to sign in using Windows Hello for Business until Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory.
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
|
||||
<a name='hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment'></a>
|
||||
|
||||
## Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment
|
||||
|
||||
|
||||
[Full size image](images/howitworks/prov-haadj-instant-certtrust-federated.png)
|
||||
|
||||
| Phase | Description |
|
||||
|:-----:|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID and a key receipt to the application, which represents the end of user key registration. |
|
||||
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys. |
|
||||
| E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. |
|
||||
| F | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. |
|
||||
| G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning. |
|
||||
| Phase | Description |
|
||||
|:-:|:-|
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). | |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID and a key receipt to the application, which represents the end of user key registration. |
|
||||
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys. |
|
||||
| E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> If the public key in the certificate isn't found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. |
|
||||
| F | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. |
|
||||
| G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning. |
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Synchronous certificate enrollment does not depend on Microsoft Entra Connect to synchronize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Microsoft Entra Connect continues to synchronize the public key to Active Directory, but is not shown in this flow.
|
||||
> Synchronous certificate enrollment doesn't depend on Microsoft Entra Connect to synchronize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Microsoft Entra Connect continues to synchronize the public key to Active Directory, but is not shown in this flow.
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
## Domain joined provisioning in an On-premises Key Trust deployment
|
||||
|
||||
|
||||
[Full size image](images/howitworks/prov-onprem-keytrust.png)
|
||||
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise DRS token on successful MFA.|
|
||||
| B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|
||||
|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Microsoft Entra multifactor authentication server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise DRS token on successful MFA.|
|
||||
| B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|
||||
|C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration. Enterprise DRS validates the MFA claim remains current. On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
|
||||
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
## Domain joined provisioning in an On-premises Certificate Trust deployment
|
||||
|
||||
[Full size image](images/howitworks/prov-onprem-certtrust.png)
|
||||
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise DRS token on successful MFA.|
|
||||
| B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|
||||
|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Microsoft Entra multifactor authentication server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise DRS token on successful MFA.|
|
||||
| B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|
||||
|C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration. Enterprise DRS validates the MFA claim remains current. On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
|
||||
|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys.|
|
||||
|E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> After validating the public key, the registration authority signs the certificate request using its enrollment agent certificate.|
|
||||
|F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
|
||||
|G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning.|
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
|
||||
|
Before Width: | Height: | Size: 159 KiB After Width: | Height: | Size: 159 KiB |
|
Before Width: | Height: | Size: 133 KiB After Width: | Height: | Size: 133 KiB |
|
Before Width: | Height: | Size: 58 KiB After Width: | Height: | Size: 58 KiB |
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
|
Before Width: | Height: | Size: 52 KiB After Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.0 MiB |
@ -1,39 +1,39 @@
|
||||
---
|
||||
title: PIN reset
|
||||
description: Learn how Microsoft PIN reset service enables your users to recover a forgotten Windows Hello for Business PIN.
|
||||
ms.date: 08/15/2023
|
||||
description: Learn how Microsoft PIN reset service enables your users to recover a forgotten Windows Hello for Business PIN, and how to configure it.
|
||||
ms.date: 12/12/2023
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
# PIN reset
|
||||
|
||||
This article describes how *Microsoft PIN reset service* enables your users to recover a forgotten Windows Hello for Business PIN.
|
||||
This article describes how *Microsoft PIN reset service* enables your users to recover a forgotten Windows Hello for Business PIN, and how to configure it.
|
||||
|
||||
## Overview
|
||||
|
||||
Windows Hello for Business provides the capability for users to reset forgotten PINs. There are two forms of PIN reset:
|
||||
|
||||
- *Destructive PIN reset*: with this option, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new sign in key and PIN are provisioned. Destructive PIN reset is the default option, and doesn't require configuration
|
||||
- *Non-destructive PIN reset*: with this option, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed. For non-destructive PIN reset, you must deploy the *Microsoft PIN reset service* and configure your clients' policy to enable the *PIN recovery* feature
|
||||
- *Destructive PIN reset*: the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new sign in key and PIN are provisioned. Destructive PIN reset is the default option, and doesn't require configuration
|
||||
- *Non-destructive PIN reset*: the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed. For nondestructive PIN reset, you must deploy the *Microsoft PIN reset service* and configure your clients' policy to enable the *PIN recovery* feature
|
||||
|
||||
## How non-destructive PIN reset works
|
||||
## How nondestructive PIN reset works
|
||||
|
||||
**Requirements:**
|
||||
|
||||
- Hybrid or cloud-only Windows Hello for Business deployments
|
||||
- Windows Enterprise, Education and Pro editions. There's no licensing requirement for this feature
|
||||
|
||||
When non-destructive PIN reset is enabled on a client, a *256-bit AES* key is generated locally. The key is added to a user's Windows Hello for Business container and keys as the *PIN reset protector*. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to Microsoft Entra ID, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it's then cleared from memory.
|
||||
When nondestructive PIN reset is enabled on a client, a *256-bit AES* key is generated locally. The key is added to a user's Windows Hello for Business container and keys as the *PIN reset protector*. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multifactor authentication to Microsoft Entra ID, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys, and it's then cleared from memory.
|
||||
|
||||
Using Group Policy, Microsoft Intune or a compatible MDM solution, you can configure Windows devices to securely use the Microsoft PIN reset service, which enables users to reset their forgotten PIN without requiring re-enrollment.
|
||||
|
||||
The following table compares destructive and non-destructive PIN reset:
|
||||
The following table compares destructive and nondestructive PIN reset:
|
||||
|
||||
|Category|Destructive PIN reset|Non-Destructive PIN reset|
|
||||
|Category|Destructive PIN reset|Nondestructive PIN reset|
|
||||
|--- |--- |--- |
|
||||
|**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new sign in key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.|
|
||||
|**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new sign in key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a nondestructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.|
|
||||
|**Microsoft Entra joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust|
|
||||
|**Microsoft Entra hybrid joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this option from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
|
||||
|**Microsoft Entra hybrid joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this option from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support nondestructive PIN reset. No network connection is required for the DC.|
|
||||
|**On Premises**|If AD FS is used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Microsoft Entra identities, so it's only available for Microsoft Entra hybrid joined and Microsoft Entra joined devices.|
|
||||
|**Additional configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature.|
|
||||
|**MSA/Enterprise**|MSA and Enterprise|Enterprise only.|
|
||||
@ -42,7 +42,7 @@ The following table compares destructive and non-destructive PIN reset:
|
||||
|
||||
## Enable the Microsoft PIN Reset Service in your Microsoft Entra tenant
|
||||
|
||||
Before you can use non-destructive PIN reset, you must register two applications in your Microsoft Entra tenant:
|
||||
Before you can use nondestructive PIN reset, you must register two applications in your Microsoft Entra tenant:
|
||||
|
||||
- Microsoft Pin Reset Service Production
|
||||
- Microsoft Pin Reset Client Production
|
||||
@ -54,7 +54,7 @@ To register the applications, follow these steps:
|
||||
1. Go to the [Microsoft PIN Reset Service Production website][APP-1], and sign in using a *Global Administrator* account you use to manage your Microsoft Entra tenant. Review the permissions requested by the *Microsoft Pin Reset Service Production* application and select **Accept** to give consent to the application to access your organization
|
||||
:::column-end:::
|
||||
:::column span="1":::
|
||||
:::image type="content" alt-text="Screenshot showing the PIN reset service permissions page." source="images/pinreset/pin-reset-service-prompt.png" lightbox="images/pinreset/pin-reset-service-prompt.png" border="true":::
|
||||
:::image type="content" alt-text="Screenshot showing the PIN reset service permissions page." source="images/pin-reset/pin-reset-service-prompt.png" lightbox="images/pin-reset/pin-reset-service-prompt.png" border="true":::
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
:::row:::
|
||||
@ -62,7 +62,7 @@ To register the applications, follow these steps:
|
||||
2. Go to the [Microsoft PIN Reset Client Production website][APP-2], and sign in using a *Global Administrator* account you use to manage your Microsoft Entra tenant. Review the permissions requested by the *Microsoft Pin Reset Client Production* application, and select **Next**.
|
||||
:::column-end:::
|
||||
:::column span="1":::
|
||||
:::image type="content" alt-text="Screenshot showing the PIN reset client permissions page." source="images/pinreset/pin-reset-client-prompt.png" lightbox="images/pinreset/pin-reset-client-prompt.png" border="true":::
|
||||
:::image type="content" alt-text="Screenshot showing the PIN reset client permissions page." source="images/pin-reset/pin-reset-client-prompt.png" lightbox="images/pin-reset/pin-reset-client-prompt.png" border="true":::
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
:::row:::
|
||||
@ -72,7 +72,7 @@ To register the applications, follow these steps:
|
||||
>After acceptance, the redirect page will show a blank page. This is a known behavior.
|
||||
:::column-end:::
|
||||
:::column span="1":::
|
||||
:::image type="content" alt-text="Screenshot showing the PIN reset service permissions final page." source="images/pinreset/pin-reset-service-prompt-2.png" lightbox="images/pinreset/pin-reset-service-prompt-2.png" border="true":::
|
||||
:::image type="content" alt-text="Screenshot showing the PIN reset service permissions final page." source="images/pin-reset/pin-reset-service-prompt-2.png" lightbox="images/pin-reset/pin-reset-service-prompt-2.png" border="true":::
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
|
||||
@ -81,7 +81,7 @@ To register the applications, follow these steps:
|
||||
1. Sign in to the [Microsoft Entra Manager admin center](https://entra.microsoft.com)
|
||||
1. Select **Microsoft Entra ID > Applications > Enterprise applications**
|
||||
1. Search by application name "Microsoft PIN" and verify that both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** are in the list
|
||||
:::image type="content" alt-text="PIN reset service permissions page." source="images/pinreset/pin-reset-applications.png" lightbox="images/pinreset/pin-reset-applications-expanded.png":::
|
||||
:::image type="content" alt-text="PIN reset service permissions page." source="images/pin-reset/pin-reset-applications.png" lightbox="images/pin-reset/pin-reset-applications-expanded.png":::
|
||||
|
||||
## Enable PIN recovery on the clients
|
||||
|
||||
@ -136,7 +136,7 @@ GET https://graph.microsoft.com/v1.0/organization?$select=id
|
||||
|
||||
#### Confirm that PIN Recovery policy is enforced on the devices
|
||||
|
||||
The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) from the command line. This state can be found under the output in the user state section as the **CanReset** line item. If **CanReset** reports as DestructiveOnly, then only destructive PIN reset is enabled. If **CanReset** reports DestructiveAndNonDestructive, then non-destructive PIN reset is enabled.
|
||||
The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) from the command line. This state can be found under the output in the user state section as the **CanReset** line item. If **CanReset** reports as DestructiveOnly, then only destructive PIN reset is enabled. If **CanReset** reports DestructiveAndNonDestructive, then nondestructive PIN reset is enabled.
|
||||
|
||||
**Sample User state Output for Destructive PIN Reset**
|
||||
|
||||
@ -182,7 +182,7 @@ The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/a
|
||||
|
||||
**Applies to:** Microsoft Entra joined devices
|
||||
|
||||
PIN reset on Microsoft Entra joined devices uses a flow called *web sign-in* to authenticate users in the lock screen. Web sign-in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message: *"We can't open that page right now"*.\
|
||||
PIN reset on Microsoft Entra joined devices uses a flow called *web sign-in* to authenticate users in the lock screen. Web sign-in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message: *We can't open that page right now*.\
|
||||
If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, then you must configure your devices with a policy to allow a list of domains that can be reached during PIN reset flows. When set, it ensures that authentication pages from that identity provider can be used during Microsoft Entra joined PIN reset.
|
||||
|
||||
[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
|
||||
@ -202,9 +202,9 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the
|
||||
> [!NOTE]
|
||||
> For Azure Government, there is a known issue with PIN reset on Microsoft Entra joined devices failing. When the user attempts to launch PIN reset, the PIN reset UI shows an error page that says, *"We can't open that page right now"*. The ConfigureWebSignInAllowedUrls policy can be used to work around this issue. If you are experiencing this problem and you are using Azure US Government cloud, set **login.microsoftonline.us** as the value for the ConfigureWebSignInAllowedUrls policy.
|
||||
|
||||
## Use PIN reset
|
||||
## User experience
|
||||
|
||||
Destructive and non-destructive PIN reset scenarios use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users don't have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen with the *PIN credential provider*. Users must authenticate and complete multi-factor authentication to reset their PIN. After PIN reset is complete, users can sign in using their new PIN.
|
||||
Destructive and nondestructive PIN reset scenarios use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users don't have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen with the *PIN credential provider*. Users must authenticate and complete multifactor authentication to reset their PIN. After PIN reset is complete, users can sign in using their new PIN.
|
||||
|
||||
>[!IMPORTANT]
|
||||
>For Microsoft Entra hybrid joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN.
|
||||
@ -225,7 +225,7 @@ For Microsoft Entra joined devices:
|
||||
1. Follow the instructions provided by the provisioning process
|
||||
1. When finished, unlock your desktop using your newly created PIN
|
||||
|
||||
:::image type="content" alt-text="Animation showing the PIN reset experience from the lock screen." source="images/pinreset/pin-reset.gif" border="false":::
|
||||
> [!VIDEO https://learn-video.azurefd.net/vod/player?id=310f7665-6276-4ad8-b76e-429073c10972]
|
||||
|
||||
For Microsoft Entra hybrid joined devices:
|
||||
|
||||
@ -107,7 +107,7 @@ items:
|
||||
- name: Windows Hello for Business features
|
||||
items:
|
||||
- name: PIN reset
|
||||
href: hello-feature-pin-reset.md
|
||||
href: pin-reset.md
|
||||
- name: Windows Hello Enhanced Security Sign-in (ESS) 🔗
|
||||
href: /windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security
|
||||
- name: Dual enrollment
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user