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

[BULK] - DocuTune - Rebranding of Azure Active Dir

Browse Source
This commit is contained in:
Alex Buck 2023-10-17 23:16:49 -04:00
parent 644bd14e3c
commit 02ac63237c
30 changed files with 436 additions and 366 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
windows/security/cloud-security/toc.yml
View File

@ -1,7 +1,7 @@
items: items:
- name: Overview - name: Overview
href: index.md href: index.md
- name: Join Active Directory and Azure AD with single sign-on (SSO) 🔗 - name: Join Active Directory and Microsoft Entra ID with single sign-on (SSO) 🔗
href: /azure/active-directory/devices/concept-azure-ad-join href: /azure/active-directory/devices/concept-azure-ad-join
- name: Security baselines with Intune 🔗 - name: Security baselines with Intune 🔗
href: /mem/intune/protect/security-baselines href: /mem/intune/protect/security-baselines
@ -15,4 +15,3 @@ items:
href: /windows/deployment/windows-autopatch href: /windows/deployment/windows-autopatch
- name: Windows Autopilot 🔗 - name: Windows Autopilot 🔗
href: /windows/deployment/windows-autopilot href: /windows/deployment/windows-autopilot

2
windows/security/hardware-security/tpm/how-windows-uses-the-tpm.md
View File

@ -57,7 +57,7 @@ For TPM-based virtual smart cards, the TPM protects the use and storage of the c
Windows Hello for Business provides authentication methods intended to replace passwords, which can be difficult to remember and easily compromised. In addition, username/password solutions for authentication often reuse the same credential combinations on multiple devices and services. If those credentials are compromised, they are compromised in multiple places. Windows Hello for Business combines the information provisioned on each device (i.e., the cryptographic key) with additional information to authenticate users. On a system that has a TPM, the TPM can protect the key. If a system does not have a TPM, software-based techniques protect the key. The additional information the user supplies can be a PIN value or, if the system has the necessary hardware, biometric information, such as fingerprint or facial recognition. To protect privacy, the biometric information is used only on the provisioned device to access the provisioned key: it is not shared across devices. Windows Hello for Business provides authentication methods intended to replace passwords, which can be difficult to remember and easily compromised. In addition, username/password solutions for authentication often reuse the same credential combinations on multiple devices and services. If those credentials are compromised, they are compromised in multiple places. Windows Hello for Business combines the information provisioned on each device (i.e., the cryptographic key) with additional information to authenticate users. On a system that has a TPM, the TPM can protect the key. If a system does not have a TPM, software-based techniques protect the key. The additional information the user supplies can be a PIN value or, if the system has the necessary hardware, biometric information, such as fingerprint or facial recognition. To protect privacy, the biometric information is used only on the provisioned device to access the provisioned key: it is not shared across devices.
The adoption of new authentication technology requires that identity providers and organizations deploy and use that technology. Windows Hello for Business lets users authenticate with their existing Microsoft account, an Active Directory account, a Microsoft Azure Active Directory account, or even non-Microsoft Identity Provider Services or Relying Party Services that support [Fast ID Online V2.0 authentication](https://go.microsoft.com/fwlink/p/?LinkId=533889). The adoption of new authentication technology requires that identity providers and organizations deploy and use that technology. Windows Hello for Business lets users authenticate with their existing Microsoft account, an Active Directory account, a Microsoft Entra account, or even non-Microsoft Identity Provider Services or Relying Party Services that support [Fast ID Online V2.0 authentication](https://go.microsoft.com/fwlink/p/?LinkId=533889).
Identity providers have flexibility in how they provision credentials on client devices. For example, an organization might provision only those devices that have a TPM so that the organization knows that a TPM protects the credentials. The ability to distinguish a TPM from malware acting like a TPM requires the following TPM capabilities (see Figure 1): Identity providers have flexibility in how they provision credentials on client devices. For example, an organization might provision only those devices that have a TPM so that the organization knows that a TPM protects the credentials. The ability to distinguish a TPM from malware acting like a TPM requires the following TPM capabilities (see Figure 1):

2
windows/security/hardware-security/tpm/tpm-recommendations.md
View File

@ -104,7 +104,7 @@ The following table defines which Windows features require TPM support.
Windows Defender System Guard (DRTM) | Yes | No | Yes | TPM 2.0 and UEFI firmware is required. Windows Defender System Guard (DRTM) | Yes | No | Yes | TPM 2.0 and UEFI firmware is required.
Credential Guard | No | Yes | Yes | Windows 10, version 1507 (End of Life as of May 2017) only supported TPM 2.0 for Credential Guard. Beginning with Windows 10, version 1511, TPM 1.2 and 2.0 are supported. Paired with Windows Defender System Guard, TPM 2.0 provides enhanced security for Credential Guard. Windows 11 requires TPM 2.0 by default to facilitate easier enablement of this enhanced security for customers. Credential Guard | No | Yes | Yes | Windows 10, version 1507 (End of Life as of May 2017) only supported TPM 2.0 for Credential Guard. Beginning with Windows 10, version 1511, TPM 1.2 and 2.0 are supported. Paired with Windows Defender System Guard, TPM 2.0 provides enhanced security for Credential Guard. Windows 11 requires TPM 2.0 by default to facilitate easier enablement of this enhanced security for customers.
Device Health Attestation| Yes | Yes | Yes | TPM 2.0 is recommended since it supports newer cryptographic algorithms. TPM 1.2 only supports the SHA-1 algorithm which is being deprecated. Device Health Attestation| Yes | Yes | Yes | TPM 2.0 is recommended since it supports newer cryptographic algorithms. TPM 1.2 only supports the SHA-1 algorithm which is being deprecated.
Windows Hello/Windows Hello for Business| No | Yes | Yes | Azure AD join supports both versions of TPM, but requires TPM with keyed-hash message authentication code (HMAC) and Endorsement Key (EK) certificate for key attestation support. TPM 2.0 is recommended over TPM 1.2 for better performance and security. Windows Hello as a FIDO platform authenticator will take advantage of TPM 2.0 for key storage. Windows Hello/Windows Hello for Business| No | Yes | Yes | Microsoft Entra join supports both versions of TPM, but requires TPM with keyed-hash message authentication code (HMAC) and Endorsement Key (EK) certificate for key attestation support. TPM 2.0 is recommended over TPM 1.2 for better performance and security. Windows Hello as a FIDO platform authenticator will take advantage of TPM 2.0 for key storage.
UEFI Secure Boot | No | Yes | Yes UEFI Secure Boot | No | Yes | Yes
TPM Platform Crypto Provider Key Storage Provider| Yes | Yes | Yes TPM Platform Crypto Provider Key Storage Provider| Yes | Yes | Yes
Virtual Smart Card | Yes | Yes | Yes Virtual Smart Card | Yes | Yes | Yes

2
windows/security/identity-protection/credential-guard/how-it-works.md
View File

@ -28,7 +28,7 @@ Some ways to store credentials aren't protected by Credential Guard, including:
- Third-party security packages - Third-party security packages
- When Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials. Thus, single sign-on doesn't work with these protocols. However, applications can prompt for credentials or use credentials stored in the Windows Vault, which aren't protected by Credential Guard with any of these protocols - When Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials. Thus, single sign-on doesn't work with these protocols. However, applications can prompt for credentials or use credentials stored in the Windows Vault, which aren't protected by Credential Guard with any of these protocols
> [!CAUTION] > [!CAUTION]
> It's recommended that valuable credentials, such as the sign-in credentials, aren't used with NTLMv1, MS-CHAPv2, Digest, or CredSSP protocols. If these protocols must be used by domain or Azure AD users, secondary credentials should be provisioned for these use cases. > It's recommended that valuable credentials, such as the sign-in credentials, aren't used with NTLMv1, MS-CHAPv2, Digest, or CredSSP protocols. If these protocols must be used by domain or Microsoft Entra users, secondary credentials should be provisioned for these use cases.
- Supplied credentials for NTLM authentication aren't protected. If a user is prompted for and enters credentials for NTLM authentication, these credentials are vulnerable to be read from LSASS memory. These same credentials are vulnerable to key loggers as well - Supplied credentials for NTLM authentication aren't protected. If a user is prompted for and enters credentials for NTLM authentication, these credentials are vulnerable to be read from LSASS memory. These same credentials are vulnerable to key loggers as well
- Kerberos service tickets aren't protected by Credential Guard, but the Kerberos Ticket Granting Ticket (TGT) is protected - Kerberos service tickets aren't protected by Credential Guard, but the Kerberos Ticket Granting Ticket (TGT) is protected
- When Credential Guard is enabled, Kerberos doesn't allow *unconstrained Kerberos delegation* or *DES encryption*, not only for signed-in credentials, but also prompted or saved credentials - When Credential Guard is enabled, Kerberos doesn't allow *unconstrained Kerberos delegation* or *DES encryption*, not only for signed-in credentials, but also prompted or saved credentials

4
windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
View File

@ -15,7 +15,7 @@ When you Microsoft Entra join a Windows device, the system prompts you to enroll
You may wish to disable the automatic Windows Hello for Business enrollment prompts if you aren't ready to use it in your environment. This article describes how to disable Windows Hello for Business enrollment in a cloud only environment. You may wish to disable the automatic Windows Hello for Business enrollment prompts if you aren't ready to use it in your environment. This article describes how to disable Windows Hello for Business enrollment in a cloud only environment.
> [!NOTE] > [!NOTE]
> During the out-of-box experience (OOBE) flow of an Microsoft Entra join, you will see a provisioning PIN when you don't have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts. > During the out-of-box experience (OOBE) flow of a Microsoft Entra join, you will see a provisioning PIN when you don't have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts.
## Prerequisites ## Prerequisites
@ -58,7 +58,7 @@ The following method explains how to disable Windows Hello for Business enrollme
## Disable Windows Hello for Business enrollment without Intune ## Disable Windows Hello for Business enrollment without Intune
If you don't use Intune in your organization, then you can disable Windows Hello for Business using the registry. You can use a third-party MDM, or some other method that you use to manage these devices. Because these systems are Azure AD Joined only, and not domain joined, these settings can also be made manually in the registry. If you don't use Intune in your organization, then you can disable Windows Hello for Business using the registry. You can use a third-party MDM, or some other method that you use to manage these devices. Because these systems are Microsoft Entra joined only, and not domain joined, these settings can also be made manually in the registry.
Intune uses the following registry keys: **`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\<Tenant-ID>\Device\Policies`** Intune uses the following registry keys: **`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\<Tenant-ID>\Device\Policies`**

10
windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
View File

@ -1,6 +1,6 @@
--- ---
title: Validate and Deploy MFA for Windows Hello for Business with certificate trust title: Validate and Deploy MFA for Windows Hello for Business with certificate trust
description: Validate and deploy multi-factor authentication (MFA) for Windows Hello for Business in an on-premises certificate trust model. description: Validate and deploy multifactor authentication (MFA) for Windows Hello for Business in an on-premises certificate trust model.
ms.date: 09/07/2023 ms.date: 09/07/2023
appliesto: appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a> - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
@ -11,21 +11,21 @@ appliesto:
ms.topic: tutorial ms.topic: tutorial
--- ---
# Validate and deploy multi-factor authentication - on-premises certificate trust # Validate and deploy multifactor authentication - on-premises certificate trust
[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)] [!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)]
Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option: Windows Hello for Business requires users perform multifactor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
- third-party authentication providers for AD FS - third-party authentication providers for AD FS
- custom authentication provider for AD FS - custom authentication provider for AD FS
> [!IMPORTANT] > [!IMPORTANT]
> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual. > As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multifactor authentication from their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
For information about third-party authentication methods, see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). To create a custom authentication method, see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method). For information about third-party authentication methods, see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). To create a custom authentication method, see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method).
Follow the integration and deployment guide for the authentication provider you plan to integrate to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies, see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies). Follow the integration and deployment guide for the authentication provider you plan to integrate to AD FS. Make sure that the authentication provider is selected as a multifactor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies, see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
> [!div class="nextstepaction"] > [!div class="nextstepaction"]
> [Next: configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md) > [Next: configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)

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

@ -30,9 +30,9 @@ Do not begin your deployment until the hosting servers and infrastructure (not r
## Deployment and trust models ## Deployment and trust models
Windows Hello for Business has three deployment models: Azure AD cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key Trust*, *Certificate Trust*, and *cloud Kerberos trust*. On-premises deployment models only support *Key Trust* and *Certificate Trust*. Windows Hello for Business has three deployment models: Microsoft Entra cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key Trust*, *Certificate Trust*, and *cloud Kerberos trust*. On-premises deployment models only support *Key Trust* and *Certificate Trust*.
Hybrid deployments are for enterprises that use Azure Active Directory. On-premises deployments are for enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Azure Active Directory must use the hybrid deployment model for all domains in that forest. Hybrid deployments are for enterprises that use Microsoft Entra ID. On-premises deployments are for enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Microsoft Entra ID must use the hybrid deployment model for all domains in that forest.
The trust model determines how you want users to authenticate to the on-premises Active Directory: The trust model determines how you want users to authenticate to the on-premises Active Directory:
@ -46,14 +46,14 @@ The trust model determines how you want users to authenticate to the on-premises
Following are the various deployment guides and models included in this topic: Following are the various deployment guides and models included in this topic:
- [Hybrid Azure AD Joined cloud Kerberos trust Deployment](hello-hybrid-cloud-kerberos-trust.md) - [Microsoft Entra hybrid joined cloud Kerberos trust Deployment](hello-hybrid-cloud-kerberos-trust.md)
- [Hybrid Azure AD Joined Key Trust Deployment](hello-hybrid-key-trust.md) - [Microsoft Entra hybrid joined Key Trust Deployment](hello-hybrid-key-trust.md)
- [Hybrid Azure AD Joined Certificate Trust Deployment](hello-hybrid-cert-trust.md) - [Microsoft Entra hybrid joined Certificate Trust Deployment](hello-hybrid-cert-trust.md)
- [Azure AD Join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md) - [Microsoft Entra join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md)
- [On Premises Key Trust Deployment](hello-deployment-key-trust.md) - [On Premises Key Trust Deployment](hello-deployment-key-trust.md)
- [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md) - [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md)
For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you will need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials are not synchronized to Azure Active Directory. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](hello-key-trust-validate-deploy-mfa.md) and [for certificate trust](hello-cert-trust-validate-deploy-mfa.md) deployments. For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you will need Microsoft Entra Connect to synchronize user accounts in the on-premises Active Directory with Microsoft Entra ID. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials are not synchronized to Microsoft Entra ID. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](hello-key-trust-validate-deploy-mfa.md) and [for certificate trust](hello-cert-trust-validate-deploy-mfa.md) deployments.
## Provisioning ## Provisioning

24
windows/security/identity-protection/hello-for-business/hello-deployment-issues.md
View File

