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..382b438e61 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: 01/25/2022
ms.reviewer:
---
# Windows Hello for Business and Authentication
@@ -22,17 +22,20 @@ 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 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.
+- [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](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos)
+- [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](#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos)
+- [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
+
| Phase | Description |
@@ -41,11 +44,20 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
|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
+
+
+
+| 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
-
+
| Phase | Description |
| :----: | :----------- |
@@ -56,8 +68,8 @@ 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
+
| Phase | Description |
@@ -69,15 +81,27 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
> [!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
+
+
+
+| 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
+
| 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.|
@@ -87,13 +111,14 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
> 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
+
| 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..38fd963a67 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
@@ -18,26 +18,32 @@ 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 deployment in a Managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-trust-deployment-in-a-managed-environment)
+- [Hybrid Azure AD joined provisioning in a Key Trust deployment in a Managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
+- [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
+
[Full size image](images/howitworks/prov-aadj-managed.png)
@@ -49,7 +55,9 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
[Return to top](#windows-hello-for-business-provisioning)
+
## Azure AD joined provisioning in a Federated environment
+
[Full size image](images/howitworks/prov-aadj-federated.png)
@@ -60,7 +68,25 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|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 Cloud Trust deployment in a Managed environment
+
+
+[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. 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. |
+
+> [!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
+
[Full size image](images/howitworks/prov-haadj-keytrust-managed.png)
@@ -74,11 +100,10 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
> [!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
+
[Full size image](images/howitworks/prov-haadj-instant-certtrust-federated.png)
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
index 28e9e95cd7..d805d7d749 100644
--- 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
@@ -16,4 +16,57 @@ localizationpriority: medium
ms.date: 1/05/2022
ms.reviewer:
---
-# Hybrid Azure AD joined Certificate Trust Deployment
+# Hybrid Cloud Trust Deployment
+
+Applies to
+
+- Windows 10, version 21H2
+- Windows 11
+
+Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on 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 deployment model is to bring the benefits of 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 does not require the deployment or modification of public key infrastructure.
+- Deploying Windows Hello for Business cloud trust enables you to also deploy passwordless security keys with minimal additional setup.
+- Cloud trust does not require syncing of public keys between Azure AD and on-premises domain controllers (DCs) before users can use their Windows Hello for Business credential on-premises.
+
+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
+
+With Azure AD Kerberos, Azure AD can issue Kerberos ticket-granting-tickets (TGTs) for one or more of your AD domains. Using this functionality, Windows can request TGTs from Azure AD when authenticating using Windows Hello for Business and then use them for logon or to access traditional Active Directory-based resources. Kerberos Service Tickets and authorization continue to be controlled by your on-premises Active Directory DCs.
+
+For more details on how Authentication with Windows Hello for Business Cloud Trust works see the [Windows Hello for Business Authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos).
+
+## Prerequisites
+
+| Requirement | Notes |
+| --- | --- |
+| Multi-factor Authentication | This requirement can be met using [Azure AD Multi-Factor Authentication](howto-mfa-getstarted.md), multi-factor authentication provided through AD FS, or a comparable solution |
+| Windows 10 version 21H2 or higher | There is no Windows version support difference between Azure AD joined and Hybrid Azure AD joined devices. |
+| Windows Server 2016 or later Domain Controllers | These should be fully patched to support updates needed for Azure AD Kerberos. |
+| Azure AD Connect version 1.4.32.0 or later | This version packages the tools for setting up Azure AD Kerberos |
+| Device management | Windows Hello for Business cloud trust can be managed with group policy or through Microsoft Intune. |
+
+### Unsupported Scenarios
+
+## Deployment Instructions
+
+Deploying Windows Hello for Business cloud trust consists of two steps. First, you will need to deploy Azure AD Kerberos in your hybrid environment. Second, you will need to configure Windows Hello for Business policy and deploy that devices you wish to use Windows Hello for Business.
+
+If you have already deployed [on-premises SSO for passwordless security key sign-in](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises), then you will have already deployed Azure AD Kerberos in your hybrid environment. You do not need to re-deploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business.
+
+### Deploy Azure AD Kerberos
+
+
+
+### Configure Windows Hello for Business
+
+## Windows Hello Provisioning
+
+DSREG CMD and Event logs
\ No newline at end of file