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

Update Shell Launcher and Assigned Access XSDs for Windows 11 and 10

Browse Source
This commit is contained in:
Paolo Matarazzo
2024-02-26 10:18:36 -05:00
parent d684c2351e
commit f125c544eb
4 changed files with 100 additions and 97 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
windows/configuration/assigned-access/assigned-access-xsd.md
View File

@ -11,7 +11,7 @@ This reference article contains the latest Assigned Access XML schema definition
## Assigned Access XSD
The following is the latest Assigned Access XSD, introduced in Windows 11:
Here's the latest Assigned Access XSD, introduced in Windows 11:
```xml
<xs:schema
@ -212,7 +212,7 @@ The following is the latest Assigned Access XSD, introduced in Windows 11:
## Windows 11, version 22H2 additions
The following is the XSD for Assigned Access features added in Windows 11:
Here's the Assigned Access XSD for the features added in Windows 11:
```xml
<xs:schema
@ -232,7 +232,7 @@ The following is the XSD for Assigned Access features added in Windows 11:
## Windows 11, version 21H2 additions
The following is the XSD for Assigned Access features added in Windows 10, version 21H2:
Here's the Assigned Access XSD for the features added in Windows 10, version 21H2:
```xml
<xs:schema
@ -259,7 +259,7 @@ The following is the XSD for Assigned Access features added in Windows 10, versi
## Windows 10, version 1909 additions
The following is the XSD for Assigned Access features added in Windows 10, version 1909:
Here's the Assigned Access XSD for the features added in Windows 10, version 1909:
```xml
<xs:schema
@ -294,7 +294,7 @@ The following is the XSD for Assigned Access features added in Windows 10, versi
## Windows 10, version 1809 additions
The following is the XSD for Assigned Access features added in Windows 10, version 1809:
Here's the Assigned Access XSD for the features added in Windows 10, version 1809:
```xml
<xs:schema

4
windows/configuration/assigned-access/shell-launcher-xsd.md
View File

@ -11,7 +11,7 @@ This reference article contains the latest Shell Launcher XML schema definition
## Shell Launcher XSD
The following is the latest Shell Launcher XSD:
Here's the latest Shell Launcher XSD, introduced in Windows 11:
```xml
<xs:schema
@ -169,7 +169,7 @@ The following is the latest Shell Launcher XSD:
In Windows 10, version 1903, Shell Launcher introduced the support of both UWP and desktop apps as the custom shell.
The following is the XSD for Shell Launcher features added in Windows 10, version 1903:
Here's the Shell Launcher XSD for the features added in Windows 10, version 1903:
```xml
<xs:schema

129
windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md
View File

@ -1,13 +1,16 @@
---
title: Windows Hello errors during PIN creation
description: When you set up Windows Hello, you may get an error during the Create a work PIN step.
description: Learn about the Windows Hello error codes that might happen during PIN creation.
ms.topic: troubleshooting
ms.date: 01/26/2024
---
# Windows Hello errors during PIN creation
When you set up Windows Hello in Windows client, you may get an error during the **Create a PIN** step. This topic lists some of the error codes with recommendations for mitigating the problem. If you get an error code that is not listed here, contact Microsoft Support.
When you set up Windows Hello in Windows client, you might get an error during the **Create a PIN** step. This article lists some of the error codes with recommendations for mitigating the problem.
> [!IMPORTANT]
> If you get an error code that isn't listed here, contact Microsoft Support.
## Where is the error code?
@ -19,72 +22,72 @@ The following image shows an example of an error during **Create a PIN**.
When a user encounters an error when creating the work PIN, advise the user to try the following steps. Many errors can be mitigated by one of these steps.
1. Try to create the PIN again. Some errors are transient and resolve themselves.
2. Sign out, sign in, and try to create the PIN again.
3. Reboot the device and then try to create the PIN again.
4. Unjoin the device from Microsoft Entra ID, rejoin, and then try to create the PIN again. To unjoin a device, go to **Settings > System > About > Disconnect from organization**.
1. Try to create the PIN again. Some errors are transient and resolve themselves
1. Sign out, sign in, and try to create the PIN again
1. Reboot the device and then try to create the PIN again
1. Unjoin the device from Microsoft Entra ID, rejoin, and then try to create the PIN again. To unjoin a device, go to **Settings > System > About > Disconnect from organization**
If the error occurs again, check the error code against the following table to see if there is another mitigation for that error. When no mitigation is listed in the table, contact Microsoft Support for assistance.
If the error occurs again, check the error code against the following table to see if there's another mitigation for that error. When no mitigation is listed in the table, contact Microsoft Support for assistance.
| Hex | Cause | Mitigation |
| :--------- | :----------------------------------------------------------------- | :------------------------------------------ |
| 0x80090005 | NTE_BAD_DATA | Unjoin the device from Microsoft Entra ID and rejoin. |
| 0x8009000F | The container or key already exists. | Unjoin the device from Microsoft Entra ID and rejoin. |
| 0x80090011 | The container or key was not found. | Unjoin the device from Microsoft Entra ID and rejoin. |
| 0x80090029 | TPM is not set up. | Sign on with an administrator account. Select **Start**, type `tpm.msc`, and select **tpm.msc Microsoft Common Console Document**. In the **Actions** pane, select **Prepare the TPM**. |
| 0x8009002A | NTE_NO_MEMORY | Close programs which are taking up memory and try again. |
| 0x80090031 | NTE_AUTHENTICATION_IGNORED | Reboot the device. If the error occurs again after rebooting, [reset the TPM](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd851452(v=ws.11)) or run [Clear-TPM](/powershell/module/trustedplatformmodule/clear-tpm). |
| 0x80090035 | Policy requires TPM and the device does not have TPM. | Change the Windows Hello for Business policy to not require a TPM. |
| 0x80090036 | User canceled an interactive dialog. | User will be asked to try again. |
| 0x801C0003 | User is not authorized to enroll. | Check if the user has permission to perform the operation​. |
| 0x801C000E | Registration quota reached. | Unjoin some other device that is currently joined using the same account or [increase the maximum number of devices per user](/azure/active-directory/devices/device-management-azure-portal). |
| 0x801C000F | Operation successful, but the device requires a reboot. | Reboot the device. |
| 0x801C0010 | The AIK certificate is not valid or trusted. | Sign out and then sign in again. |
| 0x801C0011 | The attestation statement of the transport key is invalid. | Sign out and then sign in again. |
| 0x801C0012 | Discovery request is not in a valid format. | Sign out and then sign in again. |
| Hex | Cause | Mitigation |
|:-|:-|:-|
| 0x80090005 | NTE_BAD_DATA | Unjoin the device from Microsoft Entra ID and rejoin. |
| 0x8009000F | The container or key already exists. | Unjoin the device from Microsoft Entra ID and rejoin. |
| 0x80090011 | The container or key wasn't found. | Unjoin the device from Microsoft Entra ID and rejoin. |
| 0x80090029 | TPM isn't set up. | Sign on with an administrator account. Select **Start**, type `tpm.msc`, and select **tpm.msc Microsoft Common Console Document**. In the **Actions** pane, select **Prepare the TPM**. |
| 0x8009002A | NTE_NO_MEMORY | Close programs, which are taking up memory and try again. |
| 0x80090031 | NTE_AUTHENTICATION_IGNORED | Reboot the device. If the error occurs again after rebooting, [reset the TPM](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd851452(v=ws.11)) or run [Clear-TPM](/powershell/module/trustedplatformmodule/clear-tpm). |
| 0x80090035 | Policy requires TPM and the device doesn't have TPM. | Change the Windows Hello for Business policy to not require a TPM. |
| 0x80090036 | User canceled an interactive dialog. | User will be asked to try again. |
| 0x801C0003 | User isn't authorized to enroll. | Check if the user has permission to perform the operation​. |
| 0x801C000E | Registration quota reached. | Unjoin some other device that is currently joined using the same account or [increase the maximum number of devices per user](/azure/active-directory/devices/device-management-azure-portal). |
| 0x801C000F | Operation successful, but the device requires a reboot. | Reboot the device. |
| 0x801C0010 | The AIK certificate isn't valid or trusted. | Sign out and then sign in again. |
| 0x801C0011 | The attestation statement of the transport key is invalid. | Sign out and then sign in again. |
| 0x801C0012 | Discovery request isn't in a valid format. | Sign out and then sign in again. |
| 0x801C0015 | The device is required to be joined to an Active Directory domain. | Join the device to an Active Directory domain. |
| 0x801C0016 | The federation provider configuration is empty | Go to http://clientconfig.microsoftonline-p.net/FPURL.xml and verify that the file is not empty. |
| 0x801C0017 | The federation provider domain is empty | Go to http://clientconfig.microsoftonline-p.net/FPURL.xml and verify that the FPDOMAINNAME element is not empty. |
| 0x801C0018 | The federation provider client configuration URL is empty | Go to http://clientconfig.microsoftonline-p.net/FPURL.xml and verify that the CLIENTCONFIG element contains a valid URL. |
| 0x801C03E9 | Server response message is invalid | Sign out and then sign in again. |
| 0x801C03EA | Server failed to authorize user or device. | Check if the token is valid and user has permission to register Windows Hello for Business keys. |
| 0x801C03EB | Server response http status is not valid | Sign out and then sign in again. |
| 0x801C03EC | Unhandled exception from server. | sign out and then sign in again. |
| 0x801C03ED | Multi-factor authentication is required for a 'ProvisionKey' operation, but was not performed. <br><br> -or- <br><br> Token was not found in the Authorization header. <br><br> -or- <br><br> Failed to read one or more objects. <br><br> -or- <br><br> The request sent to the server was invalid. <br><br> -or- <br><br> User does not have permissions to join to Microsoft Entra ID. | Sign out and then sign in again. If that doesn't resolve the issue, unjoin the device from Azure AD and rejoin. <br> Allow user(s) to join to Microsoft Entra ID under Microsoft Entra Device settings.
| 0x801C03EE | Attestation failed. | Sign out and then sign in again. |
| 0x801C03EF | The AIK certificate is no longer valid. | Sign out and then sign in again. |
| 0x801C03F2 | Windows Hello key registration failed. | ERROR_BAD_DIRECTORY_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in Microsoft Entra ID and the Primary SMTP address are the same in the proxy address.
| 0x801C044D | Authorization token does not contain device ID. | Unjoin the device from Microsoft Entra ID and rejoin. |
| | Unable to obtain user token. | Sign out and then sign in again. Check network and credentials. |
| 0x801C044E | Failed to receive user credentials input. | Sign out and then sign in again. |
| 0x801C0451 | User token switch account. | Delete the Web Account Manager token broker files located in `%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts\*.*\` and reboot.|
| 0xC00000BB | Your PIN or this option is temporarily unavailable. | The destination domain controller doesn't support the login method. Most often the KDC service doesn't have the proper certificate to support the login. Another common cause can be the client cannot verify the KDC certificate CRL. Use a different login method.|
| 0x801C0016 | The federation provider configuration is empty | Go to http://clientconfig.microsoftonline-p.net/FPURL.xml and verify that the file isn't empty. |
| 0x801C0017 | The federation provider domain is empty | Go to http://clientconfig.microsoftonline-p.net/FPURL.xml and verify that the FPDOMAINNAME element isn't empty. |
| 0x801C0018 | The federation provider client configuration URL is empty | Go to http://clientconfig.microsoftonline-p.net/FPURL.xml and verify that the CLIENTCONFIG element contains a valid URL. |
| 0x801C03E9 | Server response message is invalid | Sign out and then sign in again. |
| 0x801C03EA | Server failed to authorize user or device. | Check if the token is valid and user has permission to register Windows Hello for Business keys. |
| 0x801C03EB | Server response http status isn't valid | Sign out and then sign in again. |
| 0x801C03EC | Unhandled exception from server. | sign out and then sign in again. |
| 0x801C03ED | Multi-factor authentication is required for a 'ProvisionKey' operation, but wasn't performed. <br><br> -or- <br><br> Token wasn't found in the Authorization header. <br><br> -or- <br><br> Failed to read one or more objects. <br><br> -or- <br><br> The request sent to the server was invalid. <br><br> -or- <br><br> User doesn't have permissions to join to Microsoft Entra ID. | Sign out and then sign in again. If that doesn't resolve the issue, unjoin the device from Azure AD and rejoin. <br> Allow user(s) to join to Microsoft Entra ID under Microsoft Entra Device settings. |
| 0x801C03EE | Attestation failed. | Sign out and then sign in again. |
| 0x801C03EF | The AIK certificate is no longer valid. | Sign out and then sign in again. |
| 0x801C03F2 | Windows Hello key registration failed. | ERROR_BAD_DIRECTORY_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in Microsoft Entra ID and the Primary SMTP address are the same in the proxy address. |
| 0x801C044D | Authorization token doesn't contain device ID. | Unjoin the device from Microsoft Entra ID and rejoin. |
| | Unable to obtain user token. | Sign out and then sign in again. Check network and credentials. |
| 0x801C044E | Failed to receive user credentials input. | Sign out and then sign in again. |
| 0x801C0451 | User token switch account. | Delete the Web Account Manager token broker files located in `%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts\*.*\` and reboot. |
| 0xC00000BB | Your PIN or this option is temporarily unavailable. | The destination domain controller doesn't support the login method. Most often the KDC service doesn't have the proper certificate to support the login. Another common cause can be the client cannot verify the KDC certificate CRL. Use a different login method. |
## Errors with unknown mitigation
For errors listed in this table, contact Microsoft Support for assistance.
| Hex | Cause |
|-------------|---------|
| 0x80070057 | Invalid parameter or argument is passed. |
| 0X80072F0C | Unknown |
| 0x80072F8F | A mismatch happens between the system's clock and the activation server's clock when attempting to activate Windows.|
| 0x80090010 | NTE_PERM |
| 0x80090020 | NTE_FAIL |
| 0x80090027 | Caller provided a wrong parameter. If non-Microsoft code receives this error, they must change their code. |
| 0x8009002D | NTE_INTERNAL_ERROR |
| 0x801C0001 | ADRS server response is not in a valid format. |
| 0x801C0002 | Server failed to authenticate the user. |
| 0x801C0006 | Unhandled exception from server. |
| 0x801C000B | Redirection is needed and redirected location is not a well known server. |
| 0x801C000C | Discovery failed. |
| 0x801C0013 | Tenant ID is not found in the token. |
| 0x801C0014 | User SID is not found in the token. |
| 0x801C0019 | ​The federation provider client configuration is empty |
| 0x801C001A | The DRS endpoint in the federation provider client configuration is empty. |
| 0x801C001B | ​The device certificate is not found. |
| 0x801C03F0 | ​There is no key registered for the user. |
| 0x801C03F1 | ​There is no UPN in the token. |
| ​0x801C044C | There is no core window for the current thread. |
| 0x801c004D | DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is unable to find the default WAM account to use to request Microsoft Entra token for provisioning. Unable to enroll a device to use a PIN for login. |
| 0xCAA30193 | HTTP 403 Request Forbidden: it means request left the device, however either Server, proxy or firewall generated this response. |
| Hex | Cause |
|--|--|
| 0x80070057 | Invalid parameter or argument is passed. |
| 0X80072F0C | Unknown |
| 0x80072F8F | A mismatch happens between the system's clock and the activation server's clock when attempting to activate Windows. |
| 0x80090010 | NTE_PERM |
| 0x80090020 | NTE_FAIL |
| 0x80090027 | Caller provided a wrong parameter. If non-Microsoft code receives this error, they must change their code. |
| 0x8009002D | NTE_INTERNAL_ERROR |
| 0x801C0001 | ADRS server response isn't in a valid format. |
| 0x801C0002 | Server failed to authenticate the user. |
| 0x801C0006 | Unhandled exception from server. |
| 0x801C000B | Redirection is needed and redirected location isn't a well known server. |
| 0x801C000C | Discovery failed. |
| 0x801C0013 | Tenant ID isn't found in the token. |
| 0x801C0014 | User SID isn't found in the token. |
| 0x801C0019 | ​The federation provider client configuration is empty |
| 0x801C001A | The DRS endpoint in the federation provider client configuration is empty. |
| 0x801C001B | ​The device certificate isn't found. |
| 0x801C03F0 | ​There's no key registered for the user. |
| 0x801C03F1 | ​There's no UPN in the token. |
| ​0x801C044C | There's no core window for the current thread. |
| 0x801c004D | DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is unable to find the default WAM account to use to request Microsoft Entra token for provisioning. Unable to enroll a device to use a PIN for login. |
| 0xCAA30193 | HTTP 403 Request Forbidden: it means request left the device, however either Server, proxy or firewall generated this response. |

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

@ -1,6 +1,6 @@
---
title: How Windows Hello for Business provisioning works
description: Explore the provisioning flows for Windows Hello for Business, from within a variety of environments.
description: Learn about the provisioning flows for Windows Hello for Business.
ms.date: 01/03/2024
ms.topic: reference
appliesto:
@ -8,7 +8,7 @@ appliesto:
# 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:
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:
- How the device is joined to Microsoft Entra ID
- The Windows Hello for Business deployment type
@ -23,8 +23,8 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
| Phase | Description |
|:-:|:-|
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| 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. |
## Provisioning for Microsoft Entra joined devices with federated authentication
@ -33,9 +33,9 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
| Phase | Description |
|:-:|:-|
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns key ID to the application, which signals the end of user provisioning and the application exits. |
| 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. |
## Provisioning in a cloud Kerberos trust deployment model with managed authentication
@ -43,9 +43,9 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
| Phase | Description |
|:-:|:-|
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application, which signals the end of user provisioning and the application exits. |
| 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.
@ -56,9 +56,9 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
| Phase | Description |
|:-:|:-|
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application, which signals the end of user provisioning and the application exits. |
| 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]
@ -70,16 +70,16 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
| Phase | Description |
|:-|:-|
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service (or a non-Microsoft 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. |
| 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 non-Microsoft MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID and a key receipt to the application, which represents the end of user key registration. |
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys. |
| E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> If the public key in the certificate isn't found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. |
| F | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. |
| G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning. |
| 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 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.
> 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.
## Provisioning in an on-premises key trust deployment model
@ -87,9 +87,9 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
| 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. Microsoft Entra multifactor authentication server (or a non-Microsoft 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.|
|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 non-Microsoft 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.|
## Provisioning in an on-premises certificate trust deployment model
@ -97,10 +97,10 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
| 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. Microsoft Entra multifactor authentication server (or a non-Microsoft 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.|
|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 non-Microsoft 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.|
|G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning.|