@ -8,13 +8,15 @@ ms.topic: troubleshooting
The content of this article is to help troubleshoot known deployment issues for Windows Hello for Business. The content of this article is to help troubleshoot known deployment issues for Windows Hello for Business.
## PIN reset on Azure AD join devices fails with *We can't open that page right now* error <a name='pin-reset-on-azure-ad-join-devices-fails-with-we-cant-open-that-page-right-now-error'></a>
PIN reset on Azure AD-joined devices uses a flow called *web sign-in* to authenticate the user above lock. Web sign in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message *We can't open that page right now*. ## PIN reset on Microsoft Entra join devices fails with *We can't open that page right now* error
PIN reset on Microsoft Entra joined devices uses a flow called *web sign-in* to authenticate the user above lock. Web sign in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message *We can't open that page right now*.
### Identify PIN Reset allowed domains issue ### Identify PIN Reset allowed domains issue
The user can launch the PIN reset flow from the lock screen using the *I forgot my PIN* link in the PIN credential provider. Selecting the link launches a full screen UI for the PIN experience on Azure AD Join devices. Typically, the UI displays an Azure authentication page, where the user authenticates using Azure AD credentials and completes MFA. The user can launch the PIN reset flow from the lock screen using the *I forgot my PIN* link in the PIN credential provider. Selecting the link launches a full screen UI for the PIN experience on Microsoft Entra join devices. Typically, the UI displays an Azure authentication page, where the user authenticates using Microsoft Entra credentials and completes MFA.
In federated environments, authentication may be configured to route to AD FS or a third-party identity provider. If the PIN reset flow is launched and attempts to navigate to a federated identity provider server page, it fails and displays the *We can't open that page right now* error, if the domain for the server page isn't included in an allowlist. In federated environments, authentication may be configured to route to AD FS or a third-party identity provider. If the PIN reset flow is launched and attempts to navigate to a federated identity provider server page, it fails and displays the *We can't open that page right now* error, if the domain for the server page isn't included in an allowlist.
@ -22,7 +24,7 @@ If you're a customer of *Azure US Government* cloud, PIN reset also attempts to
### Resolve PIN Reset allowed domains issue ### Resolve PIN Reset allowed domains issue
To resolve the error, you can configure a list of allowed domains for PIN reset using the [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy. For information on how to configure the policy, see [Configure allowed URLs for federated identity providers on Azure AD joined devices](hello-feature-pin-reset.md#configure-allowed-urls-for-federated-identity-providers-on-azure-ad-joined-devices). To resolve the error, you can configure a list of allowed domains for PIN reset using the [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy. For information on how to configure the policy, see [Configure allowed URLs for federated identity providers on Microsoft Entra joined devices](hello-feature-pin-reset.md#configure-allowed-urls-for-federated-identity-providers-on-azure-ad-joined-devices).
## Hybrid key trust sign in broken due to user public key deletion ## Hybrid key trust sign in broken due to user public key deletion
@ -32,11 +34,11 @@ Applies to:
- Windows Server 2016, builds 14393.3930 to 14393.4048 - Windows Server 2016, builds 14393.3930 to 14393.4048
- Windows Server 2019, builds 17763.1457 to 17763.1613 - Windows Server 2019, builds 17763.1457 to 17763.1613
In Hybrid key trust deployments with domain controllers running certain builds of Windows Server 2016 and Windows Server 2019, the user's Windows Hello for Business key is deleted after they sign-in. Subsequent sign-ins will fail until the user's key is synced during the next Azure AD Connect delta sync cycle. In Hybrid key trust deployments with domain controllers running certain builds of Windows Server 2016 and Windows Server 2019, the user's Windows Hello for Business key is deleted after they sign-in. Subsequent sign-ins will fail until the user's key is synced during the next Microsoft Entra Connect delta sync cycle.
### Identify user public key deletion issue ### Identify user public key deletion issue
After the user provisions a Windows Hello for Business credential in a hybrid key trust environment, the key must sync from Azure AD to AD during an Azure AD Connect sync cycle. The user's public key is written to the `msDS-KeyCredentialLink` attribute of the user object. After the user provisions a Windows Hello for Business credential in a hybrid key trust environment, the key must sync from Microsoft Entra ID to Active Directory during a Microsoft Entra Connect Sync cycle. The user's public key is written to the `msDS-KeyCredentialLink` attribute of the user object.
Before the user's Windows Hello for Business key syncs, sign-ins with Windows Hello for Business fail with the error message *That option is temporarily unavailable. For now, please use a different method to sign in.* After the key syncs successfully, the user can sign in and unlock with their PIN or enrolled biometrics. Before the user's Windows Hello for Business key syncs, sign-ins with Windows Hello for Business fail with the error message *That option is temporarily unavailable. For now, please use a different method to sign in.* After the key syncs successfully, the user can sign in and unlock with their PIN or enrolled biometrics.
@ -48,14 +50,16 @@ After the initial sign-in attempt, the user's Windows Hello for Business public
To resolve the issue, update Windows Server 2016 and 2019 domain controllers with the latest patches. For Windows Server 2016, the behavior is fixed in build *14393.4104* ([KB4593226](https://support.microsoft.com/help/4593226)) and later. For Windows Server 2019, the behavior is fixed in build *17763.1637* ([KB4592440](https://support.microsoft.com/help/4592440)). To resolve the issue, update Windows Server 2016 and 2019 domain controllers with the latest patches. For Windows Server 2016, the behavior is fixed in build *14393.4104* ([KB4593226](https://support.microsoft.com/help/4593226)) and later. For Windows Server 2019, the behavior is fixed in build *17763.1637* ([KB4592440](https://support.microsoft.com/help/4592440)).
## Azure AD joined device access to on-premises resources using key trust and third-party Certificate Authority (CA) <a name='azure-ad-joined-device-access-to-on-premises-resources-using-key-trust-and-third-party-certificate-authority-ca'></a>
## Microsoft Entra joined device access to on-premises resources using key trust and third-party Certificate Authority (CA)
Applies to: Applies to:
- Azure AD joined key trust deployments - Microsoft Entra joined key trust deployments
- Third-party certificate authority (CA) issuing domain controller certificates - Third-party certificate authority (CA) issuing domain controller certificates
Windows Hello for Business uses smart-card based authentication for many operations. This type of authentication has special guidelines when using a third-party CA for certificate issuance, some of which apply to the domain controllers. Not all Windows Hello for Business deployment types require these configurations. Accessing on-premises resources from an Azure AD Joined device does require special configuration when using a third-party CA to issue domain controller certificates. Windows Hello for Business uses smart-card based authentication for many operations. This type of authentication has special guidelines when using a third-party CA for certificate issuance, some of which apply to the domain controllers. Not all Windows Hello for Business deployment types require these configurations. Accessing on-premises resources from a Microsoft Entra joined device does require special configuration when using a third-party CA to issue domain controller certificates.
For more information, read [Guidelines for enabling smart card sign in with third-party certification authorities](/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities). For more information, read [Guidelines for enabling smart card sign in with third-party certification authorities](/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities).
@ -104,7 +108,7 @@ Domain controllers running early versions of Windows Server 2019 have an issue t
On the client, authentication with Windows Hello for Business fails with the error message, *That option is temporarily unavailable. For now, please use a different method to sign in.* On the client, authentication with Windows Hello for Business fails with the error message, *That option is temporarily unavailable. For now, please use a different method to sign in.*
The error is presented on hybrid Azure AD-joined devices in key trust deployments after Windows Hello for Business is provisioned, but before a user's key is synced from Azure AD to AD. If a user's key isn't synced from Azure AD and the `msDS-keycredentiallink` attribute on the user object in AD is populated for NGC, then it's possible that the error occurs. The error is presented on Microsoft Entra hybrid joined devices in key trust deployments after Windows Hello for Business is provisioned, but before a user's key is synced from Microsoft Entra ID to Active Directory. If a user's key isn't synced from Microsoft Entra ID and the `msDS-keycredentiallink` attribute on the user object in AD is populated for NGC, then it's possible that the error occurs.
Another indicator of the failure can be identified using network traces. If you capture network traces for a key trust sign-in event, the traces show Kerberos failing with the error *KDC_ERR_CLIENT_NAME_MISMATCH*. Another indicator of the failure can be identified using network traces. If you capture network traces for a key trust sign-in event, the traces show Kerberos failing with the error *KDC_ERR_CLIENT_NAME_MISMATCH*.

12
windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
View File

@ -18,13 +18,13 @@ This document describes Windows Hello for Business functionalities or scenarios
Windows Hello for Business supports using a certificate as the supplied credential, when establishing a remote desktop connection to another Windows device. This document discusses three approaches for *cloud Kerberos trust* and *key trust* deployments, where authentication certificates can be deployed to an existing Windows Hello for Business user: Windows Hello for Business supports using a certificate as the supplied credential, when establishing a remote desktop connection to another Windows device. This document discusses three approaches for *cloud Kerberos trust* and *key trust* deployments, where authentication certificates can be deployed to an existing Windows Hello for Business user:
- Deploy certificates to hybrid joined devices using an on-premises Active Directory Certificate Services enrollment policy - Deploy certificates to hybrid joined devices using an on-premises Active Directory Certificate Services enrollment policy
- Deploy certificates to hybrid or Azure AD-joined devices using Intune - Deploy certificates to hybrid or Microsoft Entra joined devices using Intune
- Work with third-party PKIs - Work with third-party PKIs
## Deploy certificates via Active Directory Certificate Services (AD CS) ## Deploy certificates via Active Directory Certificate Services (AD CS)
> [!NOTE] > [!NOTE]
> This process is applicable to *hybrid Azure AD joined* devices only. > This process is applicable to *Microsoft Entra hybrid joined* devices only.
To deploy certificates using an on-premises Active Directory Certificate Services enrollment policy, you must first create a *certificate template*, and then deploy certificates based on that template. To deploy certificates using an on-premises Active Directory Certificate Services enrollment policy, you must first create a *certificate template*, and then deploy certificates based on that template.
@ -77,7 +77,7 @@ Follow these steps to create a certificate template:
### Request a certificate ### Request a certificate
1. Sign in to a client that is hybrid Azure AD joined, ensuring that the client has line of sight to a domain controller and the issuing CA 1. Sign in to a client that is Microsoft Entra hybrid joined, ensuring that the client has line of sight to a domain controller and the issuing CA
1. Open the **Certificates - Current User** Microsoft Management Console (MMC). To do so, you can execute the command `certmgr.msc` 1. Open the **Certificates - Current User** Microsoft Management Console (MMC). To do so, you can execute the command `certmgr.msc`
1. In the left pane of the MMC, right-click **Personal > All Tasks > Request New Certificate…** 1. In the left pane of the MMC, right-click **Personal > All Tasks > Request New Certificate…**
1. On the Certificate Enrollment screen, select **Next** 1. On the Certificate Enrollment screen, select **Next**
@ -88,17 +88,17 @@ Follow these steps to create a certificate template:
## Deploy certificates via Intune ## Deploy certificates via Intune
> [!CAUTION] > [!CAUTION]
> This process is applicable to both *Azure AD joined* and *hybrid Azure AD joined* devices that are managed via Intune. > This process is applicable to both *Microsoft Entra joined* and *Microsoft Entra hybrid joined* devices that are managed via Intune.
> >
> If you deploy certificates via Intune and configure Windows Hello for Business via group policy, the devices will fail to obtain a certificate, logging the error code `0x82ab0011` in the `DeviceManagement-Enterprise-Diagnostic-Provider` log.\ > If you deploy certificates via Intune and configure Windows Hello for Business via group policy, the devices will fail to obtain a certificate, logging the error code `0x82ab0011` in the `DeviceManagement-Enterprise-Diagnostic-Provider` log.\
> To avoid the error, configure Windows Hello for Business via Intune instead of group policy. > To avoid the error, configure Windows Hello for Business via Intune instead of group policy.
Deploying a certificate to Azure AD joined or hybrid Azure AD joined devices may be achieved using the Simple Certificate Enrollment Protocol (SCEP) or PKCS (PFX) via Intune. For guidance deploying the required infrastructure, refer to: Deploying a certificate to Microsoft Entra joined or Microsoft Entra hybrid joined devices may be achieved using the Simple Certificate Enrollment Protocol (SCEP) or PKCS (PFX) via Intune. For guidance deploying the required infrastructure, refer to:
- [Configure infrastructure to support SCEP certificate profiles with Microsoft Intune][MEM-1] - [Configure infrastructure to support SCEP certificate profiles with Microsoft Intune][MEM-1]
- [Configure and use PKCS certificates with Intune][MEM-2] - [Configure and use PKCS certificates with Intune][MEM-2]
Next, you should deploy the root CA certificate (and any other intermediate certificate authority certificates) to Azure AD joined Devices using a *Trusted root certificate* policy with Intune. For guidance, refer to [Create trusted certificate profiles in Microsoft Intune][MEM-5]. Next, you should deploy the root CA certificate (and any other intermediate certificate authority certificates) to Microsoft Entra joined Devices using a *Trusted root certificate* policy with Intune. For guidance, refer to [Create trusted certificate profiles in Microsoft Intune][MEM-5].
Once these requirements are met, a policy can be configured in Intune that provisions certificates for the users on the targeted device. Once these requirements are met, a policy can be configured in Intune that provisions certificates for the users on the targeted device.

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

@ -22,15 +22,15 @@ When a user encounters an error when creating the work PIN, advise the user to t
1. Try to create the PIN again. Some errors are transient and resolve themselves. 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. 2. Sign out, sign in, and try to create the PIN again.
3. Reboot the device and then try to create the PIN again. 3. Reboot the device and then try to create the PIN again.
4. Unjoin the device from Azure Active Directory (Azure AD), rejoin, and then try to create the PIN again. To unjoin a device, go to **Settings > System > About > Disconnect from organization**. 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**.
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 is another mitigation for that error. When no mitigation is listed in the table, contact Microsoft Support for assistance.
| Hex | Cause | Mitigation | | Hex | Cause | Mitigation |
| :--------- | :----------------------------------------------------------------- | :------------------------------------------ | | :--------- | :----------------------------------------------------------------- | :------------------------------------------ |
| 0x80090005 | NTE\_BAD\_DATA | Unjoin the device from Azure AD and rejoin. | | 0x80090005 | NTE\_BAD\_DATA | Unjoin the device from Microsoft Entra ID and rejoin. |
| 0x8009000F | The container or key already exists. | Unjoin the device from Azure AD 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 Azure AD 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**. | | 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. | | 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). | | 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). |
@ -50,11 +50,11 @@ If the error occurs again, check the error code against the following table to s
| 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. | | 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. | | 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. | | 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 Azure AD. | 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 Azure AD under Azure AD Device settings. | 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. | | 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. | | 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 Azure Active Directory and the Primary SMTP address are the same in the proxy address. | 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 Azure AD and rejoin. | | 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. | | | 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. | | 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.| | 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.|
@ -86,6 +86,5 @@ For errors listed in this table, contact Microsoft Support for assistance.
| 0x801C03F0 | ​There is no key registered for the user. | | 0x801C03F0 | ​There is no key registered for the user. |
| 0x801C03F1 | ​There is no UPN in the token. | | 0x801C03F1 | ​There is no UPN in the token. |
| ​0x801C044C | There is no core window for the current thread. | | ​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 Azure Active Directory token for provisioning. Unable to enroll a device to use a PIN for login. | | 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. | | 0xCAA30193 | HTTP 403 Request Forbidden: it means request left the device, however either Server, proxy or firewall generated this response. |

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

@ -36,7 +36,7 @@ sections:
- question: What's a container? - question: What's a container?
answer: | answer: |
In the context of Windows Hello for Business, a container is a logical grouping of *key material* or data. Windows Hello uses a single container that holds user key material for personal accounts, including key material associated with the user's Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account. In the context of Windows Hello for Business, a container is a logical grouping of *key material* or data. Windows Hello uses a single container that holds user key material for personal accounts, including key material associated with the user's Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account.
The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD. The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Microsoft Entra ID.
> [!NOTE] > [!NOTE]
> There are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials that Windows Hello stores, are protected without the creation of actual containers or folders. > There are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials that Windows Hello stores, are protected without the creation of actual containers or folders.
@ -46,7 +46,7 @@ sections:
Containers can contain several types of key material: Containers can contain several types of key material:
- An authentication key, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key. - An authentication key, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
- The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways: - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
- The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container. - The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
- The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI. - The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI.
- question: How are keys protected? - question: How are keys protected?
@ -54,7 +54,7 @@ sections:
Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended 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 have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IDP before the IDP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed. Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended 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 have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IDP before the IDP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
- question: How does PIN caching work with Windows Hello for Business? - question: How does PIN caching work with Windows Hello for Business?
answer: | answer: |
Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Azure AD and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key. Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Microsoft Entra ID and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key.
Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN. Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN.
@ -70,9 +70,9 @@ sections:
Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it. Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
- question: What's the difference between non-destructive and destructive PIN reset? - question: What's the difference between non-destructive and destructive PIN reset?
answer: | answer: |
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). Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Microsoft Entra ID 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 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. 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 Microsoft Entra hybrid joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
- question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication? - question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication?
answer: | 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, like a 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. 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 request users to enroll into Windows Hello during Autopilot or during the 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. 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, like a 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. 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 request users to enroll into Windows Hello during Autopilot or during the 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.
@ -123,7 +123,7 @@ sections:
No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics. No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics.
- question: What is Event ID 300? - question: What is Event ID 300?
answer: | answer: |
This event is created when Windows Hello for Business is successfully created and registered with Azure Active Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request. This is a normal condition and no further action is required. This event is created when Windows Hello for Business is successfully created and registered with Microsoft Entra ID. Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request. This is a normal condition and no further action is required.
- question: What happens when an unauthorized user gains possession of a device enrolled in Windows Hello for Business? - question: What happens when an unauthorized user gains possession of a device enrolled in Windows Hello for Business?
answer: | answer: |
The unauthorized user won't be able to utilize any biometric options and will have the only option to enter a PIN. The unauthorized user won't be able to utilize any biometric options and will have the only option to enter a PIN.
@ -142,12 +142,12 @@ sections:
- question: How many users can enroll for Windows Hello for Business on a single Windows device? - question: How many users can enroll for Windows Hello for Business on a single Windows device?
answer: | answer: |
The maximum number of supported enrollments on a single device is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, or for users that sign-in to many devices (for example, a support technician), it's recommended the use of FIDO2 security keys. The maximum number of supported enrollments on a single device is 10. This lets 10 users each enroll their face and up to 10 fingerprints. For devices with more than 10 users, or for users that sign-in to many devices (for example, a support technician), it's recommended the use of FIDO2 security keys.
- question: I have extended Active Directory to Azure Active Directory. Can I use the on-premises deployment model? - question: I have extended Active Directory to Microsoft Entra ID. Can I use the on-premises deployment model?
answer: | answer: |
No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory. No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory.
- question: What attributes are synchronized by Azure AD Connect with Windows Hello for Business? - question: What attributes are synchronized by Microsoft Entra Connect with Windows Hello for Business?
answer: | answer: |
Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes. Review [Microsoft Entra Connect Sync: Attributes synchronized to Microsoft Entra ID](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes.
- question: Can I use third-party MFA providers with Windows Hello for Business? - question: Can I use third-party MFA providers with Windows Hello for Business?
answer: | answer: |
Yes, if you're using federated hybrid deployment, you can use any third-party that provides an AD FS MFA adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods). Yes, if you're using federated hybrid deployment, you can use any third-party that provides an AD FS MFA adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods).
@ -170,21 +170,21 @@ sections:
- question: Can I wear a mask to enroll or unlock using Windows Hello face authentication? - question: Can I wear a mask to enroll or unlock using Windows Hello face authentication?
answer: | answer: |
Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, consider un-enrolling from face authentication and only using PIN or fingerprint. Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, consider un-enrolling from face authentication and only using PIN or fingerprint.
- question: How does Windows Hello for Business work with Azure AD registered devices? - question: How does Windows Hello for Business work with Microsoft Entra registered devices?
answer: | answer: |
A user will be prompted to set up a Windows Hello for Business key on an Azure AD registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures. A user will be prompted to set up a Windows Hello for Business key on a Microsoft Entra registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures.
If a user has signed into their Azure AD registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources. If a user has signed into their Microsoft Entra registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Microsoft Entra resources. The Windows Hello for Business key meets Microsoft Entra multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
It's possible to Azure AD register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business. It's possible to Microsoft Entra register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business.
For more information, please read [Azure AD registered devices](/azure/active-directory/devices/concept-azure-ad-register). For more information, please read [Microsoft Entra registered devices](/azure/active-directory/devices/concept-azure-ad-register).
- question: Does Windows Hello for Business work with non-Windows operating systems? - question: Does Windows Hello for Business work with non-Windows operating systems?
answer: | answer: |
Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration). Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration).
- question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients? - question: Does Windows Hello for Business work with Microsoft Entra Domain Services clients?
answer: | 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 DS. No, Microsoft Entra Domain Services is a separately managed environment in Azure, and hybrid device registration with cloud Microsoft Entra ID isn't available for it via Microsoft Entra Connect. Hence, Windows Hello for Business doesn't work with Microsoft Entra Domain Services.
- question: Is Windows Hello for Business considered multifactor authentication? - question: Is Windows Hello for Business considered multifactor authentication?
answer: | 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". 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".
@ -200,9 +200,9 @@ sections:
- question: What is convenience PIN? - question: What is convenience PIN?
answer: | answer: |
*Convenience PIN* provides a simpler way to sign in to Windows than passwords, but it still uses a password for authentication. When the correct convenience PIN is provided to Windows, the password information is loaded from its cache and authenticates the user. Organizations using convenience PINs should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs. *Convenience PIN* provides a simpler way to sign in to Windows than passwords, but it still uses a password for authentication. When the correct convenience PIN is provided to Windows, the password information is loaded from its cache and authenticates the user. Organizations using convenience PINs should move to **Windows Hello for Business**. New Windows deployments should deploy Windows Hello for Business and not convenience PINs.
- question: Can I use a convenience PIN with Azure Active Directory? - question: Can I use a convenience PIN with Microsoft Entra ID?
answer: | answer: |
No. While it's possible to set a convenience PIN on Azure AD joined and hybrid Azure AD joined devices, convenience PIN isn't supported for Azure AD user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users. No. While it's possible to set a convenience PIN on Microsoft Entra joined and Microsoft Entra hybrid joined devices, convenience PIN isn't supported for Microsoft Entra user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users.
- question: What about virtual smart cards? - question: What about virtual smart cards?
answer: | answer: |
Windows Hello for Business is the modern, two-factor authentication for Windows. Microsoft will deprecate virtual smart cards in the near future. Customers using virtual smart cards are strongly encouraged to move to Windows Hello for Business. Microsoft will publish the deprecation date to ensure customers have adequate lead time to move to Windows Hello for Business. We recommend that new Windows deployments use Windows Hello for Business. Windows Hello for Business is the modern, two-factor authentication for Windows. Microsoft will deprecate virtual smart cards in the near future. Customers using virtual smart cards are strongly encouraged to move to Windows Hello for Business. Microsoft will publish the deprecation date to ensure customers have adequate lead time to move to Windows Hello for Business. We recommend that new Windows deployments use Windows Hello for Business.
@ -231,7 +231,7 @@ sections:
questions: questions:
- question: What is Windows Hello for Business cloud Kerberos trust? - question: What is Windows Hello for Business cloud Kerberos trust?
answer: | answer: |
Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables 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 Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust). Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Microsoft Entra hybrid joined devices and on-premises resource access on Microsoft Entra joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
- question: Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment? - question: Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment?
answer: | answer: |
This feature doesn't work in a pure on-premises AD domain services environment. This feature doesn't work in a pure on-premises AD domain services environment.
@ -254,7 +254,7 @@ sections:
questions: questions:
- question: Why does authentication fail immediately after provisioning hybrid key trust? - question: Why does authentication fail immediately after provisioning hybrid key trust?
answer: | answer: |
In a hybrid deployment, a user's public key must sync from Azure AD to AD before it can be used to authenticate against a domain controller. This sync is handled by Azure AD Connect and will occur during a normal sync cycle. In a hybrid deployment, a user's public key must sync from Microsoft Entra ID to Active Directory before it can be used to authenticate against a domain controller. This sync is handled by Microsoft Entra Connect and will occur during a normal sync cycle.
- question: Can I use Windows Hello for Business key trust and RDP? - question: Can I use Windows Hello for Business key trust and RDP?
answer: | 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 [Remote Credential Guard](../remote-credential-guard.md) without deploying certificates. 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 [Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.

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

@ -26,7 +26,7 @@ Windows Hello for Business provides the capability for users to reset forgotten
- Hybrid or cloud-only Windows Hello for Business deployments - Hybrid or cloud-only Windows Hello for Business deployments
- Windows Enterprise, Education and Pro editions. There's no licensing requirement for this feature - Windows Enterprise, Education and Pro editions. There's no licensing requirement for this feature
When non-destructive PIN reset is enabled on a client, a *256-bit AES* key is generated locally. The key is added to a user's Windows Hello for Business container and keys as the *PIN reset protector*. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to 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's then cleared from memory. When non-destructive PIN reset is enabled on a client, a *256-bit AES* key is generated locally. The key is added to a user's Windows Hello for Business container and keys as the *PIN reset protector*. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to Microsoft Entra ID, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it's then cleared from memory.
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. 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.
@ -35,15 +35,17 @@ The following table compares destructive and non-destructive PIN reset:
|Category|Destructive PIN reset|Non-Destructive PIN reset| |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, are deleted from the client and a new sign in key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.| |**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new sign in key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a 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.|
|**Azure Active Directory Joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust| |**Microsoft Entra joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust|
|**Hybrid Azure Active Directory Joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this option from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.| |**Microsoft Entra hybrid joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this option from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
|**On Premises**|If AD FS is used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it's only available for hybrid Azure AD joined and Azure AD Joined devices.| |**On Premises**|If AD FS is used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Microsoft Entra identities, so it's only available for Microsoft Entra hybrid joined and Microsoft Entra joined devices.|
|**Additional configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature.| |**Additional configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature.|
|**MSA/Enterprise**|MSA and Enterprise|Enterprise only.| |**MSA/Enterprise**|MSA and Enterprise|Enterprise only.|
## Enable the Microsoft PIN Reset Service in your Azure AD tenant <a name='enable-the-microsoft-pin-reset-service-in-your-azure-ad-tenant'></a>
Before you can use non-destructive PIN reset, you must register two applications in your Azure Active Directory tenant: ## Enable the Microsoft PIN Reset Service in your Microsoft Entra tenant
Before you can use non-destructive PIN reset, you must register two applications in your Microsoft Entra tenant:
- Microsoft Pin Reset Service Production - Microsoft Pin Reset Service Production
- Microsoft Pin Reset Client Production - Microsoft Pin Reset Client Production
@ -52,7 +54,7 @@ To register the applications, follow these steps:
:::row::: :::row:::
:::column span="3"::: :::column span="3":::
1. Go to the [Microsoft PIN Reset Service Production website][APP-1], and sign in using a *Global Administrator* account you use to manage your Azure Active Directory tenant. Review the permissions requested by the *Microsoft Pin Reset Service Production* application and select **Accept** to give consent to the application to access your organization 1. Go to the [Microsoft PIN Reset Service Production website][APP-1], and sign in using a *Global Administrator* account you use to manage your Microsoft Entra tenant. Review the permissions requested by the *Microsoft Pin Reset Service Production* application and select **Accept** to give consent to the application to access your organization
:::column-end::: :::column-end:::
:::column span="1"::: :::column span="1":::
:::image type="content" alt-text="Screenshot showing the PIN reset service permissions page." source="images/pinreset/pin-reset-service-prompt.png" lightbox="images/pinreset/pin-reset-service-prompt.png" border="true"::: :::image type="content" alt-text="Screenshot showing the PIN reset service permissions page." source="images/pinreset/pin-reset-service-prompt.png" lightbox="images/pinreset/pin-reset-service-prompt.png" border="true":::
@ -60,7 +62,7 @@ To register the applications, follow these steps:
:::row-end::: :::row-end:::
:::row::: :::row:::
:::column span="3"::: :::column span="3":::
2. Go to the [Microsoft PIN Reset Client Production website][APP-2], and sign in using a *Global Administrator* account you use to manage your Azure Active Directory tenant. Review the permissions requested by the *Microsoft Pin Reset Client Production* application, and select **Next**. 2. Go to the [Microsoft PIN Reset Client Production website][APP-2], and sign in using a *Global Administrator* account you use to manage your Microsoft Entra tenant. Review the permissions requested by the *Microsoft Pin Reset Client Production* application, and select **Next**.
:::column-end::: :::column-end:::
:::column span="1"::: :::column span="1":::
:::image type="content" alt-text="Screenshot showing the PIN reset client permissions page." source="images/pinreset/pin-reset-client-prompt.png" lightbox="images/pinreset/pin-reset-client-prompt.png" border="true"::: :::image type="content" alt-text="Screenshot showing the PIN reset client permissions page." source="images/pinreset/pin-reset-client-prompt.png" lightbox="images/pinreset/pin-reset-client-prompt.png" border="true":::
@ -80,7 +82,7 @@ To register the applications, follow these steps:
### Confirm that the two PIN Reset service principals are registered in your tenant ### 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. Sign in to the [Microsoft Entra Manager admin center](https://entra.microsoft.com)
1. Select **Azure Active Directory > Applications > Enterprise applications** 1. Select **Microsoft Entra ID > Applications > Enterprise applications**
1. Search by application name "Microsoft PIN" and verify that both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** are in the list 1. Search by application name "Microsoft PIN" and verify that both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** are in the list
:::image type="content" alt-text="PIN reset service permissions page." source="images/pinreset/pin-reset-applications.png" lightbox="images/pinreset/pin-reset-applications-expanded.png"::: :::image type="content" alt-text="PIN reset service permissions page." source="images/pinreset/pin-reset-applications.png" lightbox="images/pinreset/pin-reset-applications-expanded.png":::
@ -116,7 +118,7 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the
| `./Vendor/MSFT/Policy/PassportForWork/`*TenantId*`/Policies/EnablePinRecovery`| Boolean | True | | `./Vendor/MSFT/Policy/PassportForWork/`*TenantId*`/Policies/EnablePinRecovery`| Boolean | True |
>[!NOTE] >[!NOTE]
> You must replace `TenantId` with the identifier of your Azure Active Directory tenant. To look up your Tenant ID, see [How to find your Azure Active Directory tenant ID](/azure/active-directory/fundamentals/how-to-find-tenant) or try the following, ensuring to sign-in with your organization's account:: > You must replace `TenantId` with the identifier of your Microsoft Entra tenant. To look up your Tenant ID, see [How to find your Microsoft Entra tenant ID](/azure/active-directory/fundamentals/how-to-find-tenant) or try the following, ensuring to sign-in with your organization's account::
```msgraph-interactive ```msgraph-interactive
GET https://graph.microsoft.com/v1.0/organization?$select=id GET https://graph.microsoft.com/v1.0/organization?$select=id
@ -177,12 +179,14 @@ The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/a
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
``` ```
## Configure allowed URLs for federated identity providers on Azure AD joined devices <a name='configure-allowed-urls-for-federated-identity-providers-on-azure-ad-joined-devices'></a>
**Applies to:** Azure AD joined devices ## Configure allowed URLs for federated identity providers on Microsoft Entra joined devices
PIN reset on Azure AD-joined devices uses a flow called *web sign-in* to authenticate users in the lock screen. Web sign-in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message: *"We can't open that page right now"*.\ **Applies to:** Microsoft Entra joined devices
If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, then you must configure your devices with a policy to allow a list of domains that can be reached during PIN reset flows. When set, it ensures that authentication pages from that identity provider can be used during Azure AD joined PIN reset.
PIN reset on Microsoft Entra joined devices uses a flow called *web sign-in* to authenticate users in the lock screen. Web sign-in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message: *"We can't open that page right now"*.\
If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, then you must configure your devices with a policy to allow a list of domains that can be reached during PIN reset flows. When set, it ensures that authentication pages from that identity provider can be used during Microsoft Entra joined PIN reset.
[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)] [!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
@ -199,14 +203,14 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the
| <li> OMA-URI: `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls` </li><li>Data type: String </li><li>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**</li>| | <li> OMA-URI: `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls` </li><li>Data type: String </li><li>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**</li>|
> [!NOTE] > [!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. > For Azure Government, there is a known issue with PIN reset on Microsoft Entra joined devices failing. When the user attempts to launch PIN reset, the PIN reset UI shows an error page that says, *"We can't open that page right now"*. The ConfigureWebSignInAllowedUrls policy can be used to work around this issue. If you are experiencing this problem and you are using Azure US Government cloud, set **login.microsoftonline.us** as the value for the ConfigureWebSignInAllowedUrls policy.
## Use PIN reset ## Use PIN reset
Destructive and non-destructive PIN reset scenarios use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users don't have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen with the *PIN credential provider*. Users must authenticate and complete multi-factor authentication to reset their PIN. After PIN reset is complete, users can sign in using their new PIN. Destructive and non-destructive PIN reset scenarios use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users don't have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen with the *PIN credential provider*. Users must authenticate and complete multi-factor authentication to reset their PIN. After PIN reset is complete, users can sign in using their new PIN.
>[!IMPORTANT] >[!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. >For Microsoft Entra hybrid joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN.
### Reset PIN from Settings ### Reset PIN from Settings
@ -216,7 +220,7 @@ Destructive and non-destructive PIN reset scenarios use the same steps for initi
### Reset PIN from the lock screen ### Reset PIN from the lock screen
For Azure AD-joined devices: For Microsoft Entra joined devices:
1. If the PIN credential provider isn't selected, expand the **Sign-in options** link, and select the PIN pad icon 1. If the PIN credential provider isn't 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 **I forgot my PIN** from the PIN credential provider
@ -226,7 +230,7 @@ For Azure AD-joined devices:
:::image type="content" alt-text="Animation showing the PIN reset experience from the lock screen." source="images/pinreset/pin-reset.gif" border="false"::: :::image type="content" alt-text="Animation showing the PIN reset experience from the lock screen." source="images/pinreset/pin-reset.gif" border="false":::
For Hybrid Azure AD-joined devices: For Microsoft Entra hybrid joined devices:
1. If the PIN credential provider isn't selected, expand the **Sign-in options** link, and select the PIN pad icon 1. If the PIN credential provider isn't 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 **I forgot my PIN** from the PIN credential provider
@ -235,9 +239,9 @@ For Hybrid Azure AD-joined devices:
1. When finished, unlock your desktop using your newly created PIN 1. When finished, unlock your desktop using your newly created PIN
> [!NOTE] > [!NOTE]
> Key trust on hybrid Azure AD-joined devices doesn't 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. > Key trust on Microsoft Entra hybrid joined devices doesn't 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.
You may find that PIN reset from Settings only works post sign in. Also, the lock screen PIN reset function doesn't work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen](/azure/active-directory/authentication/howto-sspr-windows#general-limitations). You may find that PIN reset from Settings only works post sign in. Also, the lock screen PIN reset function doesn't work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Microsoft Entra self-service password reset at the Windows sign-in screen](/azure/active-directory/authentication/howto-sspr-windows#general-limitations).
<!--links--> <!--links-->

4
windows/security/identity-protection/hello-for-business/hello-feature-remote-desktop.md
View File

@ -12,7 +12,7 @@ ms.collection:
**Requirements** **Requirements**
- Hybrid and On-premises Windows Hello for Business deployments - Hybrid and On-premises Windows Hello for Business deployments
- Azure AD joined, Hybrid Azure AD joined, and Enterprise joined devices - Microsoft Entra joined, Microsoft Entra hybrid joined, and Enterprise joined devices
Windows Hello for Business supports using a certificate deployed to a Windows Hello for Business container as a supplied credential to establish a remote desktop connection to a server or another device. This feature takes advantage of the redirected smart card capabilities of the remote desktop protocol. Windows Hello for Business key trust can be used with [Remote Credential Guard](../remote-credential-guard.md) to establish a remote desktop protocol connection. Windows Hello for Business supports using a certificate deployed to a Windows Hello for Business container as a supplied credential to establish a remote desktop connection to a server or another device. This feature takes advantage of the redirected smart card capabilities of the remote desktop protocol. Windows Hello for Business key trust can be used with [Remote Credential Guard](../remote-credential-guard.md) to establish a remote desktop protocol connection.
@ -23,7 +23,7 @@ Microsoft continues to investigate supporting using keys trust for supplied cred
**Requirements** **Requirements**
- Hybrid and On-premises Windows Hello for Business deployments - Hybrid and On-premises Windows Hello for Business deployments
- Azure AD joined, Hybrid Azure AD joined, and Enterprise joined devices - Microsoft Entra joined, Microsoft Entra hybrid joined, and Enterprise joined devices
- Biometric enrollments - Biometric enrollments
The ability for users to authenticate to a remote desktop session using their Windows Hello for Business biometric is on by default. The ability for users to authenticate to a remote desktop session using their Windows Hello for Business biometric is on by default.

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

@ -6,75 +6,87 @@ ms.topic: reference
--- ---
# Windows Hello for Business authentication # Windows Hello for Business authentication
Windows Hello for Business authentication is a passwordless, two-factor authentication. Authenticating with Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Azure Active Directory and Active Directory resources. Windows Hello for Business authentication is a passwordless, two-factor authentication. Authenticating with Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Microsoft Entra ID and Active Directory resources.
Azure AD-joined devices authenticate to Azure AD during sign-in and can, optionally, authenticate to Active Directory. Hybrid Azure AD-joined devices authenticate to Active Directory during sign-in, and authenticate to Azure AD in the background. Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in and can, optionally, authenticate to Active Directory. Microsoft Entra hybrid joined devices authenticate to Active Directory during sign-in, and authenticate to Microsoft Entra ID in the background.
## Azure AD join authentication to Azure AD <a name='azure-ad-join-authentication-to-azure-ad'></a>
![Azure AD join authentication to Azure Active Directory.](images/howitworks/auth-aadj-cloud.png) ## Microsoft Entra join authentication to Microsoft Entra ID
![Microsoft Entra join authentication to Microsoft Entra ID.](images/howitworks/auth-aadj-cloud.png)
> [!NOTE] > [!NOTE]
> All Azure AD-joined devices authenticate with Windows Hello for Business to Azure AD the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD. > All Microsoft Entra joined devices authenticate with Windows Hello for Business to Microsoft Entra ID the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD.
| Phase | Description | | Phase | Description |
| :----: | :----------- | | :----: | :----------- |
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.| |A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider.|
|B | The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory.| |B | The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID.|
|C | Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature. Azure AD then validates the returned signed nonce, and creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.| |C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. Microsoft Entra ID then validates the returned signed nonce, and creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.|
|D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.| |D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| |E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
## Azure AD join authentication to Active Directory using cloud Kerberos trust <a name='azure-ad-join-authentication-to-active-directory-using-cloud-kerberos-trust'></a>
![Azure Active Directory join authentication to Azure AD.](images/howitworks/auth-aadj-cloudtrust-kerb.png) ## Microsoft Entra join authentication to Active Directory using cloud Kerberos trust
![Microsoft Entra join authentication to Azure AD.](images/howitworks/auth-aadj-cloudtrust-kerb.png)
| Phase | Description | | Phase | Description |
| :----: | :----------- | | :----: | :----------- |
|A | Authentication to Active Directory from an Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. |A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller.
|B | After locating a domain controller, the Kerberos provider sends a partial TGT that it received from Azure AD from a previous Azure AD authentication to the domain controller. The partial TGT contains only the user SID, and it's signed by Azure AD Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client.| |B | After locating a domain controller, the Kerberos provider sends a partial TGT that it received from Microsoft Entra ID from a previous Microsoft Entra authentication to the domain controller. The partial TGT contains only the user SID, and it's signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client.|
## Azure AD join authentication to Active Directory using a key <a name='azure-ad-join-authentication-to-active-directory-using-a-key'></a>
![Azure AD join authentication to Active Directory using a Key.](images/howitworks/auth-aadj-keytrust-kerb.png) ## Microsoft Entra join authentication to Active Directory using a key
![Microsoft Entra join authentication to Active Directory using a Key.](images/howitworks/auth-aadj-keytrust-kerb.png)
| Phase | Description | | Phase | Description |
| :----: | :----------- | | :----: | :----------- |
|A | Authentication to Active Directory from an Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.| |A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.<br>The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| |B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.<br>The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.| |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
> [!NOTE] > [!NOTE]
> You might have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Azure AD joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins. > You might have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Microsoft Entra joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins.
## Azure AD join authentication to Active Directory using a certificate <a name='azure-ad-join-authentication-to-active-directory-using-a-certificate'></a>
![Azure AD join authentication to Active Directory using a Certificate.](images/howitworks/auth-aadj-certtrust-kerb.png) ## Microsoft Entra join authentication to Active Directory using a certificate
![Microsoft Entra join authentication to Active Directory using a Certificate.](images/howitworks/auth-aadj-certtrust-kerb.png)
| Phase | Description | | Phase | Description |
| :----: | :----------- | | :----: | :----------- |
|A | Authentication to Active Directory from an Azure AD joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos preauthentication data.| |A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses information from the certificate to get a hint of the user's domain. Kerberos can use the distinguished name of the user found in the subject of the certificate, or it can use the user principal name of the user found in the subject alternate name of the certificate. Using the hint, the provider uses the DClocator service to locate a domain controller. After the provider locates an active domain controller, the provider uses the private key to sign the Kerberos preauthentication data.|
|B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| |B | The Kerberos provider sends the signed preauthentication data and user's certificate, which includes the public key, to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.<br>The domain controller determines the certificate isn't self-signed certificate. The domain controller ensures the certificate chains to trusted root certificate, is within its validity period, can be used for authentication, and hasn't been revoked. It retrieves the public key and UPN from the certificate included in the KERB_AS_REQ and searches for the UPN in Active Directory. It validates the signed preauthentication data using the public key from the certificate. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.| |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
> [!NOTE] > [!NOTE]
> You may have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation. > You may have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.
## Hybrid Azure AD join authentication using cloud Kerberos trust <a name='hybrid-azure-ad-join-authentication-using-cloud-kerberos-trust'></a>
![Hybrid Azure AD join authentication using Azure AD Kerberos](images/howitworks/auth-haadj-cloudtrust.png) ## Microsoft Entra hybrid join authentication using cloud Kerberos trust
![Microsoft Entra hybrid join authentication using Microsoft Entra Kerberos](images/howitworks/auth-haadj-cloudtrust.png)
| Phase | Description | | Phase | Description |
| :----: | :----------- | | :----: | :----------- |
|A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Azure Active Directory. Azure AD returns a nonce. |A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.
|B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Azure AD. |B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Microsoft Entra ID.
|C | Azure AD validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Azure AD Kerberos and returns them to Cloud AP. |C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Microsoft Entra Kerberos and returns them to Cloud AP.
|D | Cloud AP receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT. |D | Cloud AP receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT.
|E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After locating an active 2016 domain controller, the Kerberos provider sends the partial TGT that it received from Azure AD to the domain controller. The partial TGT contains only the user SID and is signed by Azure AD Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| |E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After locating an active 2016 domain controller, the Kerberos provider sends the partial TGT that it received from Microsoft Entra ID to the domain controller. The partial TGT contains only the user SID and is signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
## Hybrid Azure AD join authentication using a key <a name='hybrid-azure-ad-join-authentication-using-a-key'></a>
![Hybrid Azure AD join authentication using a key.](images/howitworks/auth-haadj-keytrust.png) ## Microsoft Entra hybrid join authentication using a key
![Microsoft Entra hybrid join authentication using a key.](images/howitworks/auth-haadj-keytrust.png)
| Phase | Description | | Phase | Description |
| :----: | :----------- | | :----: | :----------- |
@ -83,15 +95,17 @@ Azure AD-joined devices authenticate to Azure AD during sign-in and can, optiona
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating.
|D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.| |D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| |E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce.| |F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory. Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.| |G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
> [!IMPORTANT] > [!IMPORTANT]
> In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time. > In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time.
## Hybrid Azure AD join authentication using a certificate <a name='hybrid-azure-ad-join-authentication-using-a-certificate'></a>
![Hybrid Azure AD join authentication using a Certificate.](images/howitworks/auth-haadj-certtrust.png) ## Microsoft Entra hybrid join authentication using a certificate
![Microsoft Entra hybrid join authentication using a Certificate.](images/howitworks/auth-haadj-certtrust.png)
| Phase | Description | | Phase | Description |
| :----: | :----------- | | :----: | :----------- |
@ -100,8 +114,8 @@ Azure AD-joined devices authenticate to Azure AD during sign-in and can, optiona
|C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating.
|D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.| |D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.|
|E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| |E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
|F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Azure Active Directory. Azure AD returns a nonce.| |F | While Windows loads the user's desktop, lsass passes the collected credentials to the Cloud Authentication security support provider, referred to as the Cloud AP provider. The Cloud AP provider requests a nonce from Microsoft Entra ID. Microsoft Entra ID returns a nonce.|
|G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Azure Active Directory. Azure Active Directory validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.| |G | The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.<br>The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.<br>The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT.|
> [!IMPORTANT] > [!IMPORTANT]
> In the above deployment model, a **newly provisioned** user will not be able to sign in using Windows Hello for Business unless the device has line of sight to the domain controller. > In the above deployment model, a **newly provisioned** user will not be able to sign in using Windows Hello for Business unless the device has line of sight to the domain controller.

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

@ -8,100 +8,110 @@ ms.topic: overview
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 Azure Active Directory - How the device is joined to Microsoft Entra ID
- The Windows Hello for Business deployment type - The Windows Hello for Business deployment type
- If the environment is managed or federated - If the environment is managed or federated
List of provisioning flows: List of provisioning flows:
- [Azure AD joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment) - [Microsoft Entra joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment)
- [Azure AD joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment) - [Microsoft Entra joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)
- [Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment) - [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
- [Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment) - [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
- [Hybrid Azure AD joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment) - [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
- [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment) - [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)
- [Domain joined provisioning in an On-premises certificate trust deployment](#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment) - [Domain joined provisioning in an On-premises certificate trust deployment](#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment)
> [!NOTE] > [!NOTE]
> The flows in this section are not exhaustive for every possible scenario. For example, Federated Key Trust is also a supported configuration. > The flows in this section are not exhaustive for every possible scenario. For example, Federated Key Trust is also a supported configuration.
## Azure AD joined provisioning in a managed environment <a name='azure-ad-joined-provisioning-in-a-managed-environment'></a>
![Azure AD joined provisioning in a managed environment.](images/howitworks/prov-aadj-managed.png) ## Microsoft Entra joined provisioning in a managed environment
![Microsoft Entra joined provisioning in a managed environment.](images/howitworks/prov-aadj-managed.png)
[Full size image](images/howitworks/prov-aadj-managed.png) [Full size image](images/howitworks/prov-aadj-managed.png)
| Phase | Description | | 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 Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. | | A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).| |B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure 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. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits.| |C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application which signals the end of user provisioning and the application exits.|
[Return to top](#windows-hello-for-business-provisioning) [Return to top](#windows-hello-for-business-provisioning)
## Azure AD joined provisioning in a federated environment <a name='azure-ad-joined-provisioning-in-a-federated-environment'></a>
![Azure AD joined provisioning in federated environment.](images/howitworks/prov-aadj-federated.png) ## Microsoft Entra joined provisioning in a federated environment
![Microsoft Entra joined provisioning in federated environment.](images/howitworks/prov-aadj-federated.png)
[Full size image](images/howitworks/prov-aadj-federated.png) [Full size image](images/howitworks/prov-aadj-federated.png)
| Phase | Description | | 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 Azure Active Directory Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Azure Active Directory.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. | | A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).| |B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure 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. Azure Active Directory returns key ID to the application which signals the end of user provisioning and the application exits.| |C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns key ID to the application which signals the end of user provisioning and the application exits.|
[Return to top](#windows-hello-for-business-provisioning) [Return to top](#windows-hello-for-business-provisioning)
## Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment <a name='hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment'></a>
![Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a Managed environment.](images/howitworks/prov-haadj-cloudtrust-managed.png) ## Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment
![Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a Managed environment.](images/howitworks/prov-haadj-cloudtrust-managed.png)
[Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png) [Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png)
| Phase | Description | | 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 Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. | | A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). | | B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure 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. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. | | 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] > [!NOTE]
> Windows Hello for Business cloud Kerberos trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to Azure Active Directory and AD after provisioning their credential. > Windows Hello for Business cloud Kerberos trust does not require users' keys to be synced from Microsoft Entra ID to Active Directory. Users can immediately authenticate to Microsoft Entra ID and AD after provisioning their credential.
[Return to top](#windows-hello-for-business-provisioning) [Return to top](#windows-hello-for-business-provisioning)
## Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment <a name='hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment'></a>
![Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment.](images/howitworks/prov-haadj-keytrust-managed.png) ## Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment
![Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment.](images/howitworks/prov-haadj-keytrust-managed.png)
[Full size image](images/howitworks/prov-haadj-keytrust-managed.png) [Full size image](images/howitworks/prov-haadj-keytrust-managed.png)
| Phase | Description | | 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 Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. | | A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). | | B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure 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. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. | | 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 | Azure AD Connect requests updates on its next synchronization cycle. Azure Active Directory sends the user's public key that was securely registered through provisioning. Azure Active Directory Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. | | 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] > [!IMPORTANT]
> The newly provisioned user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory. > The newly provisioned user will not be able to sign in using Windows Hello for Business until Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory.
[Return to top](#windows-hello-for-business-provisioning) [Return to top](#windows-hello-for-business-provisioning)
## Hybrid Azure AD joined provisioning in a synchronous certificate trust deployment in a federated environment <a name='hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment'></a>
![Hybrid Azure AD joined provisioning in a synchronous Certificate trust deployment in a federated environment.](images/howitworks/prov-haadj-instant-certtrust-federated.png) ## Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment
![Microsoft Entra hybrid joined provisioning in a synchronous Certificate trust deployment in a federated environment.](images/howitworks/prov-haadj-instant-certtrust-federated.png)
[Full size image](images/howitworks/prov-haadj-instant-certtrust-federated.png) [Full size image](images/howitworks/prov-haadj-instant-certtrust-federated.png)
| Phase | Description | | 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 Azure Active Directory Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Azure Active Directory.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. | | A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Microsoft Entra ID.<br>Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). | | B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure 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. Azure Active Directory returns a key ID and a key receipt to the application, which represents the end of user key registration. | | 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. | | D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys. |
| E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. | | E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. |
| F | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. | | 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] > [!IMPORTANT]
> Synchronous certificate enrollment does not depend on Azure AD 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. Azure AD Connect continues to synchronize the public key to Active Directory, but is not shown in this flow. > Synchronous certificate enrollment does not depend on Microsoft Entra Connect to synchronize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Microsoft Entra Connect continues to synchronize the public key to Active Directory, but is not shown in this flow.
[Return to top](#windows-hello-for-business-provisioning) [Return to top](#windows-hello-for-business-provisioning)
## Domain joined provisioning in an On-premises Key Trust deployment ## Domain joined provisioning in an On-premises Key Trust deployment
@ -110,7 +120,7 @@ List of provisioning flows:
| Phase | Description | | 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 Azure Active Directory Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise DRS token on successful MFA.| |A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise DRS token on successful MFA.|
| B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).| | B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|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.| |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.|
@ -122,7 +132,7 @@ List of provisioning flows:
| Phase | Description | | 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 Azure Active Directory Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise DRS token on successful MFA.| |A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues an enterprise DRS token on successful MFA.|
| B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).| | B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|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.| |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.| |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.|

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

@ -32,32 +32,44 @@ In the issued AIK certificate, a special OID is added to attest that endorsement
- [Windows client certificate enrollment protocol: glossary](/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_70efa425-6b46-462f-911d-d399404529ab) - [Windows client certificate enrollment protocol: glossary](/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_70efa425-6b46-462f-911d-d399404529ab)
- [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/) - [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
## Azure Active Directory join <a name='azure-active-directory-join'></a>
Azure Active Directory (Azure AD) join is intended for organizations that desire to be cloud-first or cloud-only. There's no restriction on the size or type of organizations that can deploy Azure AD join. Azure AD join also works in a hybrid environment and can enable access to on-premises applications and resources. ## Microsoft Entra join
### Related to Azure AD join Microsoft Entra join is intended for organizations that desire to be cloud-first or cloud-only. There's no restriction on the size or type of organizations that can deploy Microsoft Entra join. Microsoft Entra join also works in a hybrid environment and can enable access to on-premises applications and resources.
<a name='related-to-azure-ad-join'></a>
### Related to Microsoft Entra join
- [Join type](#join-type) - [Join type](#join-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join) - [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
### More information about Azure AD join <a name='more-information-about-azure-ad-join'></a>
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview). ### More information about Microsoft Entra join
## Azure AD registration [Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview).
The goal of Azure AD-registered devices is to provide you with support for the _bring your own device_ (BYOD) scenario. In this scenario, a user can access your organization's Azure AD-controlled resources using a personal device. <a name='azure-ad-registration'></a>
### Related to Azure AD registration ## Microsoft Entra registration
- [Azure AD join](#azure-active-directory-join) The goal of Microsoft Entra registered devices is to provide you with support for the _bring your own device_ (BYOD) scenario. In this scenario, a user can access your organization's Microsoft Entra ID-controlled resources using a personal device.
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
<a name='related-to-azure-ad-registration'></a>
### Related to Microsoft Entra registration
- [Microsoft Entra join](#azure-active-directory-join)
- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Join type](#join-type) - [Join type](#join-type)
### More information about Azure AD registration <a name='more-information-about-azure-ad-registration'></a>
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview). ### More information about Microsoft Entra registration
[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview).
## Certificate trust ## Certificate trust
@ -66,7 +78,7 @@ The certificate trust model uses a securely issued certificate based on the user
### Related to certificate trust ### Related to certificate trust
- [Deployment type](#deployment-type) - [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join) - [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment) - [Hybrid deployment](#hybrid-deployment)
- [Cloud Kerberos trust](#cloud-kerberos-trust) - [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Key trust](#key-trust) - [Key trust](#key-trust)
@ -79,18 +91,18 @@ The certificate trust model uses a securely issued certificate based on the user
## Cloud deployment ## Cloud deployment
The Windows Hello for Business cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Azure AD-joined or Azure AD-registered devices. The Windows Hello for Business cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Microsoft Entra joined or Microsoft Entra registered devices.
### Related to cloud deployment ### Related to cloud deployment
- [Azure AD join](#azure-active-directory-join) - [Microsoft Entra join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration) - [Microsoft Entra registration](#azure-ad-registration)
- [Deployment type](#deployment-type) - [Deployment type](#deployment-type)
- [Join type](#join-type) - [Join type](#join-type)
## Cloud experience host ## Cloud experience host
In Windows 10 and Windows 11, cloud experience host is an application used while joining the workplace environment or Azure AD for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Azure AD, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC. In Windows 10 and Windows 11, cloud experience host is an application used while joining the workplace environment or Microsoft Entra ID for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Microsoft Entra ID, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC.
### Related to cloud experience host ### Related to cloud experience host
@ -111,7 +123,7 @@ Giving the simplicity offered by this model, cloud Kerberos trust is the recomme
### Related to cloud Kerberos trust ### Related to cloud Kerberos trust
- [Deployment type](#deployment-type) - [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join) - [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment) - [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust) - [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment) - [On-premises deployment](#on-premises-deployment)
@ -168,7 +180,7 @@ For certain devices that use firmware-based TPM produced by Intel or Qualcomm, t
## Federated environment ## Federated environment
Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Azure AD and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they don't have to sign in again to use Microsoft cloud services. This federated authentication model can provide extra authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Azure AD. Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Microsoft Entra ID and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they don't have to sign in again to use Microsoft cloud services. This federated authentication model can provide extra authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Microsoft Entra ID.
### Related to federated environment ### Related to federated environment
@ -179,9 +191,11 @@ Primarily for large enterprise organizations with more complex authentication re
### More information about federated environment ### More information about federated environment
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn) [Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Hybrid Azure AD join <a name='hybrid-azure-ad-join'></a>
## Microsoft Entra hybrid join
For more than a decade, many organizations have used the domain join to their on-premises Active Directory to enable: For more than a decade, many organizations have used the domain join to their on-premises Active Directory to enable:
@ -190,27 +204,31 @@ For more than a decade, many organizations have used the domain join to their on
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy to manage them. Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy to manage them.
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure AD, you can implement hybrid Azure AD-joined devices. These devices are joined to both your on-premises Active Directory and your Azure AD. If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Microsoft Entra ID, you can implement Microsoft Entra hybrid joined devices. These devices are joined to both your on-premises Active Directory and your Microsoft Entra ID.
### Related to hybrid Azure AD join <a name='related-to-hybrid-azure-ad-join'></a>
- [Azure AD join](#azure-active-directory-join) ### Related to Microsoft Entra hybrid join
- [Azure AD registration](#azure-ad-registration)
- [Microsoft Entra join](#azure-active-directory-join)
- [Microsoft Entra registration](#azure-ad-registration)
- [Hybrid deployment](#hybrid-deployment) - [Hybrid deployment](#hybrid-deployment)
### More information about hybrid Azure AD join <a name='more-information-about-hybrid-azure-ad-join'></a>
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview) ### More information about Microsoft Entra hybrid join
[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview)
## Hybrid deployment ## Hybrid deployment
The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that's synchronized with Azure AD. Hybrid deployments support devices that are Azure AD-registered, Azure AD-joined, and hybrid Azure AD-joined. The Hybrid deployment model supports three trust types for on-premises authentication: cloud Kerberos trust, key trust and certificate trust. The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that's synchronized with Microsoft Entra ID. Hybrid deployments support devices that are Microsoft Entra registered, Microsoft Entra joined, and Microsoft Entra hybrid joined. The Hybrid deployment model supports three trust types for on-premises authentication: cloud Kerberos trust, key trust and certificate trust.
### Related to hybrid deployment ### Related to hybrid deployment
- [Azure AD join](#azure-active-directory-join) - [Microsoft Entra join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration) - [Microsoft Entra registration](#azure-ad-registration)
- [Hybrid Azure AD join](#hybrid-azure-ad-join) - [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
### More information about hybrid deployment ### More information about hybrid deployment
@ -218,23 +236,23 @@ The Windows Hello for Business hybrid deployment is for organizations that have
## Join type ## Join type
Join type is how devices are associated with Azure AD. For a device to authenticate to Azure AD it must be registered or joined. Join type is how devices are associated with Microsoft Entra ID. For a device to authenticate to Microsoft Entra it must be registered or joined.
Registering a device to Azure AD enables you to manage a device's identity. When a device is registered, Azure AD device registration provides the device with an identity that is used to authenticate the device when a user signs-in to Azure AD. You can use the identity to enable or disable a device. Registering a device to Microsoft Entra ID enables you to manage a device's identity. When a device is registered, Microsoft Entra device registration provides the device with an identity that is used to authenticate the device when a user signs-in to Microsoft Entra ID. You can use the identity to enable or disable a device.
When combined with a mobile device management (MDM) solution such as Microsoft Intune, the device attributes in Azure AD are updated with additional information about the device. This behavior allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune. When combined with a mobile device management (MDM) solution such as Microsoft Intune, the device attributes in Microsoft Entra ID are updated with additional information about the device. This behavior allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune.
Joining a device is an extension to registering a device. This method provides you with all the benefits of registering a device, and changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account. Joining a device is an extension to registering a device. This method provides you with all the benefits of registering a device, and changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account.
### Related to join type ### Related to join type
- [Azure AD join](#azure-active-directory-join) - [Microsoft Entra join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration) - [Microsoft Entra registration](#azure-ad-registration)
- [Hybrid Azure AD join](#hybrid-azure-ad-join) - [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
### More information about join type ### More information about join type
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview) [Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview)
## Key trust ## Key trust
@ -245,7 +263,7 @@ The key trust model uses the user's Windows Hello for Business identity to authe
- [Cloud Kerberos trust](#cloud-kerberos-trust) - [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Certificate trust](#certificate-trust) - [Certificate trust](#certificate-trust)
- [Deployment type](#deployment-type) - [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join) - [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment) - [Hybrid deployment](#hybrid-deployment)
- [On-premises deployment](#on-premises-deployment) - [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type) - [Trust type](#trust-type)
@ -256,7 +274,7 @@ The key trust model uses the user's Windows Hello for Business identity to authe
## Managed environment ## Managed environment
Managed environments are for non-federated environments where Azure AD manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services (ADFS). Managed environments are for non-federated environments where Microsoft Entra ID manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services (ADFS).
### Related to managed environment ### Related to managed environment
@ -280,7 +298,7 @@ The Windows Hello for Business on-premises deployment is for organizations that
## Pass-through authentication ## Pass-through authentication
Pass-through authentication provides a simple password validation for Azure AD authentication services. It uses a software agent that runs on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Azure AD and manage your users on-premises. Allows your users to sign in to both on-premises and Microsoft cloud resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Azure AD. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network. Pass-through authentication provides a simple password validation for Microsoft Entra authentication services. It uses a software agent that runs on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Microsoft Entra ID and manage your users on-premises. Allows your users to sign in to both on-premises and Microsoft cloud resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Microsoft Entra ID. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Microsoft Entra ID when they are on their corporate devices and connected to your corporate network.
### Related to pass-through authentication ### Related to pass-through authentication
@ -290,11 +308,11 @@ Pass-through authentication provides a simple password validation for Azure AD a
### More information about pass-through authentication ### More information about pass-through authentication
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn) [Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Password hash sync ## Password hash sync
Password hash sync is the simplest way to enable authentication for on-premises directory objects in Azure AD. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Azure AD and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Azure AD so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Azure AD so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Azure AD or stored in Azure AD in clear text. Some premium features of Azure AD, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network. Password hash sync is the simplest way to enable authentication for on-premises directory objects in Microsoft Entra ID. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Microsoft Entra ID and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Microsoft Entra ID so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Microsoft Entra ID so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Microsoft Entra ID or stored in Microsoft Entra ID in clear text. Some premium features of Microsoft Entra ID, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Microsoft Entra ID when they are on their corporate devices and connected to your corporate network.
### Related to password hash sync ### Related to password hash sync
@ -304,13 +322,13 @@ Password hash sync is the simplest way to enable authentication for on-premises
### More information about password hash sync ### More information about password hash sync
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn) [Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Primary refresh token ## Primary refresh token
Single sign on (SSO) relies on special tokens obtained for each of the types of applications above. These special tokens are then used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications, this token is a _primary refresh token_ (PRT). It's a [JSON Web Token](https://openid.net/specs/draft-jones-json-web-token-07.html) that contains claims about both the user and the device. Single sign on (SSO) relies on special tokens obtained for each of the types of applications above. These special tokens are then used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Microsoft Entra ID and AD FS applications, this token is a _primary refresh token_ (PRT). It's a [JSON Web Token](https://openid.net/specs/draft-jones-json-web-token-07.html) that contains claims about both the user and the device.
The PRT is initially obtained during Windows user sign-in or unlock in a similar way the Kerberos TGT is obtained. This behavior is true for both Azure AD joined and hybrid Azure AD-joined devices. For personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account. For a personal device the account to unlock the device isn't the work account, but a consumer account. For example, hotmail.com, live.com, or outlook.com. The PRT is initially obtained during Windows user sign-in or unlock in a similar way the Kerberos TGT is obtained. This behavior is true for both Microsoft Entra joined and Microsoft Entra hybrid joined devices. For personal devices registered with Microsoft Entra ID, the PRT is initially obtained upon Add Work or School Account. For a personal device the account to unlock the device isn't the work account, but a consumer account. For example, hotmail.com, live.com, or outlook.com.
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. The PRT also contains information about the device. If you have any [device-based conditional access](/azure/active-directory/conditional-access/concept-conditional-access-grant) policy set on an application, without the PRT, access will be denied. The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. The PRT also contains information about the device. If you have any [device-based conditional access](/azure/active-directory/conditional-access/concept-conditional-access-grant) policy set on an application, without the PRT, access will be denied.
@ -330,7 +348,7 @@ The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of
## Trust type ## Trust type
The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type doesn't affect authentication to Azure AD. Windows Hello for Business authentication to Azure AD always uses the key, not a certificate (excluding smart card authentication in a federated environment). The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type doesn't affect authentication to Microsoft Entra ID. Windows Hello for Business authentication to Microsoft Entra ID always uses the key, not a certificate (excluding smart card authentication in a federated environment).
### Related to trust type ### Related to trust type

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

@ -6,7 +6,7 @@ ms.topic: overview
--- ---
# How Windows Hello for Business works in Windows Devices # How Windows Hello for Business works in Windows Devices
Windows Hello for Business is a two-factor credential that is a more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Azure Active Directory-joined, Hybrid Azure Active Directory-joined, or Azure AD registered devices. Windows Hello for Business also works for domain joined devices. Windows Hello for Business is a two-factor credential that is a more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Microsoft Entra joined, Microsoft Entra hybrid joined, or Microsoft Entra registered devices. Windows Hello for Business also works for domain joined devices.
Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business works and some of its supporting features. Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business works and some of its supporting features.
> [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8] > [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8]
@ -17,7 +17,7 @@ Windows Hello for Business is a distributed system that uses several components
### Device Registration ### Device Registration
Registration is a fundamental prerequisite for Windows Hello for Business. Without registration, Windows Hello for Business provisioning cannot start. Registration is where the device **registers** its identity with the identity provider. For cloud and hybrid deployments, the identity provider is Azure Active Directory and the device registers with the Azure Device Registration Service (ADRS). For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the device registers with the enterprise device registration service hosted on the federation servers (AD FS). Registration is a fundamental prerequisite for Windows Hello for Business. Without registration, Windows Hello for Business provisioning cannot start. Registration is where the device **registers** its identity with the identity provider. For cloud and hybrid deployments, the identity provider is Microsoft Entra ID and the device registers with the Azure Device Registration Service (ADRS). For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the device registers with the enterprise device registration service hosted on the federation servers (AD FS).
For more information, read [how device registration works](/azure/active-directory/devices/device-registration-how-it-works). For more information, read [how device registration works](/azure/active-directory/devices/device-registration-how-it-works).

80
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
View File

@ -1,6 +1,6 @@
--- ---
title: Use Certificates to enable SSO for Azure AD join devices title: Use Certificates to enable SSO for Microsoft Entra join devices
description: If you want to use certificates for on-premises single-sign on for Azure Active Directory-joined devices, then follow these additional steps. description: If you want to use certificates for on-premises single-sign on for Microsoft Entra joined devices, then follow these additional steps.
ms.date: 08/19/2018 ms.date: 08/19/2018
ms.topic: how-to ms.topic: how-to
--- ---
@ -9,14 +9,14 @@ ms.topic: how-to
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust-aad.md)] [!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust-aad.md)]
If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Azure AD-joined devices. If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Microsoft Entra joined devices.
> [!IMPORTANT] > [!IMPORTANT]
> Ensure you have performed the configurations in [Azure AD-joined devices for On-premises Single-Sign On](/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso) before you continue. > Ensure you have performed the configurations in [Microsoft Entra joined devices for On-premises Single-Sign On](/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso) before you continue.
Steps you'll perform include: Steps you'll perform include:
- [Prepare Azure AD Connect](#prepare-azure-ad-connect) - [Prepare Microsoft Entra Connect](#prepare-azure-ad-connect)
- [Prepare the Network Device Enrollment Services Service Account](#prepare-the-network-device-enrollment-services-ndes-service-account) - [Prepare the Network Device Enrollment Services Service Account](#prepare-the-network-device-enrollment-services-ndes-service-account)
- [Prepare Active Directory Certificate Services](#prepare-active-directory-certificate-authority) - [Prepare Active Directory Certificate Services](#prepare-active-directory-certificate-authority)
- [Install the Network Device Enrollment Services Role](#install-and-configure-the-ndes-role) - [Install the Network Device Enrollment Services Role](#install-and-configure-the-ndes-role)
@ -26,7 +26,7 @@ Steps you'll perform include:
## Requirements ## Requirements
You need to install and configure additional infrastructure to provide Azure AD-joined devices with on-premises single-sign on. You need to install and configure additional infrastructure to provide Microsoft Entra joined devices with on-premises single-sign on.
- An existing Windows Server 2012 R2 or later Enterprise Certificate Authority - An existing Windows Server 2012 R2 or later Enterprise Certificate Authority
- A Windows Server 2012 R2 domain joined server that hosts the Network Device Enrollment Services role - A Windows Server 2012 R2 domain joined server that hosts the Network Device Enrollment Services role
@ -43,29 +43,33 @@ The Network Device Enrollment Service (NDES) server role can issue up to three u
- Encryption - Encryption
- Signature and Encryption - Signature and Encryption
If you need to deploy more than three types of certificates to the Azure AD joined device, you need additional NDES servers. Alternatively, consider consolidating certificate templates to reduce the number of certificate templates. If you need to deploy more than three types of certificates to the Microsoft Entra joined device, you need additional NDES servers. Alternatively, consider consolidating certificate templates to reduce the number of certificate templates.
### Network Requirements ### Network Requirements
All communication occurs securely over port 443. All communication occurs securely over port 443.
## Prepare Azure AD Connect <a name='prepare-azure-ad-connect'></a>
## Prepare Microsoft Entra Connect
Successful authentication to on-premises resources using a certificate requires the certificate to provide a hint about the on-premises domain. The hint can be the user's Active Directory distinguished name as the subject of the certificate, or the hint can be the user's user principal name where the suffix matches the Active Directory domain name. Successful authentication to on-premises resources using a certificate requires the certificate to provide a hint about the on-premises domain. The hint can be the user's Active Directory distinguished name as the subject of the certificate, or the hint can be the user's user principal name where the suffix matches the Active Directory domain name.
Most environments change the user principal name suffix to match the organization's external domain name (or vanity domain), which prevents the user principal name as a hint to locate a domain controller. Therefore, the certificate needs the user's on-premises distinguished name in the subject to properly locate a domain controller. Most environments change the user principal name suffix to match the organization's external domain name (or vanity domain), which prevents the user principal name as a hint to locate a domain controller. Therefore, the certificate needs the user's on-premises distinguished name in the subject to properly locate a domain controller.
To include the on-premises distinguished name in the certificate's subject, Azure AD Connect must replicate the Active Directory **distinguishedName** attribute to the Azure Active Directory **onPremisesDistinguishedName** attribute. Azure AD Connect version 1.1.819 includes the proper synchronization rules needed for these attributes. To include the on-premises distinguished name in the certificate's subject, Microsoft Entra Connect must replicate the Active Directory **distinguishedName** attribute to the Microsoft Entra ID **onPremisesDistinguishedName** attribute. Microsoft Entra Connect version 1.1.819 includes the proper synchronization rules needed for these attributes.
### Verify Azure Active Directory Connect version <a name='verify-azure-active-directory-connect-version'></a>
Sign-in to computer running Azure AD Connect with access equivalent to _local administrator_. ### Verify Microsoft Entra Connect version
1. Open **Synchronization Services** from the **Azure AD Connect** folder. Sign-in to computer running Microsoft Entra Connect with access equivalent to _local administrator_.
1. Open **Synchronization Services** from the **Microsoft Entra Connect** folder.
2. In the **Synchronization Service Manager**, select **Help** and then select **About**. 2. In the **Synchronization Service Manager**, select **Help** and then select **About**.
3. If the version number isn't **1.1.819** or later, then upgrade Azure AD Connect to the latest version. 3. If the version number isn't **1.1.819** or later, then upgrade Microsoft Entra Connect to the latest version.
### Verify the onPremisesDistinguishedName attribute is synchronized ### Verify the onPremisesDistinguishedName attribute is synchronized
@ -80,7 +84,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync
3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You'll now be prompted for delegated permissions consent. 3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You'll now be prompted for delegated permissions consent.
4. In the Graph Explorer URL, enter `https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName`, where **[userid]** is the user principal name of a user in Azure Active Directory. Select **Run query**. 4. In the Graph Explorer URL, enter `https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName`, where **[userid]** is the user principal name of a user in Microsoft Entra ID. Select **Run query**.
> [!NOTE] > [!NOTE]
> Because the v1.0 endpoint of the Graph API only provides a limited set of parameters, we will use the $select [Optional OData query parameter](/graph/api/user-get?). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios. > Because the v1.0 endpoint of the Graph API only provides a limited set of parameters, we will use the $select [Optional OData query parameter](/graph/api/user-get?). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios.
@ -232,7 +236,7 @@ You must prepare the public key infrastructure and the issuing certificate autho
- Configure the certificate authority to let Intune provide validity periods - Configure the certificate authority to let Intune provide validity periods
- Create an NDES-Intune Authentication Certificate template - Create an NDES-Intune Authentication Certificate template
- Create an Azure AD joined Windows Hello for Business authentication certificate template - Create a Microsoft Entra joined Windows Hello for Business authentication certificate template
- Publish certificate templates - Publish certificate templates
### Configure the certificate authority to let Intune provide validity periods ### Configure the certificate authority to let Intune provide validity periods
@ -283,7 +287,9 @@ Sign-in to the issuing certificate authority or management workstations with _Do
11. Select on the **Apply** to save changes and close the console. 11. Select on the **Apply** to save changes and close the console.
### Create an Azure AD joined Windows Hello for Business authentication certificate template <a name='create-an-azure-ad-joined-windows-hello-for-business-authentication-certificate-template'></a>
### Create a Microsoft Entra joined Windows Hello for Business authentication certificate template
During Windows Hello for Business provisioning, Windows requests an authentication certificate from Microsoft Intune, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You use the name of the certificate template when configuring the NDES Server. During Windows Hello for Business provisioning, Windows requests an authentication certificate from Microsoft Intune, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You use the name of the certificate template when configuring the NDES Server.
@ -455,13 +461,13 @@ Sign-in a domain controller with a minimum access equivalent to _Domain Admins_.
5. Select **Add**. 5. Select **Add**.
6. Select **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Azure AD-joined devices. From the **Available services** list, select **HOST**. Select **OK**. 6. Select **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Microsoft Entra joined devices. From the **Available services** list, select **HOST**. Select **OK**.
![NDES Service delegation to NDES host.](images/aadjcert/ndessvcdelegation-host-ndes-spn.png) ![NDES Service delegation to NDES host.](images/aadjcert/ndessvcdelegation-host-ndes-spn.png)
7. Repeat steps 5 and 6 for each NDES server using this service account. Select **Add**. 7. Repeat steps 5 and 6 for each NDES server using this service account. Select **Add**.
8. Select **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Azure AD-joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Select **OK**. 8. Select **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Microsoft Entra joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Select **OK**.
9. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request certificates. 9. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request certificates.
@ -534,7 +540,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
1. Open an elevated command prompt. 1. Open an elevated command prompt.
2. Using the table above, decide which registry value name you'll use to request Windows Hello for Business authentication certificates for Azure AD-joined devices. 2. Using the table above, decide which registry value name you'll use to request Windows Hello for Business authentication certificates for Microsoft Entra joined devices.
3. Type the following command: 3. Type the following command:
@ -542,7 +548,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d [certificateTemplateName] reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d [certificateTemplateName]
``` ```
where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Azure AD-joined devices. Example: where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Microsoft Entra joined devices. Example:
```console ```console
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d AADJWHFBAuthentication reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d AADJWHFBAuthentication
@ -557,13 +563,13 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
### Create a Web Application Proxy for the internal NDES URL. ### Create a Web Application Proxy for the internal NDES URL.
Certificate enrollment for Azure AD-joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy. Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services. Certificate enrollment for Microsoft Entra joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Microsoft Entra application proxy. Microsoft Entra application proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.
Ideally, you configure your Microsoft Intune SCEP certificate profile to use multiple external NDES URLs. This enables Microsoft Intune to round-robin load balance the certificate requests to identically configured NDES Servers (each NDES server can accommodate approximately 300 concurrent requests). Microsoft Intune sends these requests to Azure AD Application Proxies. Ideally, you configure your Microsoft Intune SCEP certificate profile to use multiple external NDES URLs. This enables Microsoft Intune to round-robin load balance the certificate requests to identically configured NDES Servers (each NDES server can accommodate approximately 300 concurrent requests). Microsoft Intune sends these requests to Microsoft Entra Application Proxies.
Azure AD Application proxies are serviced by lightweight Application Proxy Connector agents. See [What is Application Proxy](/azure/active-directory/manage-apps/application-proxy#what-is-application-proxy) for more details. These agents are installed on your on-premises, domain joined devices and make authenticated secure outbound connection to Azure, waiting to process requests from Azure AD Application Proxies. You can create connector groups in Azure Active Directory to assign specific connectors to service specific applications. Microsoft Entra Application proxies are serviced by lightweight Application Proxy Connector agents. See [What is Application Proxy](/azure/active-directory/manage-apps/application-proxy#what-is-application-proxy) for more details. These agents are installed on your on-premises, domain joined devices and make authenticated secure outbound connection to Azure, waiting to process requests from Microsoft Entra Application Proxies. You can create connector groups in Microsoft Entra ID to assign specific connectors to service specific applications.
Connector group automatically round-robin, load balance the Azure AD Application proxy requests to the connectors within the assigned connector group. This ensures Windows Hello for Business certificate requests have multiple dedicated Azure AD Application Proxy connectors exclusively available to satisfy enrollment requests. Load balancing the NDES servers and connectors should ensure users enroll their Windows Hello for Business certificates in a timely manner. Connector group automatically round-robin, load balance the Microsoft Entra application proxy requests to the connectors within the assigned connector group. This ensures Windows Hello for Business certificate requests have multiple dedicated Microsoft Entra application proxy connectors exclusively available to satisfy enrollment requests. Load balancing the NDES servers and connectors should ensure users enroll their Windows Hello for Business certificates in a timely manner.
#### Download and Install the Application Proxy Connector Agent #### Download and Install the Application Proxy Connector Agent
@ -571,7 +577,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**. 1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, select **Azure Active Directory**. 2. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**.
3. Under **MANAGE**, select **Application proxy**. 3. Under **MANAGE**, select **Application proxy**.
@ -582,7 +588,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
5. Sign-in the computer that will run the connector with access equivalent to a _domain user_. 5. Sign-in the computer that will run the connector with access equivalent to a _domain user_.
> [!IMPORTANT] > [!IMPORTANT]
> Install a minimum of two Azure Active Directory Proxy connectors for each NDES Application Proxy. Strategically locate Azure AD application proxy connectors throughout your organization to ensure maximum availability. Remember, devices running the connector must be able to communicate with Azure and the on-premises NDES servers. > Install a minimum of two Microsoft Entra ID Proxy connectors for each NDES Application Proxy. Strategically locate Microsoft Entra application proxy connectors throughout your organization to ensure maximum availability. Remember, devices running the connector must be able to communicate with Azure and the on-premises NDES servers.
6. Start **AADApplicationProxyConnectorInstaller.exe**. 6. Start **AADApplicationProxyConnectorInstaller.exe**.
@ -598,7 +604,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
![Azure Application Proxy Connector: read](images/aadjcert/azureappproxyconnectorinstall-03.png) ![Azure Application Proxy Connector: read](images/aadjcert/azureappproxyconnectorinstall-03.png)
10. Repeat steps 5 - 10 for each device that will run the Azure AD Application Proxy connector for Windows Hello for Business certificate deployments. 10. Repeat steps 5 - 10 for each device that will run the Microsoft Entra application proxy connector for Windows Hello for Business certificate deployments.
#### Create a Connector Group #### Create a Connector Group
@ -606,7 +612,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**. 1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, select **Azure Active Directory**. 2. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**.
3. Under **MANAGE**, select **Application proxy**. 3. Under **MANAGE**, select **Application proxy**.
@ -626,17 +632,17 @@ Sign-in a workstation with access equivalent to a _domain user_.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**. 1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, select **Azure Active Directory**. 2. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**.
3. Under **MANAGE**, select **Application proxy**. 3. Under **MANAGE**, select **Application proxy**.
4. Select **Configure an app**. 4. Select **Configure an app**.
5. Under **Basic Settings** next to **Name**, type **WHFB NDES 01**. Choose a name that correlates this Azure AD Application Proxy setting with the on-premises NDES server. Each NDES server must have its own Azure AD Application Proxy as two NDES servers can't share the same internal URL. 5. Under **Basic Settings** next to **Name**, type **WHFB NDES 01**. Choose a name that correlates this Microsoft Entra application proxy setting with the on-premises NDES server. Each NDES server must have its own Microsoft Entra application proxy as two NDES servers can't share the same internal URL.
6. Next to **Internal URL**, type the internal, fully qualified DNS name of the NDES server associated with this Azure AD Application Proxy. For example, ```https://ndes.corp.mstepdemo.net```. You need to match the primary host name (AD Computer Account name) of the NDES server, and prefix the URL with **https**. 6. Next to **Internal URL**, type the internal, fully qualified DNS name of the NDES server associated with this Microsoft Entra application proxy. For example, ```https://ndes.corp.mstepdemo.net```. You need to match the primary host name (AD Computer Account name) of the NDES server, and prefix the URL with **https**.
7. Under **Internal URL**, select **https://** from the first list. In the text box next to **https://**, type the hostname you want to use as your external hostname for the Azure AD Application Proxy. In the list next to the hostname you typed, select a DNS suffix you want to use externally for the Azure AD Application Proxy. It's recommended to use the default, -[tenantName].msapproxy.net where **[tenantName]** is your current Azure Active Directory tenant name (-mstephendemo.msappproxy.net). 7. Under **Internal URL**, select **https://** from the first list. In the text box next to **https://**, type the hostname you want to use as your external hostname for the Microsoft Entra application proxy. In the list next to the hostname you typed, select a DNS suffix you want to use externally for the Microsoft Entra application proxy. It's recommended to use the default, -[tenantName].msapproxy.net where **[tenantName]** is your current Microsoft Entra tenant name (-mstephendemo.msappproxy.net).
![Azure NDES Application Proxy Configuration.](images/aadjcert/azureconsole-appproxyconfig.png) ![Azure NDES Application Proxy Configuration.](images/aadjcert/azureconsole-appproxyconfig.png)
@ -681,7 +687,7 @@ Sign-in the NDES server with access equivalent to _local administrators_.
10. Select **Enroll** 10. Select **Enroll**
11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Azure AD-joined devices. 11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Microsoft Entra joined devices.
### Configure the Web Server Role ### Configure the Web Server Role
@ -824,7 +830,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**. 1. Sign-in to the [Azure portal](https://portal.azure.com/) with access equivalent to **Global Administrator**.
2. Select **All Services**. Type **Azure Active Directory** to filter the list of services. Under **SERVICES**, select **Azure Active Directory**. 2. Select **All Services**. Type **Microsoft Entra ID** to filter the list of services. Under **SERVICES**, select **Microsoft Entra ID**.
3. Select **Groups**. Select **New group**. 3. Select **Groups**. Select **New group**.
@ -836,7 +842,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
7. Select **Assigned** from the **Membership type** list. 7. Select **Assigned** from the **Membership type** list.
![Azure AD new group creation.](images/aadjcert/azureadcreatewhfbcertgroup.png) ![Microsoft Entra new group creation.](images/aadjcert/azureadcreatewhfbcertgroup.png)
8. Select **Members**. Use the **Select members** pane to add members to this group. When finished, select **Select**. 8. Select **Members**. Use the **Select members** pane to add members to this group. When finished, select **Select**.
@ -889,7 +895,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
![WHFB SCEP certificate Profile EKUs.](images/aadjcert/profile03.png) ![WHFB SCEP certificate Profile EKUs.](images/aadjcert/profile03.png)
17. Under **SCEP Server URLs**, type the fully qualified external name of the Azure AD Application proxy you configured. Append to the name **/certsrv/mscep/mscep.dll**. For example, ```https://ndes-mtephendemo.msappproxy.net/certsrv/mscep/mscep.dll```. Select **Add**. Repeat this step for each additional NDES Azure AD Application Proxy you configured to issue Windows Hello for Business certificates. Microsoft Intune round-robin load balances requests among the URLs listed in the SCEP certificate profile. 17. Under **SCEP Server URLs**, type the fully qualified external name of the Microsoft Entra application proxy you configured. Append to the name **/certsrv/mscep/mscep.dll**. For example, ```https://ndes-mtephendemo.msappproxy.net/certsrv/mscep/mscep.dll```. Select **Add**. Repeat this step for each additional NDES Microsoft Entra application proxy you configured to issue Windows Hello for Business certificates. Microsoft Intune round-robin load balances requests among the URLs listed in the SCEP certificate profile.
18. Select **Next**. 18. Select **Next**.
@ -924,7 +930,7 @@ You have successfully completed the configuration. Add users that need to enrol
> [!div class="checklist"] > [!div class="checklist"]
> - Requirements > - Requirements
> - Prepare Azure AD Connect > - Prepare Microsoft Entra Connect
> - Prepare the Network Device Enrollment Services (NDES) Service Account > - Prepare the Network Device Enrollment Services (NDES) Service Account
> - Prepare Active Directory Certificate Authority > - Prepare Active Directory Certificate Authority
> - Install and Configure the NDES Role > - Install and Configure the NDES Role

30
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
View File

@ -1,21 +1,21 @@
--- ---
title: Configure single sign-on (SSO) for Azure AD joined devices title: Configure single sign-on (SSO) for Microsoft Entra joined devices
description: Learn how to configure single sign-on to on-premises resources for Azure AD-joined devices, using Windows Hello for Business. description: Learn how to configure single sign-on to on-premises resources for Microsoft Entra joined devices, using Windows Hello for Business.
ms.date: 12/30/2022 ms.date: 12/30/2022
ms.topic: how-to ms.topic: how-to
--- ---
# Configure single sign-on for Azure AD joined devices # Configure single sign-on for Microsoft Entra joined devices
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-keycert-trust-aad.md)] [!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-keycert-trust-aad.md)]
Windows Hello for Business combined with Azure AD-joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD-joined devices may need to access these resources. With additional configurations to the hybrid deployment, you can provide single sign-on to on-premises resources for Azure AD-joined devices using Windows Hello for Business, using a key or a certificate. Windows Hello for Business combined with Microsoft Entra joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Microsoft Entra joined devices may need to access these resources. With additional configurations to the hybrid deployment, you can provide single sign-on to on-premises resources for Microsoft Entra joined devices using Windows Hello for Business, using a key or a certificate.
> [!NOTE] > [!NOTE]
> These steps are not needed when using the cloud Kerberos trust model. > These steps are not needed when using the cloud Kerberos trust model.
## Prerequisites ## Prerequisites
Unlike hybrid Azure AD-joined devices, Azure AD-joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices: Unlike Microsoft Entra hybrid joined devices, Microsoft Entra joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Microsoft Entra joined devices:
> [!div class="checklist"] > [!div class="checklist"]
> - Certificate Revocation List (CRL) Distribution Point > - Certificate Revocation List (CRL) Distribution Point
@ -29,9 +29,9 @@ During certificate validation, Windows compares the current certificate with inf
![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png) ![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png)
The preceding domain controller certificate shows a *CRL distribution point* (CDP) in Active Directory. The value in the URL begins with *ldap*. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure AD joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated. The preceding domain controller certificate shows a *CRL distribution point* (CDP) in Active Directory. The value in the URL begins with *ldap*. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Microsoft Entra joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
To resolve this issue, the CRL distribution point must be a location accessible by Azure AD joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS). To resolve this issue, the CRL distribution point must be a location accessible by Microsoft Entra joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first, in the list of distribution points. If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first, in the list of distribution points.
@ -40,11 +40,11 @@ If your CRL distribution point doesn't list an HTTP distribution point, then you
### Domain controller certificates ### Domain controller certificates
Certificate authorities write CDP information in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CDP. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory. Certificate authorities write CDP information in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CDP. The domain controller certificate is one the critical components of Microsoft Entra joined devices authenticating to Active Directory.
#### Why does Windows need to validate the domain controller certificate? #### Why does Windows need to validate the domain controller certificate?
Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on an Azure AD joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met: Windows Hello for Business enforces the strict KDC validation security feature when authenticating from a Microsoft Entra joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on a Microsoft Entra joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met:
- The domain controller has the private key for the certificate provided - The domain controller has the private key for the certificate provided
- The root CA that issued the domain controller's certificate is in the device's *Trusted Root Certificate Authorities* - The root CA that issued the domain controller's certificate is in the device's *Trusted Root Certificate Authorities*
@ -54,7 +54,7 @@ Windows Hello for Business enforces the strict KDC validation security feature w
- The domain controller's certificate's signature hash algorithm is **sha256** - The domain controller's certificate's signature hash algorithm is **sha256**
- The domain controller's certificate's public key is **RSA (2048 Bits)** - The domain controller's certificate's public key is **RSA (2048 Bits)**
Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the *KDC Authentication* EKU. If you're adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the *KDC Authentication* EKU. Authenticating from a Microsoft Entra hybrid joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the *KDC Authentication* EKU. If you're adding Microsoft Entra joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the *KDC Authentication* EKU.
## Configure a CRL distribution point for an issuing CA ## Configure a CRL distribution point for an issuing CA
@ -62,7 +62,7 @@ Use this set of procedures to update the CA that issues domain controller certif
### Configure Internet Information Services to host CRL distribution point ### Configure Internet Information Services to host CRL distribution point
You need to host your new certificate revocation list on a web server so Azure AD-joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point. You need to host your new certificate revocation list on a web server so Microsoft Entra joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point.
> [!IMPORTANT] > [!IMPORTANT]
> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http. > Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http.
@ -217,9 +217,11 @@ With the CA properly configured with a valid HTTP-based CRL distribution point,
1. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK** 1. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK**
![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png) ![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png)
## Deploy the root CA certificate to Azure AD-joined devices <a name='deploy-the-root-ca-certificate-to-azure-ad-joined-devices'></a>
The domain controllers have a certificate that includes the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails. ## Deploy the root CA certificate to Microsoft Entra joined devices
The domain controllers have a certificate that includes the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Microsoft Entra joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Microsoft Entra joined devices don't trust domain controller certificates and authentication fails.
### Export the enterprise root certificate ### Export the enterprise root certificate
@ -250,4 +252,4 @@ To configure devices with Microsoft Intune, use a custom policy:
1. Under **Assignment**, select a security group that contains as members the devices or users that you want to configure > **Next** 1. Under **Assignment**, select a security group that contains as members the devices or users that you want to configure > **Next**
1. Review the policy configuration and select **Create** 1. Review the policy configuration and select **Create**
If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). Otherwise, you can sign in to an Azure AD joined device with Windows Hello for Business and test SSO to an on-premises resource. If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). Otherwise, you can sign in to a Microsoft Entra joined device with Windows Hello for Business and test SSO to an on-premises resource.

8
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md
View File

@ -25,12 +25,12 @@ Hybrid certificate trust deployments issue users a sign-in certificate, enabling
[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)] [!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
> [!NOTE] > [!NOTE]
> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. > Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for Microsoft Entra hybrid joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Microsoft Entra joined devices.
> [!IMPORTANT] > [!IMPORTANT]
> For Azure AD joined devices to authenticate to on-premises resources, ensure to: > For Microsoft Entra joined devices to authenticate to on-premises resources, ensure to:
> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune > - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune
> - Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL > - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL
[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] [!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
@ -54,7 +54,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
1. Close the console 1. Close the console
> [!IMPORTANT] > [!IMPORTANT]
> If you plan to deploy **Azure AD joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md). > If you plan to deploy **Microsoft Entra joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md).
## Configure and deploy certificates to domain controllers ## Configure and deploy certificates to domain controllers

50
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md
View File

@ -15,7 +15,7 @@ ms.topic: how-to
[!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-cert-trust.md)] [!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-cert-trust.md)]
Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources. Hybrid environments are distributed systems that enable organizations to use on-premises and Microsoft Entra protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources.
This deployment guide describes how to deploy Windows Hello for Business in a hybrid certificate trust scenario. This deployment guide describes how to deploy Windows Hello for Business in a hybrid certificate trust scenario.
@ -29,10 +29,10 @@ The following prerequisites must be met for a hybrid certificate trust deploymen
> [!div class="checklist"] > [!div class="checklist"]
> * Directories and directory synchronization > * Directories and directory synchronization
> * Federated authentication to Azure AD > * Federated authentication to Microsoft Entra ID
> * Device registration > * Device registration
> * Public Key Infrastructure > * Public Key Infrastructure
> * Multi-factor authentication > * Multifactor authentication
> * Device management > * Device management
### Directories and directory synchronization ### Directories and directory synchronization
@ -40,21 +40,23 @@ The following prerequisites must be met for a hybrid certificate trust deploymen
Hybrid Windows Hello for Business needs two directories: Hybrid Windows Hello for Business needs two directories:
- An on-premises Active Directory - An on-premises Active Directory
- An Azure Active Directory tenant with an Azure AD Premium subscription - A Microsoft Entra tenant with a Microsoft Entra ID P1 or P2 subscription
The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD. The two directories must be synchronized with [Microsoft Entra Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Microsoft Entra ID.
The hybrid-certificate trust deployment needs an *Azure Active Directory Premium* subscription because it uses the device write-back synchronization feature. The hybrid-certificate trust deployment needs an *Microsoft Entra ID P1 or P2* subscription because it uses the device write-back synchronization feature.
> [!NOTE] > [!NOTE]
> Windows Hello for Business hybrid certificate trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD. > Windows Hello for Business hybrid certificate trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Microsoft Entra ID.
> [!IMPORTANT] > [!IMPORTANT]
> Windows Hello for Business is tied between a user and a device. Both the user and device object must be synchronized between Azure Active Directory and Active Directory. > Windows Hello for Business is tied between a user and a device. Both the user and device object must be synchronized between Microsoft Entra ID and Active Directory.
### Federated authentication to Azure AD <a name='federated-authentication-to-azure-ad'></a>
Windows Hello for Business hybrid certificate trust doesn't support Azure AD *Pass-through Authentication* (PTA) or *password hash sync* (PHS).\ ### Federated authentication to Microsoft Entra ID
Windows Hello for Business hybrid certificate trust requires Active Directory to be federated with Azure Active Directory using AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices.
Windows Hello for Business hybrid certificate trust doesn't support Microsoft Entra ID *Pass-through Authentication* (PTA) or *password hash sync* (PHS).\
Windows Hello for Business hybrid certificate trust requires Active Directory to be federated with Microsoft Entra ID using AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices.
If you're new to AD FS and federation services: If you're new to AD FS and federation services:
@ -69,18 +71,18 @@ The AD FS farm used with Windows Hello for Business must be Windows Server 2016
### Device registration and device write-back ### Device registration and device write-back
Windows devices must be registered in Azure AD. Devices can be registered in Azure AD using either *Azure AD join* or *hybrid Azure AD join*.\ Windows devices must be registered in Microsoft Entra ID. Devices can be registered in Microsoft Entra ID using either *Microsoft Entra join* or *Microsoft Entra hybrid join*.\
For hybrid Azure AD joined devices, review the guidance on the [plan your hybrid Azure Active Directory join implementation][AZ-8] page. For Microsoft Entra hybrid joined devices, review the guidance on the [plan your Microsoft Entra hybrid join implementation][AZ-8] page.
Refer to the [Configure hybrid Azure Active Directory join for federated domains][AZ-10] guide to learn more about using Azure AD Connect Sync to configure Azure AD device registration.\ Refer to the [Configure Microsoft Entra hybrid join for federated domains][AZ-10] guide to learn more about using Microsoft Entra Connect Sync to configure Microsoft Entra device registration.\
For a **manual configuration** of your AD FS farm to support device registration, review the [Configure AD FS for Azure AD device registration][AZ-11] guide. For a **manual configuration** of your AD FS farm to support device registration, review the [Configure AD FS for Microsoft Entra device registration][AZ-11] guide.
Hybrid certificate trust deployments require the *device write-back* feature. Authentication to AD FS needs both the user and the device to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the device and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device write-back. Hybrid certificate trust deployments require the *device write-back* feature. Authentication to AD FS needs both the user and the device to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the device and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device write-back.
> [!NOTE] > [!NOTE]
> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Azure Active Directory and Active Directory. Device write-back is used to update the *msDS-KeyCredentialLink* attribute on the computer object. > Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Microsoft Entra ID and Active Directory. Device write-back is used to update the *msDS-KeyCredentialLink* attribute on the computer object.
If you manually configured AD FS, or if you ran Azure AD Connect Sync using *Custom Settings*, you must ensure that you have configured **device write-back** and **device authentication** in your AD FS farm. For more information, see [Configure Device Write Back and Device Authentication][SER-5]. If you manually configured AD FS, or if you ran Microsoft Entra Connect Sync using *Custom Settings*, you must ensure that you have configured **device write-back** and **device authentication** in your AD FS farm. For more information, see [Configure Device Write Back and Device Authentication][SER-5].
### Public Key Infrastructure ### Public Key Infrastructure
@ -89,16 +91,18 @@ The enterprise PKI and a certificate registration authority (CRA) are required t
During Windows Hello for Business provisioning, users receive a sign-in certificate through the CRA. During Windows Hello for Business provisioning, users receive a sign-in certificate through the CRA.
### Multi-factor authentication <a name='multi-factor-authentication'></a>
### Multifactor authentication
The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication.\ The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication.\
Hybrid deployments can use: Hybrid deployments can use:
- [Azure AD Multi-Factor Authentication][AZ-2] - [Microsoft Entra multifactor authentication][AZ-2]
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS - A multifactor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings][AZ-3].\ For more information how to configure Microsoft Entra multifactor authentication, see [Configure Microsoft Entra multifactor authentication settings][AZ-3].\
For more information how to configure AD FS to provide multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1]. For more information how to configure AD FS to provide multifactor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1].
### Device management ### Device management
@ -113,7 +117,7 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr
> * Configure AD FS > * Configure AD FS
> * Configure Windows Hello for Business settings > * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients > * Provision Windows Hello for Business on Windows clients
> * Configure single sign-on (SSO) for Azure AD joined devices > * Configure single sign-on (SSO) for Microsoft Entra joined devices
> [!div class="nextstepaction"] > [!div class="nextstepaction"]
> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-cert-trust-validate-pki.md) > [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-cert-trust-validate-pki.md)

18
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
View File

@ -16,9 +16,9 @@ After the prerequisites are met and the PKI and AD FS configurations are validat
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo) #### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
> [!IMPORTANT] > [!IMPORTANT]
> The information in this section applies to hybrid Azure AD joined devices only. > The information in this section applies to Microsoft Entra hybrid joined devices only.
For hybrid Azure AD joined devices, you can use group policies to configure Windows Hello for Business. For Microsoft Entra hybrid joined devices, you can use group policies to configure Windows Hello for Business.
It is suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign the **Group Policy** and **Certificate template permissions** to this group to simplify the deployment by adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate. It is suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign the **Group Policy** and **Certificate template permissions** to this group to simplify the deployment by adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
### Enable Windows Hello for Business group policy setting ### Enable Windows Hello for Business group policy setting
@ -95,11 +95,11 @@ Users (or devices) must receive the Windows Hello for Business group policy sett
## Configure Windows Hello for Business using Microsoft Intune ## Configure Windows Hello for Business using Microsoft Intune
> [!IMPORTANT] > [!IMPORTANT]
> The information in this section applies to Azure AD joined devices managed by Intune. Before proceeding, ensure that you completed the steps described in: > The information in this section applies to Microsoft Entra joined devices managed by Intune. Before proceeding, ensure that you completed the steps described in:
> - [Configure single sign-on for Azure AD joined devices](hello-hybrid-aadj-sso.md) > - [Configure single sign-on for Microsoft Entra joined devices](hello-hybrid-aadj-sso.md)
> - [Using Certificates for AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md) > - [Using Certificates for AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md)
For Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business. For Microsoft Entra joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
There are different ways to enable and configure Windows Hello for Business in Intune: There are different ways to enable and configure Windows Hello for Business in Intune:
@ -163,19 +163,19 @@ This is the process that occurs after a user signs in, to enroll in Windows Hell
1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK** 1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry 1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device 1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory 1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Microsoft Entra ID to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Microsoft Entra Connect synchronizes the user's key to Active Directory
:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business."::: :::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
> [!IMPORTANT] > [!IMPORTANT]
> The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889). > The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
> >
> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval. > The minimum time needed to synchronize the user's public key from Microsoft Entra ID to the on-premises Active Directory is 30 minutes. The Microsoft Entra Connect scheduler controls the synchronization interval.
> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources. > **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
> Read [Azure AD Connect sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization. > Read [Microsoft Entra Connect Sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization.
> >
> [!NOTE] > [!NOTE]
> Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users no longer need to wait for Azure AD Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers. > Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users no longer need to wait for Microsoft Entra Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers.
After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows send the certificate request to the AD FS server for certificate enrollment. After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows send the certificate request to the AD FS server for certificate enrollment.

32
windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust-provision.md
View File

@ -14,18 +14,20 @@ ms.topic: tutorial
Deploying Windows Hello for Business cloud Kerberos trust consists of two steps: Deploying Windows Hello for Business cloud Kerberos trust consists of two steps:
1. Set up Azure AD Kerberos. 1. Set up Microsoft Entra Kerberos.
1. Configure a Windows Hello for Business policy and deploy it to the devices. 1. Configure a Windows Hello for Business policy and deploy it to the devices.
### Deploy Azure AD Kerberos <a name='deploy-azure-ad-kerberos'></a>
If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Azure AD Kerberos in your hybrid environment. You don't need to redeploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business and you can skip this section. ### Deploy Microsoft Entra Kerberos
If you haven't deployed Azure AD Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Azure AD][AZ-2] documentation. This page includes information on how to install and use the Azure AD Kerberos PowerShell module. Use the module to create an Azure AD Kerberos Server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust. If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Microsoft Entra Kerberos in your hybrid environment. You don't need to redeploy or change your existing Microsoft Entra Kerberos deployment to support Windows Hello for Business and you can skip this section.
If you haven't deployed Microsoft Entra Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Microsoft Entra ID][AZ-2] documentation. This page includes information on how to install and use the Microsoft Entra Kerberos PowerShell module. Use the module to create a Microsoft Entra Kerberos server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust.
### Configure Windows Hello for Business policy ### Configure Windows Hello for Business policy
After setting up the Azure AD Kerberos object, Windows Hello for business cloud Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). After setting up the Microsoft Entra Kerberos object, Windows Hello for business cloud Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune) #### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
@ -99,7 +101,7 @@ To configure the cloud Kerberos trust policy:
- Value: **True** - Value: **True**
> [!IMPORTANT] > [!IMPORTANT]
> *Tenant ID* in the OMA-URI must be replaced with the tenant ID for your Azure AD tenant. See [How to find your Azure AD tenant ID][AZ-3] for instructions on looking up your tenant ID. > *Tenant ID* in the OMA-URI must be replaced with the tenant ID for your Microsoft Entra tenant. See [How to find your Microsoft Entra tenant ID][AZ-3] for instructions on looking up your tenant ID.
:::image type="content" alt-text ="Intune custom-device configuration policy creation" source="images/hello-cloud-trust-intune.png" lightbox="images/hello-cloud-trust-intune-large.png"::: :::image type="content" alt-text ="Intune custom-device configuration policy creation" source="images/hello-cloud-trust-intune.png" lightbox="images/hello-cloud-trust-intune-large.png":::
@ -107,7 +109,7 @@ To configure the cloud Kerberos trust policy:
#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo) #### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo)
Hybrid Azure AD joined organizations can use Windows Hello for Business Group Policy to manage the feature. Group Policy can be configured to enable users to enroll and use Windows Hello for Business. Microsoft Entra hybrid joined organizations can use Windows Hello for Business Group Policy to manage the feature. Group Policy can be configured to enable users to enroll and use Windows Hello for Business.
The Enable Windows Hello for Business Group Policy setting is used by Windows to determine if a user should attempt to enroll a credential. A user will only attempt enrollment if this policy is configured to enabled. The Enable Windows Hello for Business Group Policy setting is used by Windows to determine if a user should attempt to enroll a credential. A user will only attempt enrollment if this policy is configured to enabled.
@ -142,17 +144,17 @@ You can configure Windows Hello for Business cloud Kerberos trust using a Group
## Provision Windows Hello for Business ## Provision Windows Hello for Business
The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business *cloud Kerberos trust* adds a prerequisite check for Hybrid Azure AD-joined devices when cloud Kerberos trust is enabled by policy. The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business *cloud Kerberos trust* adds a prerequisite check for Microsoft Entra hybrid joined devices when cloud Kerberos trust is enabled by policy.
You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs** > **Microsoft** > **Windows**.\ You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs** > **Microsoft** > **Windows**.\
This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4]. This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4].
:::image type="content" alt-text="Cloud Kerberos trust prerequisite check in the user device registration log" source="images/cloud-trust-prereq-check.png" lightbox="images/cloud-trust-prereq-check.png"::: :::image type="content" alt-text="Cloud Kerberos trust prerequisite check in the user device registration log" source="images/cloud-trust-prereq-check.png" lightbox="images/cloud-trust-prereq-check.png":::
The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Azure AD Kerberos is set up for the user's domain and tenant. If Azure AD Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust isn't being enforced by policy or if the device is Azure AD joined. The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Microsoft Entra Kerberos is set up for the user's domain and tenant. If Microsoft Entra Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust isn't being enforced by policy or if the device is Microsoft Entra joined.
> [!NOTE] > [!NOTE]
> The cloud Kerberos trust prerequisite check isn't done on Azure AD-joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in, but won't have SSO to on-premises resources secured by Active Directory. > The cloud Kerberos trust prerequisite check isn't done on Microsoft Entra joined devices. If Microsoft Entra Kerberos isn't provisioned, a user on a Microsoft Entra joined device will still be able to sign in, but won't have SSO to on-premises resources secured by Active Directory.
### PIN Setup ### PIN Setup
@ -166,18 +168,18 @@ After a user signs in, this is the process that occurs to enroll in Windows Hell
### Sign-in ### Sign-in
Once a user has set up a PIN with cloud Kerberos trust, it can be used **immediately** for sign-in. On a Hybrid Azure AD joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity. Once a user has set up a PIN with cloud Kerberos trust, it can be used **immediately** for sign-in. On a Microsoft Entra hybrid joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity.
## Migrate from key trust deployment model to cloud Kerberos trust ## Migrate from key trust deployment model to cloud Kerberos trust
If you deployed Windows Hello for Business using the key trust model, and want to migrate to the cloud Kerberos trust model, follow these steps: If you deployed Windows Hello for Business using the key trust model, and want to migrate to the cloud Kerberos trust model, follow these steps:
1. [Set up Azure AD Kerberos in your hybrid environment](#deploy-azure-ad-kerberos). 1. [Set up Microsoft Entra Kerberos in your hybrid environment](#deploy-azure-ad-kerberos).
1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy). 1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy).
1. For Azure AD joined devices, sign out and sign in to the device using Windows Hello for Business. 1. For Microsoft Entra joined devices, sign out and sign in to the device using Windows Hello for Business.
> [!NOTE] > [!NOTE]
> For hybrid Azure AD joined devices, users must perform the first sign in with new credentials while having line of sight to a DC. > For Microsoft Entra hybrid joined devices, users must perform the first sign in with new credentials while having line of sight to a DC.
## Migrate from certificate trust deployment model to cloud Kerberos trust ## Migrate from certificate trust deployment model to cloud Kerberos trust
@ -193,7 +195,7 @@ If you deployed Windows Hello for Business using the certificate trust model, an
1. Provision Windows Hello for Business using a method of your choice. 1. Provision Windows Hello for Business using a method of your choice.
> [!NOTE] > [!NOTE]
> For hybrid Azure AD joined devices, users must perform the first sign-in with new credentials while having line of sight to a DC. > For Microsoft Entra hybrid joined devices, users must perform the first sign-in with new credentials while having line of sight to a DC.
## Frequently Asked Questions ## Frequently Asked Questions

34
windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
View File

@ -16,34 +16,36 @@ Windows Hello for Business replaces password sign-in with strong authentication,
The goal of Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of [*passwordless security key sign-in*][AZ-1] to Windows Hello for Business, and it can be used for new or existing Windows Hello for Business deployments. The goal of Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of [*passwordless security key sign-in*][AZ-1] to Windows Hello for Business, and it can be used for new or existing Windows Hello for Business deployments.
Windows Hello for Business cloud Kerberos trust uses *Azure AD Kerberos*, which enables a simpler deployment when compared to the *key trust model*: Windows Hello for Business cloud Kerberos trust uses *Microsoft Entra Kerberos*, which enables a simpler deployment when compared to the *key trust model*:
- No need to deploy a public key infrastructure (PKI) or to change an existing PKI - No need to deploy a public key infrastructure (PKI) or to change an existing PKI
- No need to synchronize public keys between Azure AD and Active Directory for users to access on-premises resources. There isn't any delay between the user's Windows Hello for Business provisioning, and being able to authenticate to Active Directory - No need to synchronize public keys between Microsoft Entra ID and Active Directory for users to access on-premises resources. There isn't any delay between the user's Windows Hello for Business provisioning, and being able to authenticate to Active Directory
- [Passwordless security key sign-in][AZ-1] can be deployed with minimal extra setup - [Passwordless security key sign-in][AZ-1] can be deployed with minimal extra setup
> [!NOTE] > [!NOTE]
> Windows Hello for Business cloud Kerberos trust is the recommended deployment model when compared to the *key trust model*. It is also the preferred deployment model if you do not need to support certificate authentication scenarios. > Windows Hello for Business cloud Kerberos trust is the recommended deployment model when compared to the *key trust model*. It is also the preferred deployment model if you do not need to support certificate authentication scenarios.
## Azure AD Kerberos and cloud Kerberos trust authentication <a name='azure-ad-kerberos-and-cloud-kerberos-trust-authentication'></a>
## Microsoft Entra Kerberos and cloud Kerberos trust authentication
*Key trust* and *certificate trust* use certificate authentication-based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires a PKI for DC certificates, and requires end-user certificates for certificate trust. *Key trust* and *certificate trust* use certificate authentication-based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires a PKI for DC certificates, and requires end-user certificates for certificate trust.
Cloud Kerberos trust uses Azure AD Kerberos, which doesn't require a PKI to request TGTs.\ Cloud Kerberos trust uses Microsoft Entra Kerberos, which doesn't require a PKI to request TGTs.\
With Azure AD Kerberos, Azure AD can issue TGTs for one or more AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business, and use the returned TGT for sign-in or to access AD-based resources. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization. With Microsoft Entra Kerberos, Microsoft Entra ID can issue TGTs for one or more AD domains. Windows can request a TGT from Microsoft Entra ID when authenticating with Windows Hello for Business, and use the returned TGT for sign-in or to access AD-based resources. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization.
When Azure AD Kerberos is enabled in an Active Directory domain, an *AzureADKerberos* computer object is created in the domain. This object: When Microsoft Entra Kerberos is enabled in an Active Directory domain, an *AzureADKerberos* computer object is created in the domain. This object:
- Appears as a Read Only Domain Controller (RODC) object, but isn't associated with any physical servers - Appears as a Read Only Domain Controller (RODC) object, but isn't associated with any physical servers
- Is only used by Azure AD to generate TGTs for the Active Directory domain - Is only used by Microsoft Entra ID to generate TGTs for the Active Directory domain
> [!NOTE] > [!NOTE]
> Similar rules and restrictions used for RODCs apply to the AzureADKerberos computer object. For example, users that are direct or indirect members of priviliged built-in security groups won't be able to use cloud Kerberos trust. > Similar rules and restrictions used for RODCs apply to the AzureADKerberos computer object. For example, users that are direct or indirect members of priviliged built-in security groups won't be able to use cloud Kerberos trust.
:::image type="content" source="images/azuread-kerberos-object.png" alt-text="Active Directory Users and Computers console, showing the computer object representing the Azure AD Kerberos server "::: :::image type="content" source="images/azuread-kerberos-object.png" alt-text="Active Directory Users and Computers console, showing the computer object representing the Microsoft Entra Kerberos server ":::
For more information about how Azure AD Kerberos enables access to on-premises resources, see [enabling passwordless security key sign-in to on-premises resources][AZ-1].\ For more information about how Microsoft Entra Kerberos enables access to on-premises resources, see [enabling passwordless security key sign-in to on-premises resources][AZ-1].\
For more information about how Azure AD Kerberos works with Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-cloud-kerberos-trust). For more information about how Microsoft Entra Kerberos works with Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-cloud-kerberos-trust).
> [!IMPORTANT] > [!IMPORTANT]
> When implementing the cloud Kerberos trust deployment model, you *must* ensure that you have an adequate number of *read-write domain controllers* in each Active Directory site where users will be authenticating with Windows Hello for Business. For more information, see [Capacity planning for Active Directory][SERV-1]. > When implementing the cloud Kerberos trust deployment model, you *must* ensure that you have an adequate number of *read-write domain controllers* in each Active Directory site where users will be authenticating with Windows Hello for Business. For more information, see [Capacity planning for Active Directory][SERV-1].
@ -52,10 +54,10 @@ For more information about how Azure AD Kerberos works with Windows Hello for Bu
| Requirement | Notes | | Requirement | Notes |
| --- | --- | | --- | --- |
| Multi-factor Authentication | This requirement can be met using [Azure AD multi-factor authentication](/azure/active-directory/authentication/howto-mfa-getstarted), multi-factor authentication provided through AD FS, or a comparable solution. | | Multifactor authentication | This requirement can be met using [Microsoft Entra multifactor authentication](/azure/active-directory/authentication/howto-mfa-getstarted), multifactor authentication provided through AD FS, or a comparable solution. |
| Windows 10, version 21H2 or Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices. | | Windows 10, version 21H2 or Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Microsoft Entra joined and Microsoft Entra hybrid joined devices. |
| Windows Server 2016 or later Domain Controllers | If you're using Windows Server 2016, [KB3534307][SUP-1] must be installed. If you're using Server 2019, [KB4534321][SUP-2] must be installed. | | Windows Server 2016 or later Domain Controllers | If you're using Windows Server 2016, [KB3534307][SUP-1] must be installed. If you're using Server 2019, [KB4534321][SUP-2] must be installed. |
| Azure AD Kerberos PowerShell module | This module is used for enabling and managing Azure AD Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).| | Microsoft Entra Kerberos PowerShell module | This module is used for enabling and managing Microsoft Entra Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).|
| Device management | Windows Hello for Business cloud Kerberos trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. | | Device management | Windows Hello for Business cloud Kerberos trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. |
### Unsupported scenarios ### Unsupported scenarios
@ -65,19 +67,19 @@ The following scenarios aren't supported using Windows Hello for Business cloud
- On-premises only deployments - On-premises only deployments
- RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container) - RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container)
- Using cloud Kerberos trust for "Run as" - Using cloud Kerberos trust for "Run as"
- Signing in with cloud Kerberos trust on a Hybrid Azure AD joined device without previously signing in with DC connectivity - Signing in with cloud Kerberos trust on a Microsoft Entra hybrid joined device without previously signing in with DC connectivity
> [!NOTE] > [!NOTE]
> The default *Password Replication Policy* configured on the AzureADKerberos computer object doesn't allow to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys. > The default *Password Replication Policy* configured on the AzureADKerberos computer object doesn't allow to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys.
> >
> Due to possible attack vectors from Azure AD to Active Directory, it **isn't recommended** to unblock these accounts by relaxing the Password Replication Policy of the computer object `CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>`. > Due to possible attack vectors from Microsoft Entra ID to Active Directory, it **isn't recommended** to unblock these accounts by relaxing the Password Replication Policy of the computer object `CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>`.
## Next steps ## Next steps
Once the prerequisites are met, deploying Windows Hello for Business with a cloud Kerberos trust model consists of the following steps: Once the prerequisites are met, deploying Windows Hello for Business with a cloud Kerberos trust model consists of the following steps:
> [!div class="checklist"] > [!div class="checklist"]
> * Deploy Azure AD Kerberos > * Deploy Microsoft Entra Kerberos
> * Configure Windows Hello for Business settings > * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients > * Provision Windows Hello for Business on Windows clients

10
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md
View File

@ -15,7 +15,7 @@ After the prerequisites are met and the PKI configuration is validated, Windows
## Configure Windows Hello for Business using Microsoft Intune ## Configure Windows Hello for Business using Microsoft Intune
For Azure AD joined devices and hybrid Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business. For Microsoft Entra joined devices and Microsoft Entra hybrid joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
There are different ways to enable and configure Windows Hello for Business in Intune: There are different ways to enable and configure Windows Hello for Business in Intune:
@ -66,7 +66,7 @@ To configure Windows Hello for Business using an *account protection* policy:
## Configure Windows Hello for Business using group policies ## Configure Windows Hello for Business using group policies
For hybrid Azure AD joined devices, you can use group policies to configure Windows Hello for Business. For Microsoft Entra hybrid joined devices, you can use group policies to configure Windows Hello for Business.
It's suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign **Group Policy permissions** to this group to simplify the deployment by adding the users to the group. It's suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign **Group Policy permissions** to this group to simplify the deployment by adding the users to the group.
The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory
@ -144,14 +144,14 @@ The following process occurs after a user signs in, to enroll in Windows Hello f
1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK** 1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**
1. The enrollment flow proceeds to the multi-factor authentication phase. The process informs the user that there's an MFA contact attempt, using the configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry 1. The enrollment flow proceeds to the multi-factor authentication phase. The process informs the user that there's an MFA contact attempt, using the configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device 1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory 1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Microsoft Entra ID to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Microsoft Entra Connect synchronizes the user's key to Active Directory
:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business."::: :::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business.":::
> [!IMPORTANT] > [!IMPORTANT]
> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval. > The minimum time needed to synchronize the user's public key from Microsoft Entra ID to the on-premises Active Directory is 30 minutes. The Microsoft Entra Connect scheduler controls the synchronization interval.
> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources. > **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources.
> Read [Azure AD Connect sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization. > Read [Microsoft Entra Connect Sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
<!--links--> <!--links-->
[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd [AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd

10
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md
View File

@ -16,7 +16,7 @@ ms.topic: tutorial
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers. Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers.
Key trust deployments do not need client-issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by *Azure AD Connect Sync*, which synchronizes the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink`). Key trust deployments do not need client-issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by *Microsoft Entra Connect Sync*, which synchronizes the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink`).
A Windows Server-based PKI or a third-party Enterprise certification authority can be used. The requirements for the domain controller certificate are shown below. For more details, see [Requirements for domain controller certificates from a third-party CA][SERV-1]. A Windows Server-based PKI or a third-party Enterprise certification authority can be used. The requirements for the domain controller certificate are shown below. For more details, see [Requirements for domain controller certificates from a third-party CA][SERV-1].
@ -49,12 +49,12 @@ Sign in using *Enterprise Administrator* equivalent credentials on a Windows Ser
[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)] [!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
> [!NOTE] > [!NOTE]
> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. > Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for Microsoft Entra hybrid joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Microsoft Entra joined devices.
> [!IMPORTANT] > [!IMPORTANT]
> For Azure AD joined devices to authenticate to on-premises resources, ensure to: > For Microsoft Entra joined devices to authenticate to on-premises resources, ensure to:
> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune > - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune
> - Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL > - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL
[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] [!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
@ -74,7 +74,7 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
1. Close the console 1. Close the console
> [!IMPORTANT] > [!IMPORTANT]
> If you plan to deploy **Azure AD joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md). > If you plan to deploy **Microsoft Entra joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md).
## Configure and deploy certificates to domain controllers ## Configure and deploy certificates to domain controllers

40
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
View File

@ -14,7 +14,7 @@ ms.topic: how-to
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)] [!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources. Hybrid environments are distributed systems that enable organizations to use on-premises and Microsoft Entra protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources.
This deployment guide describes how to deploy Windows Hello for Business in a hybrid key trust scenario. This deployment guide describes how to deploy Windows Hello for Business in a hybrid key trust scenario.
@ -29,10 +29,10 @@ The following prerequisites must be met for a hybrid key trust deployment:
> [!div class="checklist"] > [!div class="checklist"]
> * Directories and directory synchronization > * Directories and directory synchronization
> * Authentication to Azure AD > * Authentication to Microsoft Entra ID
> * Device registration > * Device registration
> * Public Key Infrastructure > * Public Key Infrastructure
> * Multi-factor authentication > * Multifactor authentication
> * Device management > * Device management
### Directories and directory synchronization ### Directories and directory synchronization
@ -40,40 +40,44 @@ The following prerequisites must be met for a hybrid key trust deployment:
Hybrid Windows Hello for Business needs two directories: Hybrid Windows Hello for Business needs two directories:
- An on-premises Active Directory - An on-premises Active Directory
- An Azure Active Directory tenant - A Microsoft Entra tenant
The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.\ The two directories must be synchronized with [Microsoft Entra Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.\
During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Azure AD. *Azure AD Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory. During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Microsoft Entra ID. *Microsoft Entra Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory.
> [!NOTE] > [!NOTE]
> Windows Hello for Business hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD. > Windows Hello for Business hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Microsoft Entra ID.
### Authentication to Azure AD <a name='authentication-to-azure-ad'></a>
Authentication to Azure AD can be configured with or without federation: ### Authentication to Microsoft Entra ID
- [Password hash synchronization][AZ-6] or [Azure Active Directory pass-through-authentication][AZ-7] is required for non-federated environments Authentication to Microsoft Entra ID can be configured with or without federation:
- [Password hash synchronization][AZ-6] or [Microsoft Entra pass-through authentication][AZ-7] is required for non-federated environments
- Active Directory Federation Services (AD FS) or a third-party federation service is required for federated environments - Active Directory Federation Services (AD FS) or a third-party federation service is required for federated environments
### Device registration ### Device registration
The Windows devices must be registered in Azure AD. Devices can be registered in Azure AD using either *Azure AD join* or *hybrid Azure AD join*.\ The Windows devices must be registered in Microsoft Entra ID. Devices can be registered in Microsoft Entra ID using either *Microsoft Entra join* or *Microsoft Entra hybrid join*.\
For *hybrid Azure AD joined* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation][AZ-8] page. For *Microsoft Entra hybrid joined* devices, review the guidance on the [Plan your Microsoft Entra hybrid join implementation][AZ-8] page.
### Public Key Infrastructure ### Public Key Infrastructure
An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them. An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them.
### Multi-factor authentication <a name='multi-factor-authentication'></a>
### Multifactor authentication
The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication.\ The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication.\
Hybrid deployments can use: Hybrid deployments can use:
- [Azure AD Multi-Factor Authentication][AZ-2] - [Microsoft Entra multifactor authentication][AZ-2]
- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS - A multifactor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS
For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings][AZ-3].\ For more information how to configure Microsoft Entra multifactor authentication, see [Configure Microsoft Entra multifactor authentication settings][AZ-3].\
For more information how to configure AD FS to provide multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1]. For more information how to configure AD FS to provide multifactor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1].
### Device management ### Device management
@ -87,7 +91,7 @@ Once the prerequisites are met, deploying Windows Hello for Business with a hybr
> * Configure and validate the PKI > * Configure and validate the PKI
> * Configure Windows Hello for Business settings > * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients > * Provision Windows Hello for Business on Windows clients
> * Configure single sign-on (SSO) for Azure AD joined devices > * Configure single sign-on (SSO) for Microsoft Entra joined devices
> [!div class="nextstepaction"] > [!div class="nextstepaction"]
> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md) > [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md)

