deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #6811 from MicrosoftDocs/nimishasatapathy-6244024-windows

Browse Source 
Update hello-faq.yml
This commit is contained in:
Angela Fleischmann 2022-08-09 15:55:09 -06:00 committed by GitHub
commit 475a50987e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 164 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
windows/security/identity-protection/hello-for-business/hello-faq.yml
View File

@ -31,6 +31,7 @@ sections:
answer: |
Windows Hello for Business cloud trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid Cloud Trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust).
- question: What about virtual smart cards?
answer: |
Windows Hello for Business is the modern, two-factor credential for Windows 10. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using Windows 10 and virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows 10 deployments use Windows Hello for Business. Virtual smart cards remain supported for Windows 7 and Windows 8.
@ -43,6 +44,7 @@ sections:
answer: |
Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.
- question: Can I deploy Windows Hello for Business by using Microsoft Endpoint Configuration Manager?
answer: |
Windows Hello for Business deployments using Configuration Manager should follow the hybrid deployment model that uses Active Directory Federation Services. Starting in Configuration Manager version 1910, certificate-based authentication with Windows Hello for Business settings isn't supported. Key-based authentication is still valid with Configuration Manager. For more information, see [Windows Hello for Business settings in Configuration Manager](/configmgr/protect/deploy-use/windows-hello-for-business-settings).
@ -57,9 +59,8 @@ sections:
- question: How can a PIN be more secure than a password?
answer: |
The Windows Hello for Business PIN isn't a symmetric key, whereas a password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
The statement "PIN is stronger than Password" isn't directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multi-factor Unlock](feature-multifactor-unlock.md) feature.
When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
- question: How does Windows Hello for Business work with Azure AD registered devices?
answer: |
@ -123,9 +124,9 @@ sections:
- question: What's the difference between non-destructive and destructive PIN reset?
answer: |
Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 Enterprise and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 Enterprise can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid deployments, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid Azure Active Directory joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
- question: |
Which is better or more secure, key trust or certificate trust?
@ -150,6 +151,30 @@ sections:
answer: |
Windows Hello for Business is two-factor authentication based on the observed authentication factors of: something you have, something you know, and something that's part of you. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
- question: Where is Windows Hello biometrics data stored?
answer: |
When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn’t roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details see [Windows Hello biometrics in the enterprise](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored).
- question: What is the format used to store Windows Hello biometrics data on the device?
answer: |
Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (e.g., face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it’s stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash.
- question: Who has access on Windows Hello biometrics data?
answer: |
Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
- question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication?
answer: |
Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method (e.g. pin). Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start** > **Settings** > **Accounts** > **Sign-in** options. Or just click on **Go to Sign-in options**. To enroll into Windows Hello, user can go to **Start** > **Settings** > **Accounts** > **Sign-in** options, select the Windows Hello method that they want to set up, and then select **Set up**. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can by policy request users to enroll into Windows Hello during autopilot or during initial setup of the device. Admins can disallow users to enroll into biometrics via Windows hello for business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
- question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication?
answer: |
To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start** > **Settings** > **Accounts** > **Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will unenroll the user from Windows Hello biometrics auth and will also delete the associated biometrics template database file. For more details see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy).
- question: What about any diagnostic data coming out when WHFB is enabled?
answer: |
To help us keep things working properly, to help detect and prevent fraud, and to continue improving Windows Hello, we collect diagnostic data about how people use Windows Hello. For example, data about whether people sign in with their face, iris, fingerprint, or PIN; the number of times they use it; and whether it works or not is all valuable information that helps us build a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/en-us/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319).
- question: What are the biometric requirements for Windows Hello for Business?
answer: |
Read [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information.
@ -206,7 +231,7 @@ sections:
answer: |
Wherever possible, Windows Hello for Business takes advantage of Trusted Platform Module (TPM) 2.0 hardware to generate and protect keys. However, Windows Hello and Windows Hello for Business don't require a TPM. Administrators can choose to allow key operations in software.
Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they'll need to use MFA to re-authenticate to the IDP before the IDP allows them to re-register).
Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against various known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they'll need to use MFA to reauthenticate to the IDP before the IDP allows them to re-register).
- question: Can Windows Hello for Business work in air-gapped environments?
answer: |
@ -225,7 +250,7 @@ sections:
| [[MS-KPP]: Key Provisioning Protocol](/openspecs/windows_protocols/ms-kpp/25ff7bd8-50e3-4769-af23-bcfd0b4d4567) | Specifies the Key Provisioning Protocol, which defines a mechanism for a client to register a set of cryptographic keys on a user and device pair. |
| [[MS-OAPX]: OAuth 2.0 Protocol Extensions](/openspecs/windows_protocols/ms-oapx/7612efd4-f4c8-43c3-aed6-f5c5ce359da2)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and log in hints. |
| [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](/openspecs/windows_protocols/ms-oapxbc/2f7d8875-0383-4058-956d-2fb216b44706) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (the OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. |
| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define additional claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define additional provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. |
| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define other claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define more provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. |
- question: Does Windows Hello for Business work with Mac and Linux clients?
answer: |
@ -235,3 +260,4 @@ sections:
- question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients?
answer: |
No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD.

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

@ -1,6 +1,6 @@
---
title: Pin Reset
description: Learn how Microsoft PIN reset services enables you to help users recover who have forgotten their PIN.
description: Learn how Microsoft PIN reset services enable you to help users recover who have forgotten their PIN.
ms.prod: m365-security
author: GitPrakhar13
ms.author: prsriva
@ -26,34 +26,45 @@ There are two forms of PIN reset:
- **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.
## Using PIN reset
There are two forms of PIN reset called destructive and non-destructive. Destructive PIN reset is the default and doesn't require configuration. During a destructive PIN reset, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned. For non-destructive PIN reset, 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.
**Requirements**
- Reset from settings - Windows 10, version 1703 or later, Windows 11
- Reset above Lock - Windows 10, version 1709 or later, Windows 11
Destructive and non-destructive PIN reset 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 do not have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen in the PIN credential provider.
>[!IMPORTANT]
>For hybrid Azure AD-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.
### Reset PIN from Settings
1. Sign-in to Windows 10 using an alternate credential
1. Open **Settings**, select **Accounts** > **Sign-in options**
1. Select **PIN (Windows Hello)** > **I forgot my PIN** and follow the instructions
1. Sign-in to Windows 10 using an alternate credential.
1. Open **Settings**, select **Accounts** > **Sign-in options**.
1. Select **PIN (Windows Hello)** > **I forgot my PIN** and follow the instructions.
### Reset PIN above the Lock Screen
For Azure AD-joined devices:
1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon
1. Select **I forgot my PIN** from the PIN credential provider
1. Select an authentication option from the list of presented options. This list will be based on the different authentication methods enabled in your tenant (e.g., Password, PIN, Security key)
1. Follow the instructions provided by the provisioning process
1. When finished, unlock your desktop using your newly created PIN
1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon.
1. Select **I forgot my PIN** from the PIN credential provider.
1. Select an authentication option from the list of presented options. This list will be based on the different authentication methods enabled in your tenant (e.g., Password, PIN, Security key).
1. Follow the instructions provided by the provisioning process.
1. When finished, unlock your desktop using your newly created PIN.
For Hybrid Azure AD-joined devices:
1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon
1. Select **I forgot my PIN** from the PIN credential provider
1. Enter your password and press enter
1. Follow the instructions provided by the provisioning process
1. When finished, unlock your desktop using your newly created PIN
1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon.
1. Select **I forgot my PIN** from the PIN credential provider.
1. Enter your password and press enter.
1. Follow the instructions provided by the provisioning process.
1. When finished, unlock your desktop using your newly created PIN.
> [!NOTE]
> Key trust on hybrid Azure AD-joined devices does not support destructive PIN reset 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. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work.
@ -65,16 +76,36 @@ You may find that PIN reset from settings only works post login, and that the "l
**Requirements:**
- Azure Active Directory
- Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903.
- Hybrid Windows Hello for Business deployment
- Azure AD registered, Azure AD joined, and Hybrid Azure AD joined
When non-destructive PIN reset is enabled on a client, a 256-bit AES key is generated locally and 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 Azure AD, 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 is 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.
>[!IMPORTANT]
> The Microsoft PIN Reset service only works with **Enterprise Edition** for Windows 10, version 1709 to 1809 and later, and Windows 11. The feature works with **Enterprise Edition** and **Pro** edition with Windows 10, version 1903 and later, Windows 11.
> The Microsoft PIN Reset service is not currently available in Azure Government.
### Summary
|Category|Destructive PIN Reset|Non-Destructive PIN Reset|
|--- |--- |--- |
|**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. For more information on how to deploy the Microsoft PIN reset service and client policy, see [Connect Azure Active Directory with the PIN reset service](#connect-azure-active-directory-with-the-pin-reset-service). 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.|
|**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.|
|**Azure Active Directory Joined**|Cert Trust, Key Trust, and Cloud Trust|Cert Trust, Key Trust, and Cloud Trust|
|**Hybrid Azure Active Directory Joined**|Cert Trust and Cloud Trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this 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 Trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
|**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it is only available for Hybrid Azure Active Directory Joined and Azure Active Directory 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 On-board the Microsoft PIN reset service to respective Azure Active Directory tenant Configure Windows devices to use PIN reset using Group *Policy\MDM*.|
|**MSA/Enterprise**|MSA and Enterprise|Enterprise only.|
### Onboarding the Microsoft PIN reset service to your Intune tenant
> The **Microsoft PIN Reset Service** is not currently available in Azure Government.
### Enable the Microsoft PIN Reset Service in your Azure AD tenant
Before you can remotely reset PINs, you must register two applications in your Azure Active Directory tenant:
@ -84,21 +115,21 @@ Before you can remotely reset PINs, you must register two applications in your A
#### Connect Azure Active Directory with the PIN Reset Service
1. Go to the [Microsoft PIN Reset Service Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant
1. After you have logged in, select **Accept** to give consent to the **PIN Reset Service** to access your organization
1. Go to the [Microsoft PIN Reset Service Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant.
1. After you have logged in, select **Accept** to give consent to the **PIN Reset Service** to access your organization.
![PIN reset service application in Azure.](images/pinreset/pin-reset-service-prompt.png)
#### Connect Azure Active Directory with the PIN Reset Client
1. Go to the [Microsoft PIN Reset Client Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant
1. After you have logged in, select **Accept** to give consent for the **PIN Reset Client** to access your organization
1. Go to the [Microsoft PIN Reset Client Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant.
1. After you have logged in, select **Accept** to give consent for the **PIN Reset Client** to access your organization.
![PIN reset client application in Azure.](images/pinreset/pin-reset-client-prompt.png)
#### Confirm that the two PIN Reset service principals are registered in your tenant
1. Sign in to the [Microsoft Entra Manager admin center](https://entra.microsoft.com)
1. Select **Azure Active Directory** > **Applications** > **Enterprise applications**
1. Search by application name "Microsoft PIN" and both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** will show up in the list
1. Sign in to the [Microsoft Entra Manager admin center](https://entra.microsoft.com).
1. Select **Azure Active Directory** > **Applications** > **Enterprise applications**.
1. Search by application name "Microsoft PIN" and both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** will show up 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":::
### Enable PIN Recovery on your devices
@ -109,39 +140,39 @@ Before you can remotely reset PINs, your devices must be configured to enable PI
You can configure Windows devices to use the **Microsoft PIN Reset Service** using Microsoft Intune.
1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com)
1. Select **Devices** > **Configuration profiles** > **Create profile**
1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com).
1. Select **Devices** > **Configuration profiles** > **Create profile**.
1. Enter the following properties:
- **Platform**: Select **Windows 10 and later**
- **Profile type**: Select **Settings catalog**
1. Select **Create**
- **Platform**: Select **Windows 10 and later**.
- **Profile type**: Select **Settings catalog**.
1. Select **Create**.
1. In **Basics**, enter the following properties:
- **Name**: Enter a descriptive name for the profile
- **Description**: Enter a description for the profile. This setting is optional, but recommended
1. Select **Next**
1. In **Configuration settings**, select **Add settings**
1. In the settings picker, select **Windows Hello For Business** > **Enable Pin Recovery**
1. Configure **Enable Pin Recovery** to **true**
1. Select **Next**
1. In **Scope tags**, assign any applicable tags (optional)
1. Select **Next**
1. In **Assignments**, select the security groups that will receive the policy
1. Select **Next**
1. In **Review + create**, review your settings and select **Create**
- **Name**: Enter a descriptive name for the profile.
- **Description**: Enter a description for the profile. This setting is optional, but recommended.
1. Select **Next**.
1. In **Configuration settings**, select **Add settings**.
1. In the settings picker, select **Windows Hello For Business** > **Enable Pin Recovery**.
1. Configure **Enable Pin Recovery** to **true**.
1. Select **Next**.
1. In **Scope tags**, assign any applicable tags (optional).
1. Select **Next**.
1. In **Assignments**, select the security groups that will receive the policy.
1. Select **Next**.
1. In **Review + create**, review your settings and select **Create**.
>[!NOTE]
> You can also configure PIN recovery from the **Endpoint security** blade:
> 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com)
> 1. Select **Endpoint security** > **Account protection** > **Create Policy**
> 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com).
> 1. Select **Endpoint security** > **Account protection** > **Create Policy**.
#### [✅ **GPO**](#tab/gpo)
You can configure Windows devices to use the **Microsoft PIN Reset Service** using a Group Policy Object (GPO).
1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer accounts in Active Directory
1. Edit the Group Policy object from Step 1
1. Enable the **Use PIN Recovery** policy setting located under **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**
1. Close the Group Policy Management Editor to save the Group Policy object
1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer accounts in Active Directory.
1. Edit the Group Policy object from Step 1.
1. Enable the **Use PIN Recovery** policy setting located under **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**.
1. Close the Group Policy Management Editor to save the Group Policy object.
#### [✅ **CSP**](#tab/csp)
@ -198,6 +229,44 @@ The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/a
+----------------------------------------------------------------------+
```
## Configure Web Sign-in Allowed URLs for Third Party Identity Providers on Azure AD Joined Devices
**Applies to:**
- Windows 10, version 1803 or later
- Windows 11
- Azure AD joined
The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that are allowed to be navigated to during PIN reset flows on Azure AD-joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, this policy should be set to ensure that authentication pages from that identity provider can be used during Azure AD joined PIN reset.
### Configuring Policy Using Intune
1. Sign-in to [Endpoint Manager admin center](https://endpoint.microsoft.com/) using a Global administrator account.
1. Click **Devices**. Click **Configuration profiles**. Click **Create profile**.
1. For Platform select **Windows 10 and later** and for Profile type select **Templates**. In the list of templates that is loaded, select **Custom** and click Create.
1. In the **Name** field type **Web Sign In Allowed URLs** and optionally provide a description for the configuration. Click Next.
1. On the Configuration settings page, click **Add** to add a custom OMA-URI setting. Provide the following information for the custom settings:
- **Name:** Web Sign In Allowed URLs
- **Description:** (Optional) List of domains that are allowed during PIN reset flows.
- **OMA-URI:** ./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls
- **Data type:** String
- **Value**: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be _signin.contoso.com;portal.contoso.com_ (without quotation marks)
:::image type="content" alt-text="Custom Configuration for ConfigureWebSignInAllowedUrls policy." source="images/pinreset/allowlist.png" lightbox="images/pinreset/allowlist.png":::
1. Click the **Save** button to save the custom configuration.
1. On the Assignments page, use the Included groups and Excluded groups sections to define the groups of users or devices that should receive this policy. Once you have completed configuring groups click the Next button.
1. On the Applicability rules page, click **Next**.
1. Review the configuration that is shown on the Review + create page to make sure that it is accurate. Click create to save the profile and apply it to the configured groups.
### Configure Web Sign-in Allowed URLs for Third Party Identity Providers on Azure AD Joined Devices
The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that can be reached during PIN reset flows on Azure AD-joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, this policy should be set to ensure that authentication pages from that identity provider can be used during Azure AD joined PIN reset.
@ -205,28 +274,29 @@ The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-au
#### Configure Web Sign-in Allowed URLs using Microsoft Intune
1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431)
1. Select **Devices** > **Configuration profiles** > **Create profile**
1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** > **Configuration profiles** > **Create profile**.
1. Enter the following properties:
- **Platform**: Select **Windows 10 and later**
- **Profile type**: Select **Templates**
- In the list of templates that is loaded, select **Custom** > **Create**
- **Platform**: Select **Windows 10 and later**.
- **Profile type**: Select **Templates**.
- In the list of templates that is loaded, select **Custom** > **Create**.
1. In **Basics**, enter the following properties:
- **Name**: Enter a descriptive name for the profile
- **Description**: Enter a description for the profile. This setting is optional, but recommended
1. Select **Next**
- **Name**: Enter a descriptive name for the profile.
- **Description**: Enter a description for the profile. This setting is optional, but recommended.
1. Select **Next**.
1. In **Configuration settings**, select **Add** and enter the following settings:
- Name: **Web Sign In Allowed URLs**
- Description: **(Optional) List of domains that are allowed during PIN reset flows**
- OMA-URI: `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls`
- Data type: **String**
- Value: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be **signin.contoso.com;portal.contoso.com** (without quotation marks)
- Value: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be **signin.contoso.com;portal.contoso.com** (without quotation marks).
:::image type="content" alt-text="Custom Configuration for ConfigureWebSignInAllowedUrls policy." source="images/pinreset/allowlist.png" lightbox="images/pinreset/allowlist-expanded.png":::
1. Select **Save** > **Next**
1. In **Assignments**, select the security groups that will receive the policy
1. Select **Next**
1. In **Applicability Rules**, select **Next**
1. In **Review + create**, review your settings and select **Create**
1. Select **Save** > **Next**.
1. In **Assignments**, select the security groups that will receive the policy.
1. Select **Next**.
1. In **Applicability Rules**, select **Next**.
1. In **Review + create**, review your settings and select **Create**.
> [!NOTE]
> For Azure Government, there is a known issue with PIN reset on Azure AD 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.