diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md b/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md index 57e428e8b6..c04d24c0e6 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md @@ -15,7 +15,7 @@ ms.collection: - highpri ms.topic: article localizationpriority: medium -ms.date: 01/21/2021 +ms.date: 02/15/2022 --- # Windows Hello for Business Deployment Overview @@ -28,10 +28,7 @@ Windows Hello for Business is the springboard to a world without passwords. It r This deployment overview is to guide you through deploying Windows Hello for Business. Your first step should be to use the Passwordless Wizard in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup) or the [Planning a Windows Hello for Business Deployment](hello-planning-guide.md) guide to determine the right deployment model for your organization. -Once you've chosen a deployment model, the deployment guide for the that model will provide you with the information needed to successfully deploy Windows Hello for Business in your environment. - -> [!NOTE] -> Read the [Windows Hello for Business Deployment Prerequisite Overview](hello-identity-verification.md) for a summary of the prerequisites for each different Windows Hello for Business deployment model. +Once you've chosen a deployment model, the deployment guide for that model will provide you with the information needed to successfully deploy Windows Hello for Business in your environment. Read the [Windows Hello for Business Deployment Prerequisite Overview](hello-identity-verification.md) for a summary of the prerequisites for each different Windows Hello for Business deployment model. ## Assumptions @@ -42,7 +39,7 @@ This guide assumes that baseline infrastructure exists which meets the requireme - Multi-factor Authentication is required during Windows Hello for Business provisioning - Proper name resolution, both internal and external names - Active Directory and an adequate number of domain controllers per site to support authentication -- Active Directory Certificate Services 2012 or later +- Active Directory Certificate Services 2012 or later (Note: certificate services are not needed for cloud trust deployments) - One or more workstation computers running Windows 10, version 1703 or later If you are installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server. @@ -51,36 +48,33 @@ Do not begin your deployment until the hosting servers and infrastructure (not r ## Deployment and trust models -Windows Hello for Business has three deployment models: Azure AD cloud only, hybrid, and on-premises. Hybrid and on-premises deployment models have two trust models: *Key trust* and *certificate trust*. - -> [!NOTE] -> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business 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). More information will be available on Windows Hello for Business cloud trust once it is generally available. +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 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. The trust model determines how you want users to authenticate to the on-premises Active Directory: -- The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. -- The certificate-trust model is for enterprise that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today. +- The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates. +- The cloud-trust model is also for hybrid enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and does not require Active Directory Certificate Services. We recommend using cloud trust instead of key trust if the clients in your enterprise support it. +- The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today. - The certificate trust model also supports enterprises which are not ready to deploy Windows Server 2016 Domain Controllers. -> [!NOTE] -> RDP does not support authentication with Windows Hello for Business key trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md). +> [!Note] +> RDP does not support authentication with Windows Hello for Business key trust or cloud trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust and cloud trust can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md). Following are the various deployment guides and models included in this topic: +- [Hybrid Azure AD Joined Cloud Trust Deployment](hello-hybrid-cloud-trust.md) - [Hybrid Azure AD Joined Key Trust Deployment](hello-hybrid-key-trust.md) - [Hybrid Azure AD Joined Certificate Trust Deployment](hello-hybrid-cert-trust.md) - [Azure AD Join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md) - [On Premises Key Trust Deployment](hello-deployment-key-trust.md) - [On Premises Certificate Trust Deployment](hello-deployment-cert-trust.md) -> [!NOTE] -> For Windows Hello for Business hybrid [certificate trust prerequisites](hello-hybrid-cert-trust-prereqs.md#directory-synchronization) and [key trust prerequisites](hello-hybrid-key-trust-prereqs.md#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](hello-hybrid-cert-trust-prereqs.md#directory-synchronization) and [key trust prerequisites](hello-hybrid-key-trust-prereqs.md#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. ## Provisioning Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**. -> [!NOTE] -> You need to allow access to the URL account.microsoft.com to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL does not require any authentication and as such, does not collect any user data. +Note that you need to allow access to the URL account.microsoft.com to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL does not require any authentication and as such, does not collect any user data. diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md index 892f986c01..a0afa94e49 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md @@ -12,7 +12,7 @@ manager: dansimp ms.collection: M365-identity-device-management ms.topic: article localizationpriority: medium -ms.date: 08/19/2018 +ms.date: 02/15/2022 ms.reviewer: --- # Windows Hello for Business and Authentication @@ -22,31 +22,46 @@ ms.reviewer: - Windows 10 - Windows 11 -Windows Hello for Business authentication is 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.
-Azure Active Directory joined devices authenticate to Azure during sign-in and can optional authenticate to Active Directory. Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.
+Windows Hello for Business authentication is 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. -[Azure AD join authentication to Azure Active Directory](#azure-ad-join-authentication-to-azure-active-directory)
-[Azure AD join authentication to Active Directory using a Key](#azure-ad-join-authentication-to-active-directory-using-a-key)
-[Azure AD join authentication to Active Directory using a Certificate](#azure-ad-join-authentication-to-active-directory-using-a-certificate)
-[Hybrid Azure AD join authentication using a Key](#hybrid-azure-ad-join-authentication-using-a-key)
-[Hybrid Azure AD join authentication using a Certificate](#hybrid-azure-ad-join-authentication-using-a-certificate)
+Azure Active Directory joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background. +- [Azure AD join authentication to Azure Active Directory](#azure-ad-join-authentication-to-azure-active-directory) +- [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud trust preview)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-trust-preview) +- [Azure AD join authentication to Active Directory using a key](#azure-ad-join-authentication-to-active-directory-using-a-key) +- [Azure AD join authentication to Active Directory using a certificate](#azure-ad-join-authentication-to-active-directory-using-a-certificate) +- [Hybrid Azure AD join authentication using Azure AD Kerberos (cloud trust preview)](#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview) +- [Hybrid Azure AD join authentication using a key](#hybrid-azure-ad-join-authentication-using-a-key) +- [Hybrid Azure AD join authentication using a certificate](#hybrid-azure-ad-join-authentication-using-a-certificate) ## Azure AD join authentication to Azure Active Directory + ![Azure AD join authentication to Azure Active Directory.](images/howitworks/auth-aadj-cloud.png) +> [!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. + | 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.| |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.| |C | 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.| |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 Azure AD Kerberos (cloud trust preview) + +![Azure AD join authentication to Azure Active Directory.](images/howitworks/auth-aadj-cloudtrust-kerb.png) + +| 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. +|B | After locating an active 2016 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 is signed by Azure AD Kerberos. The domain controller will verify 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 -## Azure AD join authentication to Active Directory using a Key ![Azure AD join authentication to Active Directory using a Key.](images/howitworks/auth-aadj-keytrust-kerb.png) - | 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 an active 2016 domain controller, the provider uses the private key to sign the Kerberos pre-authentication data.| @@ -56,28 +71,40 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c > [!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. +## Azure AD join authentication to Active Directory using a certificate -## Azure AD join authentication to Active Directory using a Certificate ![Azure AD join authentication to Active Directory using a Certificate.](images/howitworks/auth-aadj-certtrust-kerb.png) | Phase | Description | | :----: | :----------- | -|A | Authentication to Active Directory from a 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 pre-authentication data.| +|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 pre-authentication data.| |B | The Kerberos provider sends the signed pre-authentication 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.
The domain controller determines the certificate is not 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 has not 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 pre-authentication 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 has not 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 is cached and used for subsequent service ticket requests.| > [!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. +## Hybrid Azure AD join authentication using Azure AD Kerberos (cloud trust preview) -## Hybrid Azure AD join authentication using a Key -![Hybrid Azure AD join authentication using a Key.](images/howitworks/auth-haadj-keytrust.png) +![Hybrid Azure AD join authentication using Azure AD Kerberos](images/howitworks/auth-haadj-cloudtrust.png) + +| 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 trust is enabled. If cloud 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. +|B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Azure AD. +|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. +|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 will verify that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos will return the TGT to lsass, where it is 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 + +![Hybrid Azure AD join authentication using a key.](images/howitworks/auth-haadj-keytrust.png) | 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 Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.| -|B | The Kerberos provider sends the signed pre-authentication data and the user's 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.
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 pre-authentication 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 has not 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. +|B | The Kerberos provider sends the signed pre-authentication data and the user's 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.
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 pre-authentication 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 has not 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 is 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.| |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.| @@ -86,14 +113,15 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c > [!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. -## Hybrid Azure AD join authentication using a Certificate +## Hybrid Azure AD join authentication using a certificate + ![Hybrid Azure AD join authentication using a Certificate.](images/howitworks/auth-haadj-certtrust.png) | 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 Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.| -|B | The Kerberos provider sends the signed pre-authentication 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.
The domain controller determines the certificate is not 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 has not 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 pre-authentication 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 has not 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. +|B | The Kerberos provider sends the signed pre-authentication 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.
The domain controller determines the certificate is not 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 has not 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 pre-authentication 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 has not 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 is 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.| |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.| diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md index bf92834f9b..521b4364a4 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md @@ -12,85 +12,109 @@ manager: dansimp ms.collection: M365-identity-device-management ms.topic: article localizationpriority: medium -ms.date: 08/19/2018 +ms.date: 2/15/2022 ms.reviewer: --- # Windows Hello for Business Provisioning **Applies to:** + - Windows 10 - Windows 11 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 - The Windows Hello for Business deployment type - If the environment is managed or federated -[Azure AD 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)
-[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)
-[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)
-[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)
+List of provisioning flows: + +- [Azure AD 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) +- [Hybrid Azure AD joined provisioning in a cloud trust (preview) deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-trust-preview-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) +- [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) +- [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment) +- [Domain joined provisioning in an On-premises certificate trust deployment](#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment) > [!NOTE] > The flows in this section are not exhaustive for every possible scenario. For example, Federated Key Trust is also a supported configuration. +## Azure AD joined provisioning in a managed environment -## Azure AD joined provisioning in a Managed environment -![Azure AD joined provisioning in a Managed environment.](images/howitworks/prov-aadj-managed.png) +![Azure AD joined provisioning in a managed environment.](images/howitworks/prov-aadj-managed.png) [Full size image](images/howitworks/prov-aadj-managed.png) | Phase | Description | | :----: | :----------- | -| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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 services 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.
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. | -|B | After receiving a 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.| +| 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.
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.
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. | +|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.| [Return to top](#windows-hello-for-business-provisioning) -## Azure AD joined provisioning in a Federated environment -![Azure AD joined provisioning in Managed environment.](images/howitworks/prov-aadj-federated.png) + +## Azure AD joined provisioning in a federated environment + +![Azure AD joined provisioning in federated environment.](images/howitworks/prov-aadj-federated.png) [Full size image](images/howitworks/prov-aadj-federated.png) | Phase | Description | | :----: | :----------- | -| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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 services 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.
The on-premises STS server issues a enterprise token on successful MFA. The application sends the token to Azure Active Directory.
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. | -|B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).| +| A|The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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.
The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Azure Active Directory.
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. | +|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.| [Return to top](#windows-hello-for-business-provisioning) -## 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.](images/howitworks/prov-haadj-keytrust-managed.png) + +## Hybrid Azure AD joined provisioning in a cloud trust (preview) deployment in a managed environment + +![Hybrid Azure AD joined provisioning in a cloud trust deployment in a Managed environment.](images/howitworks/prov-haadj-cloudtrust-managed.png) +[Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png) + +| Phase | Description | +|:-----:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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. | +| 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. | + +> [!NOTE] +> Windows Hello for Business Cloud Trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to AAD and AD after provisioning their credential. + +[Return to top](#windows-hello-for-business-provisioning) + +## 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.](images/howitworks/prov-haadj-keytrust-managed.png) [Full size image](images/howitworks/prov-haadj-keytrust-managed.png) | Phase | Description | |:-----:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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 services 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.
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. | -| B | After receiving a 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. | -| 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. AAD Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. | +| 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.
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.
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. | +| 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. | +| 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. AAD Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. | > [!IMPORTANT] > The newly provisioned user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory. - - - [Return to top](#windows-hello-for-business-provisioning) -## 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.](images/howitworks/prov-haadj-instant-certtrust-federated.png) + +## 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.](images/howitworks/prov-haadj-instant-certtrust-federated.png) [Full size image](images/howitworks/prov-haadj-instant-certtrust-federated.png) | Phase | Description | |:-----:|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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 services (or a third party MFA service) provides the second factor of authentication.
The on-premises STS server issues a enterprise token on successful MFA. The application sends the token to Azure Active Directory.
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. | -| B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). | +| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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.
The on-premises STS server issues an enterprise token on successful MFA. The application sends the token to Azure Active Directory.
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. | +| 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. | | 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.
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.
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.
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.
After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. | | F | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. | -| G | The application receives the newly issued certificate and installs the it into the Personal store of the user. This signals the end of provisioning. | +| G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning. | > [!IMPORTANT] > Synchronous certificate enrollment 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. @@ -102,8 +126,8 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong, | Phase | Description | | :----: | :----------- | -|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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.
The on-premises STS server issues a enterprise DRS token on successful MFA.| -| B| After receiving a EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).| +|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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.
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).| |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.| @@ -114,8 +138,8 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong, | Phase | Description | | :----: | :----------- | -|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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.
The on-premises STS server issues a enterprise DRS token on successful MFA.| -| B| After receiving a EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).| +|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.
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.
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.
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).| |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.
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.
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.
After validating the public key, the registration authority signs the certificate request using its enrollment agent certificate.| diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md index 560844634b..ed3ad19d9d 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md @@ -19,20 +19,20 @@ ms.reviewer: # Hybrid Azure AD joined Windows Hello for Business Certificate Trust Provisioning **Applies to** -- Windows 10, version 1703 or later -- Windows 11 -- Hybrid deployment -- Certificate trust +- Windows 10, version 1703 or later +- Windows 11 +- Hybrid deployment +- Certificate trust ## Provisioning + The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**. ![Event358 from User Device Registration log showing Windows Hello for Business prerequisite check result.](images/Event358.png) The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**. - Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**. ![Setup a PIN Provisioning.](images/setupapin.png) @@ -46,10 +46,11 @@ After a successful MFA, the provisioning flow asks the user to create and valida ![Create a PIN during provisioning.](images/createPin.png) The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment. -* A successful single factor authentication (username and password at sign-in) -* A device that has successfully completed device registration -* A fresh, successful multi-factor authentication -* A validated PIN that meets the PIN complexity requirements + +- A successful single factor authentication (username and password at sign-in) +- A device that has successfully completed device registration +- A fresh, successful multi-factor authentication +- A validated PIN that meets the PIN complexity requirements 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. AAD Connect synchronizes the user's key to the on-premises Active Directory. @@ -77,6 +78,7 @@ The certificate authority validates the certificate was signed by the registrati
## Follow the Windows Hello for Business hybrid certificate trust deployment guide + 1. [Overview](hello-hybrid-cert-trust.md) 2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) 3. [New Installation Baseline](hello-hybrid-cert-new-install.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md new file mode 100644 index 0000000000..157f25c9bb --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md @@ -0,0 +1,260 @@ +--- +title: Hybrid Cloud Trust Deployment (Windows Hello for Business) +description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid cloud trust scenario. +keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, cert-trust +ms.prod: m365-security +ms.mktglfcycl: deploy +ms.sitesec: library +ms.pagetype: security, mobile +audience: ITPro +author: mapalko +ms.author: mapalko +manager: dansimp +ms.collection: M365-identity-device-management +ms.topic: article +localizationpriority: medium +ms.date: 2/15/2022 +ms.reviewer: +--- +# Hybrid Cloud Trust Deployment (Preview) + +Applies to + +- Windows 10, version 21H2 +- Windows 11 and later + +Windows Hello for Business replaces username and password Windows sign in with strong authentication using an asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid cloud trust scenario. + +## Introduction to Cloud Trust + +The goal of the Windows Hello for Business cloud trust is to bring the simplified deployment experience of [on-premises SSO with passwordless security keys](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises) to Windows Hello for Business. This deployment model can be used for new Windows Hello for Business deployments or existing deployments can move to this model using policy controls. + +Windows Hello for Business cloud trust uses Azure Active Directory (AD) Kerberos to address pain points of the key trust deployment model: + +- Windows Hello for Business cloud trust provides a simpler deployment experience because it doesn't require the deployment of public key infrastructure (PKI) or changes to existing PKI. +- Cloud trust doesn't require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This change means there isn't a delay between the user provisioning and being able to authenticate. +- Deploying Windows Hello for Business cloud trust enables you to also deploy passwordless security keys with minimal extra setup. + +> [!NOTE] +> Windows Hello for Business cloud trust is recommended instead of key trust if you meet the prerequisites to deploy cloud trust. Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. + +## Azure Active Directory Kerberos and Cloud 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 PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. Cloud trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT. + +With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business and use the returned TGT for logon or to access traditional AD-based resources. Kerberos service tickets and authorization continue to be controlled by your on-premises AD DCs. + +When you enable Azure AD Kerberos in a domain, an Azure AD Kerberos Server object is created in your on-premises AD. This object will appear as a Read Only Domain Controller (RODC) object but isn't associated with any physical servers. This resource is only used by Azure Active Directory to generate TGTs for your Active Directory Domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object. + +More details on how Azure AD Kerberos enables access to on-premises resources are available in our documentation on [enabling passwordless security key sign-in to on-premises resources](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). There's more information on how Azure AD Kerberos works with Windows Hello for Business cloud trust in the [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview). + +## Prerequisites + +| 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. | +| Patched Windows 10 version 21H2 or patched 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. | +| Fully patched Windows Server 2016 or later Domain Controllers | Domain controllers should be fully patched to support updates needed for Azure AD Kerberos. If you're using Windows Server 2016, [KB3534307](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e) must be installed. If you're using Server 2019, [KB4534321](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f) 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).| +| Device management | Windows Hello for Business cloud 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 + +The following scenarios aren't supported using Windows Hello for Business cloud trust. + +- 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) +- Scenarios that require a certificate for authentication +- Using cloud trust for "Run as" +- Signing in with cloud trust on a Hybrid Azure AD joined device without previously signing in with DC connectivity + +## Deployment Instructions + +Deploying Windows Hello for Business cloud trust consists of two steps: + +1. Set up Azure AD Kerberos in your hybrid environment. +1. Configure Windows Hello for Business policy and deploy it to devices. + +### Deploy Azure AD Kerberos + +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. + +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](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module) 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 trust. + +### Configure Windows Hello for Business Policy + +After setting up the Azure AD Kerberos Object, Windows Hello for business cloud trust must be enabled using policy. By default, cloud trust won't be used by Hybrid Azure AD joined or Azure AD joined devices. + +#### Configure Using Group Policy + +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. + +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. + +You can configure the Enable Windows Hello for Business Group Policy setting for computers or users. Deploying this policy setting to computers results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence. + +Cloud trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration. + +> [!NOTE] +> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune](/mem/intune/protect/identity-protection-windows-settings) and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources) + +##### Update Group Policy Objects + +You may need to update your Group Policy definitions to be able to configure the cloud trust policy. You can copy the ADMX and ADML files from a Windows 10 21H2 or Windows 11 device that supports cloud trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the Passport.admx and Passport.adml files. + +You can also create a Group Policy Central Store and copy them their respective language folder. For more information, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store). + +##### Create the Windows Hello for Business Group Policy object + +Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials. + +1. Start the **Group Policy Management Console** (gpmc.msc). +1. Expand the domain and select the **Group Policy Object** node in the navigation pane. +1. Right-click **Group Policy object** and select **New**. +1. Type *Enable Windows Hello for Business* in the name box and click **OK**. +1. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**. +1. In the navigation pane, expand **Policies** under **Device Configuration**. +1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**. +1. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**. +1. In the content pane, double-click **Use cloud trust for on-premises authentication**. Click **Enable** and click **OK**. +1. *Optional but recommended*: In the content pane, double-click **Use a hardware security device**. Click **Enable** and click **OK**. + +This group policy should be targeted at the computer group that you've created for that you want to use Windows Hello for Business. + +> [!Important] +> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud trust have this policy not configured or disabled. + +#### Configure Using Intune + +Windows Hello for Business can be enabled using device enrollment or device configuration policy. Device enrollment policy is only applied at device enrollment time. Any modifications to the configuration in Intune won't apply to already enrolled devices. Device configuration policy is applied after device enrollment. Changes to this policy type in Intune are applied to already enrolled devices. + +The cloud trust policy needs to be configured using a custom template and is configured separately from enabling Windows Hello from Business. + +##### Create a user Group that will be targeted for Windows Hello for Business + +If you have an existing group you want to target with Windows Hello for Business cloud trust policy, you can skip this step. + +1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). +1. Browse to **Groups** and select **New group**. +1. Configure the following group settings: + 1. Group type: "Security" + 1. Group name: "WHFBCloudTrustUsers" or a group name of your choosing + 1. Membership type: Assigned +1. Select **Members** and add users that you want to target with Windows Hello for Business cloud trust. + +You can also create a group through the Azure portal instead of using the Microsoft Endpoint Manager admin center. + +##### Enable Windows Hello for Business + +If you already enabled Windows Hello for Business for a target set of users or devices, you can skip below to configuring the cloud trust policy. Otherwise, follow the instructions at [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello) to create a Windows Hello for Business device enrollment policy. + +You can also follow these steps to create a device configuration policy instead of a device enrollment policy: + +1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). +1. Browse to Devices > Windows > Configuration Profiles > Create profile. +1. For Platform, select Windows 10 and later. +1. For Profile Type, select **Templates** and select the **Identity Protection** Template. +1. Name the profile with a familiar name. For example, "Windows Hello for Business". +1. In **Configurations settings**, set the **Configure Windows Hello for Business** option to **Enable**. +1. After setting Configure Windows Hello for Business to Enable, multiple policy options become available. These policies are optional to configure. More information on these policies is available in our documentation on managing [Windows Hello for Business in your organization](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business). We recommend setting **Use a Trusted Platform Module (TPM)** to **Enable**. + + [![Intune custom device configuration policy creation](./images/hello-intune-enable.png)](./images/hello-intune-enable-large.png#lightbox) + +1. Select Next to move to **Assignments**. +1. Under Included groups, select **Add groups**. +1. Select the user group you would like to use Windows Hello for Business cloud trust. This group may be WHFBCloudTrustUsers or a group of your choosing. +1. Select Next to move to the Applicability Rules. +1. Select Next again to move to the **Review + create** tab and select the option to create the policy. + +Windows Hello for Business settings are also available in the settings catalog. For more information, see [Use the settings catalog to configure settings on Windows and macOS devices - preview](/mem/intune/configuration/settings-catalog). + +##### Configure Cloud Trust policy + +To configure the cloud trust policy, follow the steps below: + +1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). +1. Browse to Devices > Windows > Configuration Profiles > Create profile. +1. For Platform, select Windows 10 and later. +1. For Profile Type, select **Templates** and select the **Custom** Template. +1. Name the profile with a familiar name. For example, "Windows Hello for Business cloud trust". +1. In Configuration Settings, add a new configuration with the following settings: + + - Name: "Windows Hello for Business cloud trust" or another familiar name + - Description: Enable Windows Hello for Business cloud trust for sign-in and on-premises SSO. + - OMA-URI: ./Device/Vendor/MSFT/PassportForWork/*tenant ID*/Policies/UseCloudTrustForOnPremAuth + + >[!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](/azure/active-directory/fundamentals/active-directory-how-to-find-tenant) for instructions on looking up your tenant ID. + + - Data type: Boolean + - Value: True + + [![Intune custom device configuration policy creation](./images/hello-cloud-trust-intune.png)](./images/hello-cloud-trust-intune-large.png#lightbox) + +1. Select Next to navigate to **Assignments**. +1. Under Included groups, select **Add groups**. +1. Select the user group you would like to use Windows Hello for Business cloud trust. This group may be WHFBCloudTrustUsers or a group of your choosing. +1. Select Next to move to the Applicability Rules. +1. Select Next again to move to the **Review + create** tab and select the option to create the policy. + +> [!Important] +> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud trust have this policy not configured or disabled. + +## Provisioning + +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 trust adds a prerequisite check for Hybrid Azure AD joined devices when cloud 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**. This information is also available using the [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) command from a console. + + ![Cloud trust prerequisite check in the user device registration log](./images/cloud-trust-prereq-check.png) + +The cloud 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 trust is not being enforced by policy or if the device is Azure AD joined. + +This prerequisite check isn't done for provisioning 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. + +### PIN Setup + +When Windows Hello for Business provisioning begins, the user will see a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**. + +![Setup a PIN Provisioning.](images/setupapin.png) + +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. + +![MFA prompt during provisioning.](images/mfa.png) + +After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment. + +![Create a PIN during provisioning.](images/createPin.png) + +### Sign-in + +Once a user has set up a PIN with cloud 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 logon can be used for subsequent unlocks without line of sight or network connectivity. + +## Troubleshooting + +If you encounter issues or want to share feedback about Windows Hello for Business cloud trust, share via the Windows Feedback Hub app by following these steps: + +1. Open **Feedback Hub**, and make sure that you're signed in. +1. Submit feedback by selecting the following categories: + - Category: Security and Privacy + - Subcategory: Windows Hello PIN + +## Frequently Asked Questions + +### Does Windows Hello for Business cloud trust work in my on-premises environment? + +This feature doesn't work in a pure on-premises AD domain services environment. + +### Does Windows Hello for Business cloud trust work in a Windows login with RODC present in the hybrid environment? + +Windows Hello for Business cloud trust looks for a writeable DC to exchange the partial TGT. As long as you have at least one writeable DC per site, login with cloud trust will work. + +### Do I need line of sight to a domain controller to use Windows Hello for Business cloud trust? + +Windows Hello for Business cloud trust requires line of sight to a domain controller for some scenarios: + - The first sign-in or unlock with Windows Hello for Business after provisioning on a Hybrid Azure AD joined device. + - When attempting to access an on-premises resource from an Azure AD joined device. + +### Can I use RDP/VDI with Windows Hello for Business cloud trust? + +Windows Hello for Business cloud trust cannot be used as a supplied credential with RDP/VDI. Similar to key trust, cloud trust can be used for RDP with [remote credential guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose. diff --git a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md index 38ad42ddd5..1bbb178788 100644 --- a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md +++ b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md @@ -16,7 +16,7 @@ ms.collection: - highpri ms.topic: article localizationpriority: medium -ms.date: 1/22/2021 +ms.date: 2/15/2022 --- # Windows Hello for Business Deployment Prerequisite Overview @@ -36,25 +36,20 @@ This article lists the infrastructure requirements for the different deployment The table shows the minimum requirements for each deployment. For key trust in a multi-domain/multi-forest deployment, the following requirements are applicable for each domain/forest that hosts Windows Hello for business components or is involved in the Kerberos referral process. -> [!NOTE] -> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business 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). More information will be available on Windows Hello for Business cloud trust once it is generally available. - -| Key trust
Group Policy managed | Certificate trust
Mixed managed | Key trust
Modern managed | Certificate trust
Modern managed | -| --- | --- | --- | --- | -| Windows 10, version 1511 or later| **Hybrid Azure AD Joined:**
*Minimum:* Windows 10, version 1703
*Best experience:* Windows 10, version 1709 or later (supports synchronous certificate enrollment).
**Azure AD Joined:**
Windows 10, version 1511 or later| Windows 10, version 1511 or later | Windows 10, version 1511 or later | -| Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | -| Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level| Windows Server 2008 R2 Domain/Forest functional level |Windows Server 2008 R2 Domain/Forest functional level | -| Windows Server 2016 or later Domain Controllers | Windows Server 2008 R2 or later Domain Controllers | Windows Server 2016 or later Domain Controllers | Windows Server 2008 R2 or later Domain Controllers | -| Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority | -| N/A | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) (hybrid Azure AD joined clients),
and
Windows Server 2012 or later Network Device Enrollment Service (Azure AD joined) | N/A | Windows Server 2012 or later Network Device Enrollment Service | -| Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | -| Azure Account | Azure Account | Azure Account | Azure Account | -| Azure Active Directory | Azure Active Directory | Azure Active Directory | Azure Active Directory | -| Azure AD Connect | Azure AD Connect | Azure AD Connect | Azure AD Connect | -| Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional for automatic MDM enrollment | Azure AD Premium, optional for automatic MDM enrollment | +| Requirement | Cloud trust (Preview)
Group Policy or Modern managed | Key trust
Group Policy or Modern managed | Certificate trust
Mixed managed | Certificate trust
Modern managed | +| --- | --- | --- | --- | --- | +| **Windows Version** | Windows 10, version 21H2 with KB5010415; Windows 11 with KB5010414; or later | Windows 10, version 1511 or later| **Hybrid Azure AD Joined:**
*Minimum:* Windows 10, version 1703
*Best experience:* Windows 10, version 1709 or later (supports synchronous certificate enrollment).
**Azure AD Joined:**
Windows 10, version 1511 or later| Windows 10, version 1511 or later | +| **Schema Version** | No specific Schema requirement | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | +| **Domain and Forest Functional Level** | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |Windows Server 2008 R2 Domain/Forest functional level | +| **Domain Controller Version** | Windows Server 2016 or later | Windows Server 2016 or later | Windows Server 2008 R2 or later | Windows Server 2008 R2 or later | +| **Certificate Authority**| N/A | Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority | +| **AD FS Version** | N/A | N/A | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) (hybrid Azure AD joined clients),
and
Windows Server 2012 or later Network Device Enrollment Service (Azure AD joined) | Windows Server 2012 or later Network Device Enrollment Service | +| **MFA Requirement** | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
AD FS w/Azure MFA adapter, or
AD FS w/Azure MFA Server adapter, or
AD FS w/3rd Party MFA Adapter | +| **Azure AD Connect** | N/A | 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 | > [!Important] -> - Hybrid deployments support non-destructive PIN reset that works with both the certificate trust and key trust models. +> - Hybrid deployments support non-destructive PIN reset that works with certificate trust, key trust and cloud trust models. > > **Requirements:** > - Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing requirement for this service since version 1903 diff --git a/windows/security/identity-protection/hello-for-business/hello-overview.md b/windows/security/identity-protection/hello-for-business/hello-overview.md index a730b8d478..5938679856 100644 --- a/windows/security/identity-protection/hello-for-business/hello-overview.md +++ b/windows/security/identity-protection/hello-for-business/hello-overview.md @@ -21,36 +21,39 @@ localizationpriority: medium # Windows Hello for Business Overview **Applies to** + - Windows 10 - Windows 11 In Windows 10, Windows Hello for Business replaces passwords with strong two-factor authentication on devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. >[!NOTE] -> When Windows 10 first shipped, it included Microsoft Passport and Windows Hello, which worked together to provide multi-factor authentication. To simplify deployment and improve supportability, Microsoft has combined these technologies into a single solution under the Windows Hello name. Customers who have already deployed these technologies will not experience any change in functionality. Customers who have yet to evaluate Windows Hello will find it easier to deploy due to simplified policies, documentation, and semantics. +> When Windows 10 first shipped, it included Microsoft Passport and Windows Hello, which worked together to provide multi-factor authentication. To simplify deployment and improve supportability, Microsoft has combined these technologies into a single solution under the Windows Hello name. Customers who have already deployed these technologies will not experience any change in functionality. Customers who have yet to evaluate Windows Hello will find it easier to deploy due to simplified policies, documentation, and semantics. Windows Hello addresses the following problems with passwords: -- Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites. -- Server breaches can expose symmetric network credentials (passwords). -- Passwords are subject to [replay attacks](/previous-versions/dotnet/netframework-4.0/aa738652(v=vs.100)). -- Users can inadvertently expose their passwords due to [phishing attacks](https://go.microsoft.com/fwlink/p/?LinkId=615674). + +- Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites. +- Server breaches can expose symmetric network credentials (passwords). +- Passwords are subject to [replay attacks](/previous-versions/dotnet/netframework-4.0/aa738652(v=vs.100)). +- Users can inadvertently expose their passwords due to [phishing attacks](https://go.microsoft.com/fwlink/p/?LinkId=615674). Windows Hello lets users authenticate to: -- a Microsoft account. -- an Active Directory account. -- a Microsoft Azure Active Directory (Azure AD) account. -- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://go.microsoft.com/fwlink/p/?LinkId=533889) authentication (in progress) + +- A Microsoft account. +- An Active Directory account. +- A Microsoft Azure Active Directory (Azure AD) account. +- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://go.microsoft.com/fwlink/p/?LinkId=533889) authentication. After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users. As an administrator in an enterprise or educational organization, you can create policies to manage Windows Hello for Business use on Windows 10-based devices that connect to your organization. ## Biometric sign-in - + Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras. Fingerprint reader hardware can be used or added to devices that don't currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users' credentials. - -- **Facial recognition**. This type of biometric recognition uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well. -- **Fingerprint recognition**. This type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) work with Windows 10 and Windows 11. + +- **Facial recognition**. This type of biometric recognition uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well. +- **Fingerprint recognition**. This type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) work with Windows 10 and Windows 11. Windows stores biometric data that is used to implement Windows Hello securely on the local device only. The biometric data doesn't roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there's no single collection point an attacker can compromise to steal biometric data. For more information about biometric authentication with Windows Hello for Business, see [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md). @@ -60,17 +63,16 @@ Windows stores biometric data that is used to implement Windows Hello securely o - **Windows Hello for Business**, which is configured by Group Policy or mobile device management (MDM) policy, always uses key-based or certificate-based authentication. This makes it much more secure than **Windows Hello convenience PIN**. - ## Benefits of Windows Hello Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their user name and password have been exposed. You may wonder [how a PIN can help protect a device better than a password](hello-why-pin-is-better-than-password.md). Passwords are shared secrets; they are entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone, anywhere. Because they're stored on the server, a server breach can reveal those stored credentials. -In Windows 10, Windows Hello replaces passwords. When the identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows from the combination of Hello keys and gesture that this is a verified identity and provides an authentication token that allows Windows 10 to access resources and services. +In Windows 10 and later, Windows Hello replaces passwords. When an identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows from the combination of Hello keys and gesture that this is a verified identity and provides an authentication token that allows Windows to access resources and services. >[!NOTE] ->Windows Hello as a convenience sign-in uses regular user name and password authentication, without the user entering the password. +>Windows Hello as a convenience sign-in uses regular username and password authentication, without the user entering the password. :::image type="content" alt-text="How authentication works in Windows Hello." source="images/authflow.png" lightbox="images/authflow.png"::: @@ -78,36 +80,31 @@ Imagine that someone is looking over your shoulder as you get money from an ATM Windows Hello helps protect user identities and user credentials. Because the user doesn't enter a password (except during provisioning), it helps circumvent phishing and brute force attacks. It also helps prevent server breaches because Windows Hello credentials are an asymmetric key pair, which helps prevent replay attacks when these keys are protected by TPMs. - -  ## How Windows Hello for Business works: key points -- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device. +- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device. -- Identity provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and maps the Windows Hello public key to a user account during the registration step. +- Identity provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and maps the Windows Hello public key to a user account during the registration step. -- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. +- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. To guarantee that keys are generated in hardware, you must set policy. -- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture does not roam between devices and is not shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared. +- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture does not roam between devices and is not shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared. -- The private key never leaves a device when using TPM. The authenticating server has a public key that is mapped to the user account during the registration process. +- The private key never leaves a device when using TPM. The authenticating server has a public key that is mapped to the user account during the registration process. -- PIN entry and biometric gesture both trigger Windows 10 to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user. +- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user. -- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy. +- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy. -- Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture. +- Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture. For details, see [How Windows Hello for Business works](hello-how-it-works.md). ## Comparing key-based and certificate-based authentication -Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello. Enterprises that do not use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello but still use certificates on their domain controllers as a root of trust. +Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that do not use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 21H2, there is a feature called cloud trust for hybrid deployments which uses Azure AD as the root of trust. Cloud trust uses key-based credentials for Windows Hello but does not require certificates on the domain controller. -Windows Hello for Business with a key does not support supplied credentials for RDP. RDP does not support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business key trust can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md). - -> [!NOTE] -> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business 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). More information will be available on Windows Hello for Business cloud trust once it is generally available. +Windows Hello for Business with a key, including cloud trust, does not support supplied credentials for RDP. RDP does not support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md). ## Learn more @@ -134,4 +131,3 @@ Windows Hello for Business with a key does not support supplied credentials for - [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md) - [Event ID 300 - Windows Hello successfully created](hello-event-300.md) - [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md) -  \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/images/cloud-trust-prereq-check.png b/windows/security/identity-protection/hello-for-business/images/cloud-trust-prereq-check.png new file mode 100644 index 0000000000..f327f79f32 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/cloud-trust-prereq-check.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/hello-cloud-trust-intune-large.png b/windows/security/identity-protection/hello-for-business/images/hello-cloud-trust-intune-large.png new file mode 100644 index 0000000000..e9d0876738 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/hello-cloud-trust-intune-large.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/hello-cloud-trust-intune.png b/windows/security/identity-protection/hello-for-business/images/hello-cloud-trust-intune.png new file mode 100644 index 0000000000..fd6644b8b7 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/hello-cloud-trust-intune.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/hello-intune-enable-large.png b/windows/security/identity-protection/hello-for-business/images/hello-intune-enable-large.png new file mode 100644 index 0000000000..ef99144042 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/hello-intune-enable-large.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/hello-intune-enable.png b/windows/security/identity-protection/hello-for-business/images/hello-intune-enable.png new file mode 100644 index 0000000000..edcbe0ec34 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/hello-intune-enable.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloudtrust-kerb.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloudtrust-kerb.png new file mode 100644 index 0000000000..1fec70ce5a Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloudtrust-kerb.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-cloudtrust.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-cloudtrust.png new file mode 100644 index 0000000000..0a803d8fbb Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-cloudtrust.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-cloudtrust-managed.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-cloudtrust-managed.png new file mode 100644 index 0000000000..b2867c3aeb Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-cloudtrust-managed.png differ diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml index f0c08b1c66..1e3bd031b3 100644 --- a/windows/security/identity-protection/hello-for-business/toc.yml +++ b/windows/security/identity-protection/hello-for-business/toc.yml @@ -33,6 +33,8 @@ href: hello-prepare-people-to-use.md - name: Deployment Guides items: + - name: Hybrid Cloud Trust Deployment + href: hello-hybrid-cloud-trust.md - name: Hybrid Azure AD Joined Key Trust items: - name: Hybrid Azure AD Joined Key Trust Deployment