14
windows/security/identity-protection/hello-for-business/hello-identity-verification.md
View File

@ -17,12 +17,14 @@ appliesto:
This article lists the infrastructure requirements for the different deployment models for Windows Hello for Business. This article lists the infrastructure requirements for the different deployment models for Windows Hello for Business.
## Azure AD Cloud Only Deployment <a name='azure-ad-cloud-only-deployment'></a>
- Azure Active Directory ## Microsoft Entra Cloud Only Deployment
- Azure AD Multifactor Authentication
- Microsoft Entra ID
- Microsoft Entra multifactor authentication
- Device management solution (Intune or supported third-party MDM), *optional* - Device management solution (Intune or supported third-party MDM), *optional*
- Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory - Microsoft Entra ID P1 or P2 subscription - *optional*, needed for automatic MDM enrollment when the device joins Microsoft Entra ID
## Hybrid Deployments ## Hybrid Deployments
@ -37,8 +39,8 @@ The table shows the minimum requirements for each deployment. For key trust in a
| **Certificate Authority**| Not required |Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions | | **Certificate Authority**| Not required |Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions |
| **AD FS Version** | Not required | Not required | Any supported Windows Server versions | Any supported Windows Server versions | | **AD FS Version** | Not required | Not required | Any supported Windows Server versions | Any supported Windows Server versions |
| **MFA Requirement** | Azure MFA, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | | **MFA Requirement** | Azure MFA, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter |
| **Azure AD Connect** | Not required. It's recommended to use [Microsoft Entra Connect cloud sync](/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync) | Required | Required | Required | | **Microsoft Entra Connect** | Not required. It's recommended to use [Microsoft Entra Connect cloud sync](/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync) | Required | Required | Required |
| **Azure AD License** | Azure AD Premium, optional | Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional. Intune license required | | **Microsoft Entra ID license** | Microsoft Entra ID P1 or P2, optional | Microsoft Entra ID P1 or P2, optional | Microsoft Entra ID P1 or P2, needed for device write-back | Microsoft Entra ID P1 or P2, optional. Intune license required |
## On-premises Deployments ## On-premises Deployments

