deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-19 00:37:22 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge pull request #9206 from paolomatarazzo/pm-202231212-pin-reset

Browse Source 
[WHFB] PIN reset
This commit is contained in:
Stacyrch140 2023-12-12 13:33:31 -05:00 committed by GitHub
commit 9dedcb2493
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
19 changed files with 146 additions and 255 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
.openpublishing.redirection.windows-security.json
View File

@ -8054,6 +8054,16 @@
"source_path": "windows/security/security-foundations/msft-security-dev-lifecycle.md",
"redirect_url": "/compliance/assurance/assurance-microsoft-security-development-lifecycle",
"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
},
{
"source_path": "windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md",
"redirect_url": "/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services",
"redirect_document_id": false
}
]
}

99
windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md
View File

@ -1,99 +0,0 @@
---
title: Plan an adequate number of Domain Controllers for Windows Hello for Business deployments
description: Learn how to plan for an adequate number of Domain Controllers to support Windows Hello for Business deployments.
ms.date: 03/10/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: conceptual
---
# Plan an adequate number of Domain Controllers for Windows Hello for Business deployments
> [!NOTE]
>There was an issue with key trust authentication on Windows Server 2019. To fix it, refer to [KB4487044](https://support.microsoft.com/help/4487044/windows-10-update-kb4487044).
## How many is adequate
How can you find out how many domain controllers are needed? You can use performance monitoring on your domain controllers to determine existing authentication traffic. Windows Server 2016 and above includes the KDC AS Requests performance counter. You can use this counter to determine how much of a domain controller's load is due to initial Kerberos authentication. It's important to remember that authentication for a Windows Hello for Business key trust deployment does not affect Kerberos authentication - it remains unchanged.
Windows 10 or Windows 11 accomplishes Windows Hello for Business key trust authentication by mapping an Active Directory user account to one or more public keys. This mapping occurs on the domain controller, which is why the deployment needs Windows Server 2016 or later domain controllers. Public key mapping is only supported by Windows Server 2016 domain controllers and above. Therefore, users in a key trust deployment must authenticate to a Windows Server 2016 and above domain controller.
Determining an adequate number of Windows Server domain controllers is important to ensure you have enough domain controllers to satisfy all authentication requests, including users mapped with public key trust. What many administrators do not realize is that adding a domain controller that supports public key mapping (in this case Windows Server 2016 or later) to a deployment of existing domain controllers which do not support public key mapping (Windows Server 2008R2, Windows Server 2012R2) instantly makes that single domain controller susceptible to carrying the most load, or what is commonly referred to as "piling on". To illustrate the "piling on" concept, consider the following scenario:
Consider a controlled environment where there are 1000 client computers and the authentication load of these 1000 client computers is evenly distributed across 10 domain controllers in the environment. The Kerberos AS requests load would look something like the following:
![dc-chart1.](images/plan/dc-chart1.png)
The environment changes. The first change includes DC1 upgraded to Windows Server 2016 or later to support Windows Hello for Business key-trust authentication. Next, 100 clients enroll for Windows Hello for Business using the public key trust deployment. Given all other factors stay constant, the authentication would now look like the following:
![dc-chart2.](images/plan/dc-chart2.png)
The Windows Server 2016 or later domain controller is handling 100 percent of all public key trust authentication. However, it is also handling 10 percent of password authentication. Why? This behavior occurs because domain controllers 2 - 10 only support password and certificate trust authentication; only a Windows Server 2016 and above domain controller supports public key trust authentication. The Windows Server 2016 and above domain controller still understands how to authenticate password and certificate trust authentication and will continue to share the load of authenticating those clients. Because DC1 can handle all forms of authentication, it will bear more of the authentication load, and easily become overloaded. What if another Windows Server 2016 or later domain controller is added, but without deploying Windows Hello for Business to any more clients?
![dc-chart3.](images/plan/dc-chart3.png)
Upgrading another domain controller to Windows Server 2016 or later distributes the public key trust authentication across two domain controllers - each supporting 50 percent of the load. But it doesn't change the distribution of password and certificate trust authentication. Both Windows Server 2019 domain controllers still share 10 percent of this load. Now look at the scenario when half of the domain controllers are upgraded to Windows Server 2016 or later, but the number of Windows Hello for Business clients remains the same.
![dc-chart4.](images/plan/dc-chart4.png)
Domain controllers 1 through 5 now share the public key trust authentication load where each domain controller handles 20 percent of the public key trust load but they each still handle 10 percent of the password and certificate trust authentication. These domain controllers still have a heavier load than domain controllers 6 through 10; however, the load is adequately distributed. Now look the scenario when half of the client computers are upgraded to Windows Hello for Business using a key-trust deployment.
![dc-chart5.](images/plan/dc-chart5.png)
You'll notice the distribution did not change. Each Windows Server 2016 or later domain controller handles 20 percent of the public key trust authentication. However, increasing the volume of authentication (by increasing the number of clients) increases the amount of work that is represented by the same 20 percent. In the previous example, 20 percent of public key trust authentication equated to a volume of 20 authentications per domain controller capable of public key trust authentication. However, with upgraded clients, that same 20 percent represents a volume of 100 public key trust authentications per public key trust capable domain controller. Also, the distribution of non-public key trust authentication remained at 10 percent, but the volume of password and certificate trust authentications decreased across the older domain controllers.
There are several conclusions here:
- Upgrading domain controllers changes the distribution of new authentication, but doesn't change the distribution of older authentication.
- Upgrading domain controllers does not affect the distribution of password and certificate trust authentication because newer domain controllers can support password and certificate trust authentication.
- Upgraded domain controllers typically carry a heavier authentication load than down-level domain controllers because they support more forms of authentication.
- Upgrading clients to Windows Hello for Business, increases the volume of public key trust authentication distributed across domain controllers which support it and, reduces the volume of password and certificate trust authentication across all domain controllers
- Upgrading clients to Windows Hello for Business but does not affect the distribution of authentication; only the volume of authentication.
The preceding was an example to show why it's unrealistic to have a "one-size-fits-all" number to describe what "an adequate amount" means. In the real world, authentication is not evenly distributed across domain controllers.
## Determining total AS Request load
Each organization needs to have a baseline of the AS request load that occurs in their environment. Windows Server provides the KDC AS Requests performance counter that helps you determine this.
Pick a site where you plan to upgrade the clients to Windows Hello for Business public key trust. Pick a time when authentication traffic is most significant--Monday morning is great time as everyone is returning to the office. Enable the performance counter on *all* the domain controllers in that site. Collect KDC AS Requests performance counters for two hours:
- A half-hour before you expect initial authentication (sign-ins and unlocks) to be significant
- The hour you believe initial authentication to be significant
- And a half-hour after you expect initial authentication to be significant
For example, if employees are scheduled to come into the office at 9:00am. Your performance capture should begin at 8:30am and end at 10:30am. Ensure your performance logs do not wrap the data. You want to see authentication trend upward, peak, and trend downward.
> [!NOTE]
> To capture all the authentication traffic. Ensure that all computers are powered down to get the most accurate authentication information (computers and services authenticate at first power up--you need to consider this authentication in your evaluation).
Aggregate the performance data of all domain controllers. Look for the maximum KDC AS Requests for each domain controller. Find the median time when the maximum number of requests occurred for the site, this should represent when the site is experiencing the highest amount of authentication.
Add the number of authentications for each domain controller for the median time. You now have the total authentication for the site during a peak time. Using this metric, you can determine the distribution of authentication across the domain controllers in the site by dividing the domain controller's authentication number for the median time by the total authentication. Multiply the quotient by 10 to convert the distribution to a percentage. To validate your math, all the distributions should equal 100 percent.
Review the distribution of authentication. Hopefully, none of these are above 70 percent. It's always good to reserve some capacity for the unexpected. Also, the primary purposes of a domain controller are to provide authentication and handle Active Directory operations. Identify domain controllers with lower distributions of authentication as potential candidates for the initial domain controller upgrades in conjunction with a reasonable distribution of clients provisioned for Windows Hello for Business.
## Monitoring Authentication
Using the same methods described above, monitor the Kerberos authentication after upgrading a domain controller and your first phase of Windows Hello for Business deployments. Make note of the delta of authentication before and after upgrading the domain controller to Windows Server 2016 or newer. This delta is representative of authentication resulting from the first phase of your Windows Hello for Business clients. It gives you a baseline for your environment to where you can form a statement such as:
```"Every n Windows Hello for Business clients results in x percentage of key-trust authentication."```
Where *n* equals the number of clients you switched to Windows Hello for Business and *x* equals the increased percentage of authentication from the upgraded domain controller. Armed with this information, you can apply the observations of upgrading domain controllers and increasing Windows Hello for Business client count to appropriately phase your deployment.
Remember, increasing the number of clients changes the volume of authentication distributed across the Windows Server 2016 or newer domain controllers. If there is only one Windows Server 2016 or newer domain controller, there's no distribution and you are simply increasing the volume of authentication for which THAT domain controller is responsible.
Increasing the number of domain controllers distributes the volume of authentication, but doesn't change it. Therefore, as you add more domain controllers, the burden of authentication, for which each domain controller is responsible, decreases. Upgrading two domain controller changes the distribution to 50 percent. Upgrading three domain controllers changes the distribution to 33 percent, and so on.
## Strategy
The simplest strategy you can employ is to upgrade one domain controller and monitor the single domain controller as you continue to phase in new Windows Hello for Business key-trust clients until it reaches a 70 or 80 percent threshold.
Then, upgrade a second domain controller. Monitor the authentication on both domain controllers to determine how the authentication distributes between the two domain controllers. Introduce more Windows Hello for Business clients while monitoring the authentication on the two upgraded domain controllers. Once those reach your environment's designated capacity, you can upgrade another domain controller.
Repeat until your deployment for that site is complete. Now, monitor authentication across all your domain controllers like you did the very first time. Determine the distribution of authentication for each domain controller. Identify the percentage of distribution for which it is responsible. If a single domain controller is responsible for 70 percent of more of the authentication, you may want to consider adding a domain controller to reduce the distribution of authentication volume.
However, before considering this, ensure the high load of authentication is not a result of applications and services where their configuration has a statically-configured domain controller. Adding domain controllers will not resolve the additional authentication load problem in this scenario. Instead, manually distribute the authentication to different domain controllers among all the services or applications. Alternatively, try simply using the domain name rather than a specific domain controller. Each domain controller has an A record registered in DNS for the domain name, which DNS will round robin with each DNS query. It's not the best load balancer, however, it is a better alternative to static domain controller configurations, provided the configuration is compatible with your service or application.

23
windows/security/identity-protection/hello-for-business/hello-deployment-guide.md
View File

@ -3,7 +3,9 @@ title: Windows Hello for Business Deployment Overview
description: Use this deployment guide to successfully deploy Windows Hello for Business in an existing environment.
ms.date: 02/15/2022
ms.topic: overview
appliesto:
---
# Windows Hello for Business Deployment Overview
Windows Hello for Business is the springboard to a world without passwords. It replaces username and password sign-in to Windows with strong user authentication based on an asymmetric key pair.
@ -12,7 +14,7 @@ This deployment overview is to guide you through deploying Windows Hello for Bus
Once you've chosen a deployment model, the deployment guide for that model will provide you with the information needed to successfully deploy Windows Hello for Business in your environment. Read the [Windows Hello for Business Deployment Prerequisite Overview](hello-identity-verification.md) for a summary of the prerequisites for each different Windows Hello for Business deployment model.
## Assumptions
## Requirements
This guide assumes that baseline infrastructure exists which meets the requirements for your deployment. For either hybrid or on-premises deployments, it is expected that you have:
@ -21,12 +23,12 @@ This guide assumes that baseline infrastructure exists which meets the requireme
- Multi-factor Authentication is required during Windows Hello for Business provisioning
- Proper name resolution, both internal and external names
- Active Directory and an adequate number of domain controllers per site to support authentication
- Active Directory Certificate Services 2012 or later (Note: certificate services are not needed for cloud Kerberos trust deployments)
- Active Directory Certificate Services 2012 or later (Note: certificate services aren't needed for cloud Kerberos trust deployments)
- One or more workstation computers running Windows 10, version 1703 or later
If you are installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.
If you're installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.
Do not begin your deployment until the hosting servers and infrastructure (not roles) identified in your prerequisite worksheet are configured and properly working.
Don't begin your deployment until the hosting servers and infrastructure (not roles) identified in your prerequisite worksheet are configured and properly working.
## Deployment and trust models
@ -36,12 +38,12 @@ Hybrid deployments are for enterprises that use Microsoft Entra ID. On-premises
The trust model determines how you want users to authenticate to the on-premises Active Directory:
- The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
- The cloud-trust model is also for hybrid enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and does not require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
- The key-trust model is for enterprises who don't want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
- The cloud-trust model is also for hybrid enterprises who don't want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and doesn't require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
- The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today.
- The certificate trust model also supports enterprises which are not ready to deploy Windows Server 2016 Domain Controllers.
- The certificate trust model also supports enterprises, which aren't ready to deploy Windows Server 2016 Domain Controllers.
> [!Note]
> [!NOTE]
> RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Remote Credential Guard](../remote-credential-guard.md).
Following are the various deployment guides and models included in this topic:
@ -53,10 +55,11 @@ Following are the various deployment guides and models included in this topic:
- [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
- [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md)
For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you will need Microsoft Entra Connect to synchronize user accounts in the on-premises Active Directory with Microsoft Entra ID. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials are not synchronized to Microsoft Entra ID. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](hello-key-trust-validate-deploy-mfa.md) and [for certificate trust](hello-cert-trust-validate-deploy-mfa.md) deployments.
For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you'll need Microsoft Entra Connect to synchronize user accounts in the on-premises Active Directory with Microsoft Entra ID. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials aren't synchronized to Microsoft Entra ID. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](hello-key-trust-validate-deploy-mfa.md) and [for certificate trust](hello-cert-trust-validate-deploy-mfa.md) deployments.
## Provisioning
Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
Note that you need to allow access to the URL account.microsoft.com to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL does not require any authentication and as such, does not collect any user data.
> [!NOTE]
> You must allow access to the URL `account.microsoft.com` to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL doesn't require any authentication and as such, doesn't collect any user data.

96
windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
View File

@ -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:
@ -14,34 +16,27 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
List of provisioning flows:
- [Microsoft Entra joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment)
- [Microsoft Entra joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)
- [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
- [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
- [Microsoft Entra joined provisioning in a managed environment](#microsoft-entra-joined-provisioning-in-a-managed-environment)
- [Microsoft Entra joined provisioning in a federated environment](#microsoft-entra-joined-provisioning-in-a-federated-environment)
- [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#microsoft-entra-hybrid-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#microsoft-entra-hybrid-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
- [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#microsoft-entra-hybrid-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
- [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)
- [Domain joined provisioning in an On-premises certificate trust deployment](#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment)
> [!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
![Microsoft Entra joined provisioning in a managed environment.](images/howitworks/prov-aadj-managed.png)
[Full size image](images/howitworks/prov-aadj-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.|
[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
@ -49,14 +44,10 @@ List of provisioning flows:
[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>
|:-:|:-|
| 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
@ -64,80 +55,69 @@ List of provisioning flows:
[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. |
|:-:|:-|
| 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
![Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment.](images/howitworks/prov-haadj-keytrust-managed.png)
[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. |
|:-:|:-|
| 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
![Microsoft Entra hybrid joined provisioning in a synchronous Certificate trust deployment in a federated environment.](images/howitworks/prov-haadj-instant-certtrust-federated.png)
[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). |
|:-|:-|
| 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 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. |
| 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
![Domain joined provisioning in an On-premises Key Trust deployment.](images/howitworks/prov-onprem-keytrust.png)
[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
![Domain joined provisioning in an On-premises Certificate Trust deployment.](images/howitworks/prov-onprem-certtrust.png)
[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)

66
windows/security/identity-protection/hello-for-business/hello-planning-guide.md
View File

@ -1,17 +1,18 @@
---
title: Planning a Windows Hello for Business Deployment
title: Plan a Windows Hello for Business Deployment
description: Learn about the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of your infrastructure.
ms.date: 09/16/2020
ms.topic: overview
---
# Planning a Windows Hello for Business Deployment
# Plan a Windows Hello for Business Deployment
Congratulations! You're taking the first step forward in helping move your organizations away from password to a two-factor, convenience authentication for Windows — Windows Hello for Business. This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure. Armed with your planning worksheet, you'll use that information to select the correct deployment guide for your needs.
> [!Note]
>If you have an Azure tenant, you can use our online, interactive Passwordless Wizard which walks through the same choices instead of using our manual guide below. The Passwordless Wizard is available in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup).
> If you have a Microsoft Entra ID tenant, you can use our online, interactive Passwordless Wizard which walks through the same choices instead of using our manual guide below. The Passwordless Wizard is available in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup).
## Using this guide
@ -46,7 +47,7 @@ There are three deployment models from which you can choose: cloud only, hybrid,
##### Cloud only
The cloud only deployment model is for organizations who only have cloud identities and do not access on-premises resources. These organizations typically join their devices to the cloud and exclusively use resources in the cloud such as SharePoint, OneDrive, and others. Also, because these users do not use on-premises resources, they do not need certificates for things like VPN because everything they need is hosted in Azure.
The cloud only deployment model is for organizations who only have cloud identities and don't access on-premises resources. These organizations typically join their devices to the cloud and exclusively use resources in the cloud such as SharePoint, OneDrive, and others. Also, because these users don't use on-premises resources, they don't need certificates for things like VPN because everything they need is hosted in Azure.
##### Hybrid
@ -64,7 +65,7 @@ The hybrid deployment model is for organizations that:
> - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
##### On-premises
The on-premises deployment model is for organizations that do not have cloud identities or use applications hosted in Microsoft Entra ID.
The on-premises deployment model is for organizations that don't have cloud identities or use applications hosted in Microsoft Entra ID.
> [!Important]
> On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust models.
@ -85,7 +86,7 @@ A deployment's trust type defines how each Windows Hello for Business client aut
The key trust type doesn't require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience. Unlike key trust, certificate trust does not require Windows Server 2016 domain controllers (but still requires [Windows Server 2016 or later Active Directory schema](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directories)). Users can use their certificate to authenticate to any Windows Server 2008 R2, or later, domain controller.
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience. Unlike key trust, certificate trust doesn't require Windows Server 2016 domain controllers (but still requires [Windows Server 2016 or later Active Directory schema](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directories)). Users can use their certificate to authenticate to any Windows Server 2008 R2, or later, domain controller.
> [!NOTE]
> RDP does not support authentication with Windows Hello for Business key trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust can be used with [Remote Credential Guard](../remote-credential-guard.md).
@ -103,7 +104,7 @@ The built-in Windows Hello for Business provisioning experience creates a hardwa
> [!IMPORTANT]
> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multifactor authentication for their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure Multi-Factor Authentication Server](/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
The goal of Windows Hello for Business is to move organizations away from passwords by providing them a with strong credential that provides easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
The goal of Windows Hello for Business is to move organizations away from passwords by providing them with a strong credential that enables easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
Cloud only and hybrid deployments provide many choices for multifactor authentication. On-premises deployments must use a multifactor authentication that provides an AD FS multifactor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multi-Factor Authentication Server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
> [!NOTE]
@ -130,7 +131,7 @@ Group Policy is the easiest and most popular way to manage Windows Hello for Bus
#### Modern management
Modern management is an emerging device management paradigm that leverages the cloud for managing domain joined and non-domain joined devices. Organizations can unify their device management into one platform and apply policy settings using a single platform
Modern management is an emerging device management paradigm that leverages the cloud for managing domain joined and nondomain joined devices. Organizations can unify their device management into one platform and apply policy settings using a single platform
### Client
@ -161,15 +162,16 @@ Use the remainder of this guide to help with planning your deployment. As you m
Choose the deployment model based on the resources your users access. Use the following guidance to make your decision.
If your organization does not have on-premises resources, write **Cloud Only** in box **1a** on your planning worksheet.
If your organization doesn't have on-premises resources, write **Cloud Only** in box **1a** on your planning worksheet.
If your organization is federated with Azure or uses any service, such as AD Connect, Office365 or OneDrive, or your users access cloud and on-premises resources, write **Hybrid** in box **1a** on your planning worksheet.
If your organization does not have cloud resources, write **On-Premises** in box **1a** on your planning worksheet.
> [!NOTE]
> * Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests".
> * Migration from on-premise to hybrid deployment will require redeployment.
If your organization doesn't have cloud resources, write **On-Premises** in box **1a** on your planning worksheet.
>[!NOTE]
>
>- Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests"
>- Migration from on-premise to hybrid deployment will require redeployment
### Trust type
@ -177,9 +179,9 @@ Microsoft Entra hybrid joined devices managed by Group Policy need the Windows S
Choose a trust type that is best suited for your organizations. Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers.
One trust model is not more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers and needing to enroll certificates for all their users (certificate trust).
One trust model isn't more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers and needing to enroll certificates for all their users (certificate trust).
Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
Because the certificate trust types issues certificates, there's more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**.
@ -203,9 +205,9 @@ If box **1a** on your planning worksheet reads **on-premises**, write **AD FS**
### Directory Synchronization
Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multifactor authentication during provisioning or writing the user's public key.
Windows Hello for Business is strong user authentication, which usually means there's an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multifactor authentication during provisioning or writing the user's public key.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Microsoft Entra ID and there is not another directory with which the information must be synchronized.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Microsoft Entra ID and there isn't another directory with which the information must be synchronized.
If box **1a** on your planning worksheet reads **hybrid**, then write **Microsoft Entra Connect** in box **1e** on your planning worksheet.
@ -213,7 +215,7 @@ If box **1a** on your planning worksheet reads **on-premises**, then write **Azu
### Multifactor authentication
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and can't be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
If box **1a** on your planning worksheet reads **cloud only**, then your only option is to use the Azure MFA cloud service. Write **Azure MFA** in box **1f** on your planning worksheet.
@ -233,7 +235,7 @@ Alternatively, you can use AD FS with an on-premises Azure MFA server adapter. R
The last option is for you to use AD FS with a third-party adapter as the second factor of authentication. If you choose to use AD FS with a third-party MFA adapter, write **AD FS with third party** in box **1f** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, then you have two second factor authentication options. You must use Windows Server 2016 AD FS with your choice of the on-premises Azure MFA server or with a third-party MFA adapter.
If box **1a** on your planning worksheet reads **on-premises**, then you have two-second factor authentication options. You must use Windows Server 2016 AD FS with your choice of the on-premises Azure MFA server or with a third-party MFA adapter.
If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with Azure MFA server adapter** in box **1f** on your planning worksheet. If you choose to use AD FS with a third-party MFA adapter, write **AD FS with third party** in box **1f** on your planning worksheet.
@ -241,38 +243,38 @@ If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with
Windows Hello for Business provides organizations with many policy settings and granular control on how these settings may be applied to both computers and users. The type of policy management you can use depends on your selected deployment and trust models.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Microsoft Entra joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage nondomain joined devices. If you choose to manage Microsoft Entra joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
> [!NOTE]
> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
If box **1a** on your planning worksheet reads **on-prem**, write **GP** in box **2a** on your planning worksheet. Write **N/A** in box **2b** on your worksheet.
Managing hybrid deployments includes two categories of devices to consider for your Windows Hello for Business deployment—domain joined and non-domain joined. All devices are registered, however, not all devices are domain joined. You have the option of using Group Policy for domain joined devices and modern management for non-domain joined devices. Or, you can use modern management for both domain and non-domain joined devices.
Managing hybrid deployments includes two categories of devices to consider for your Windows Hello for Business deployment—domain joined and nondomain joined. All devices are registered, however, not all devices are domain joined. You have the option of using Group Policy for domain joined devices and modern management for nondomain joined devices. Or, you can use modern management for both domain and nondomain joined devices.
If you use Group Policy to manage your domain joined devices, write **GP** in box **2a** on your planning worksheet. Write **modern management** in box **2b** if you decide to manage non-domain joined devices; otherwise, write **N/A**.
If you use Group Policy to manage your domain joined devices, write **GP** in box **2a** on your planning worksheet. Write **modern management** in box **2b** if you decide to manage nondomain joined devices; otherwise, write **N/A**.
If you use modern management for both domain and non-domain joined devices, write **modern management** in box **2a** and **2b** on your planning worksheet.
If you use modern management for both domain and nondomain joined devices, write **modern management** in box **2a** and **2b** on your planning worksheet.
### Client
Windows Hello for Business is a feature exclusive to Windows 10 and Windows 11. Some deployments and features are available using earlier versions of Windows 10. Others need the latest versions.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
> [!NOTE]
> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
Write **1511 or later** in box **3a** on your planning worksheet if any of the following are true.
* Box **2a** on your planning worksheet read **modern management**.
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
* Box **1a** on your planning worksheet reads **hybrid**, box **1b** reads **key trust**, and box **2a** reads **GP**.
<em>Optionally, you may write **1511 or later</em>* in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
<em>Optionally, you may write **1511 or later</em>* in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
Write **1703 or later** in box **3a** on your planning worksheet if any of the following are true.
* Box **1a** on your planning worksheet reads **on-premises**.
Write **N/A** in box **3b** on your planning worksheet.
* Box **1a** on your planning worksheet reads **hybrid**, box **1b** reads **certificate trust**, and box **2a** reads **GP**.
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
### Active Directory
@ -284,11 +286,11 @@ Review the trust type portion of this section if box **4d** on your planning wor
Public key infrastructure prerequisites already exist in your planning worksheet. These conditions are the minimum requirements for any hybrid or on-premises deployment. Additional conditions may be needed based on your trust type.
If box **1a** on your planning worksheet reads **cloud only**, ignore the public key infrastructure section of your planning worksheet. Cloud only deployments do not use a public key infrastructure.
If box **1a** on your planning worksheet reads **cloud only**, ignore the public key infrastructure section of your planning worksheet. Cloud only deployments don't use a public key infrastructure.
If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. Key trust doesn't require any change in public key infrastructure, skip this part and go to **Cloud** section.
The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
The registration authority only relates to certificate trust deployments and the management used for domain and nondomain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances:
@ -321,9 +323,9 @@ Nearly all deployments of Windows Hello for Business require an Azure account.
If box **1a** on your planning worksheet reads **cloud only** or **hybrid**, write **Yes** in boxes **6a** and **6b** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, and box **1f** reads **AD FS with third party**, write **No** in box **6a** on your planning worksheet. Otherwise, write **Yes** in box **6a** as you need an Azure account for per-consumption MFA billing. Write **No** in box **6b** on your planning worksheet—on-premises deployments do not use the cloud directory.
If box **1a** on your planning worksheet reads **on-premises**, and box **1f** reads **AD FS with third party**, write **No** in box **6a** on your planning worksheet. Otherwise, write **Yes** in box **6a** as you need an Azure account for per-consumption MFA billing. Write **No** in box **6b** on your planning worksheet—on-premises deployments don't use the cloud directory.
Windows Hello for Business does not require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
Windows Hello for Business doesn't require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
If box **1a** on your planning worksheet reads **on-premises**, write **No** in box **6c** on your planning worksheet.
@ -331,7 +333,7 @@ If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads *
If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, a Microsoft Entra ID P1 or P2 feature.
Modern managed devices do not require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
Modern managed devices don't require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
If boxes **2a** or **2b** read **modern management** and you want devices to automatically enroll in your modern management software, write **Yes** in box **6c** on your planning worksheet. Otherwise, write **No** in box **6c**.

0
windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset-applications-expanded.png → windows/security/identity-protection/hello-for-business/images/pin-reset/pin-reset-applications-expanded.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 159 KiB

After

Width:  |  Height:  |  Size: 159 KiB

0
windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset-applications.png → windows/security/identity-protection/hello-for-business/images/pin-reset/pin-reset-applications.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 133 KiB

After

Width:  |  Height:  |  Size: 133 KiB

0
windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset-client-prompt.png → windows/security/identity-protection/hello-for-business/images/pin-reset/pin-reset-client-prompt.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 58 KiB

After

Width:  |  Height:  |  Size: 58 KiB

0
windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset-service-prompt-2.png → windows/security/identity-protection/hello-for-business/images/pin-reset/pin-reset-service-prompt-2.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 50 KiB

After

Width:  |  Height:  |  Size: 50 KiB

0
windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset-service-prompt.png → windows/security/identity-protection/hello-for-business/images/pin-reset/pin-reset-service-prompt.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 52 KiB

After

Width:  |  Height:  |  Size: 52 KiB

BIN
windows/security/identity-protection/hello-for-business/images/pinreset/pin-reset.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.0 MiB

BIN
windows/security/identity-protection/hello-for-business/images/plan/dc-chart1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.1 KiB

BIN
windows/security/identity-protection/hello-for-business/images/plan/dc-chart2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.1 KiB

BIN
windows/security/identity-protection/hello-for-business/images/plan/dc-chart3.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.3 KiB

BIN
windows/security/identity-protection/hello-for-business/images/plan/dc-chart4.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.3 KiB

BIN
windows/security/identity-protection/hello-for-business/images/plan/dc-chart5.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.3 KiB

42
windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md → windows/security/identity-protection/hello-for-business/pin-reset.md
View File

@ -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 alt-text="Anmimation showing the PIN reset user experience from the lock screen."]
For Microsoft Entra hybrid joined devices:

4
windows/security/identity-protection/hello-for-business/toc.yml
View File

@ -94,8 +94,6 @@ items:
href: hello-cert-trust-validate-deploy-mfa.md
- name: Configure Windows Hello for Business policy settings
href: hello-cert-trust-policy-settings.md
- name: Planning for Domain Controller load
href: hello-adequate-domain-controllers.md
- name: How-to Guides
items:
- name: Prepare people to use Windows Hello
@ -107,7 +105,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

35
windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
View File

@ -1,13 +1,13 @@
---
title: How to use Single Sign-On (SSO) over VPN and Wi-Fi connections
description: Explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections.
ms.date: 08/03/2023
title: How to use single sign-on (SSO) over VPN and Wi-Fi connections
description: Explains requirements to enable single sign-on (SSO) to on-premises domain resources over WiFi or VPN connections.
ms.date: 12/12/2023
ms.topic: how-to
---
# How to use Single Sign-On (SSO) over VPN and Wi-Fi connections
# How to use single sign-on (SSO) over VPN and Wi-Fi connections
This article explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over Wi-Fi or VPN connections. The following scenarios are typically used:
This article explains requirements to enable single sign-on (SSO) to on-premises domain resources over Wi-Fi or VPN connections. The following scenarios are typically used:
- Connecting to a network using Wi-Fi or VPN
- Use credentials for Wi-Fi or VPN authentication to also authenticate requests to access domain resources, without being prompted for domain credentials
@ -21,7 +21,7 @@ The credentials that are used for the connection authentication are placed in *C
The credentials are placed in Credential Manager as a *session credential*:
- A *session credential* implies that it is valid for the current user session
- A *session credential* implies that it's valid for the current user session
- The credentials are cleaned up when the Wi-Fi or VPN connection is disconnected
> [!NOTE]
@ -30,22 +30,22 @@ The credentials are placed in Credential Manager as a *session credential*:
For example, if someone using Microsoft Edge tries to access a domain resource, Microsoft Edge has the right Enterprise Authentication capability. This allows [WinInet](/windows/win32/wininet/wininet-reference) to release the credentials that it gets from Credential Manager to the SSP that is requesting it.
For more information about the Enterprise Authentication capability, see [App capability declarations](/windows/uwp/packaging/app-capability-declarations).
The local security authority will look at the device application to determine if it has the right capability. This includes items such as a Universal Windows Platform (UWP) application.
The local security authority looks at the device application to determine if it has the right capability. This includes items such as a Universal Windows Platform (UWP) application.
If the app isn't a UWP, it doesn't matter.
But, if the application is a UWP app, it will evaluate at the device capability for Enterprise Authentication.
If it does have that capability and if the resource that you're trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential will be released.
But, if the application is a UWP app, it evaluates at the device capability for Enterprise Authentication.
If it does have that capability and if the resource that you're trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential is released.
This behavior helps prevent credentials from being misused by untrusted third parties.
## Intranet zone
For the Intranet zone, by default it only allows single-label names, such as *http://finance*.
For the Intranet zone, by default it only allows single-label names, such as `http://finance`.
If the resource that needs to be accessed has multiple domain labels, then the workaround is to use the [Registry CSP](/windows/client-management/mdm/registry-csp).
### Setting the ZoneMap
The ZoneMap is controlled using a registry that can be set through MDM.
By default, single-label names such as *http://finance* are already in the intranet zone.
For multi-label names, such as *http://finance.net*, the ZoneMap needs to be updated.
By default, single-label names such as `http://finance` are already in the intranet zone.
For multi-label names, such as `http://finance.net`, the ZoneMap needs to be updated.
## MDM Policy
@ -72,8 +72,8 @@ If the credentials are certificate-based, then the elements in the following tab
| Template element | Configuration |
|------------------|---------------|
| SubjectName | The user's distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
| SubjectAlternativeName | The user's fully qualified UPN where a domain name component of the user's UPN matches the organizations internal domain's DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
| SubjectName | The user's distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName doesn't have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
| SubjectAlternativeName | The user's fully qualified UPN where a domain name component of the user's UPN matches the organizations internal domain's DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName doesn't have the DN required to find the domain controller. |
| Key Storage Provider (KSP) | If the device is joined to Microsoft Entra ID, a discrete SSO certificate is used. |
| EnhancedKeyUsage | One or more of the following EKUs is required: </br><ul><li>Client Authentication (for the VPN)</li><li>EAP Filtering OID (for Windows Hello for Business)</li><li>SmartCardLogon (for Microsoft Entra joined devices)</li></ul>If the domain controllers require smart card EKU either:<ul><li>SmartCardLogon</li><li>id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) </li></ul>Otherwise:</br><ul><li>TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)</li></ul> |
@ -86,9 +86,6 @@ For more information, see [Configure certificate infrastructure for SCEP](/mem/i
You need IP connectivity to a DNS server and domain controller over the network interface so that authentication can succeed as well.
Domain controllers must have appropriate KDC certificates for the client to trust them as domain controllers. Because phones are not domain-joined, the root CA of the KDC's certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store.
Domain controllers must have appropriate KDC certificates for the client to trust them as domain controllers. Because phones aren't domain-joined, the root CA of the KDC's certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store.
Domain controllers must be using certificates based on the updated KDC certificate template Kerberos Authentication.
This requires that all authenticating domain controllers run Windows Server 2016, or you'll need to enable strict KDC validation on domain controllers that run previous versions of Windows Server.
For more information, see [Enabling Strict KDC Validation in Windows Kerberos](https://www.microsoft.com/download/details.aspx?id=6382).
Domain controllers must be using certificates based on the updated *KDC certificate template* Kerberos Authentication.