10
windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
View File

@ -1,6 +1,6 @@
--- ---
title: Validate and Deploy MFA for Windows Hello for Business with key trust title: Validate and Deploy MFA for Windows Hello for Business with key trust
description: Validate and deploy multi-factor authentication (MFA) for Windows Hello for Business in an on-premises key trust model. description: Validate and deploy multifactor authentication (MFA) for Windows Hello for Business in an on-premises key trust model.
ms.date: 09/07/2023 ms.date: 09/07/2023
appliesto: appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a> - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
@ -11,22 +11,22 @@ appliesto:
ms.topic: tutorial ms.topic: tutorial
--- ---
# Validate and deploy multi-factor authentication - on-premises key trust # Validate and deploy multifactor authentication - on-premises key trust
[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)] [!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)]
Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option: Windows Hello for Business requires users perform multifactor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
- certificates - certificates
- third-party authentication providers for AD FS - third-party authentication providers for AD FS
- custom authentication provider for AD FS - custom authentication provider for AD FS
> [!IMPORTANT] > [!IMPORTANT]
> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual. > As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multifactor authentication from their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
For information on available third-party authentication methods see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method) For information on available third-party authentication methods see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method)
Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies). Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multifactor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
> [!div class="nextstepaction"] > [!div class="nextstepaction"]
> [Next: configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md) > [Next: configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)

2
windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
View File

@ -13,7 +13,7 @@ ms.topic: reference
You can create a Group Policy or mobile device management (MDM) policy to configure Windows Hello for Business on Windows devices. You can create a Group Policy or mobile device management (MDM) policy to configure Windows Hello for Business on Windows devices.
>[!IMPORTANT] >[!IMPORTANT]
>Windows Hello as a convenience PIN is disabled by default on all domain joined and Azure AD joined devices. To enable a convenience PIN, enable the Group Policy setting **Turn on convenience PIN sign-in**. >Windows Hello as a convenience PIN is disabled by default on all domain joined and Microsoft Entra joined devices. To enable a convenience PIN, enable the Group Policy setting **Turn on convenience PIN sign-in**.
> >
>Use **PIN Complexity** policy settings to manage PINs for Windows Hello for Business. >Use **PIN Complexity** policy settings to manage PINs for Windows Hello for Business.