Cloud Kerberos trust deployment guide

This article describes Windows Hello for Business functionalities or scenarios that apply to:


Requirements

Before starting the deployment, review the requirements described in the Plan a Windows Hello for Business Deployment article.

Ensure that the following requirements are met before you begin:

Important

When implementing the cloud Kerberos trust deployment model, you must ensure that you have an adequate number of read-write domain controllers in each Active Directory site where users will be authenticating with Windows Hello for Business. For more information, see Capacity planning for Active Directory.

Deployment steps

Once the prerequisites are met, deploying Windows Hello for Business consists of the following steps:

Deploy Microsoft Entra Kerberos

If you've already deployed on-premises SSO for passwordless security key sign-in, then Microsoft Entra Kerberos is already deployed in your organization. You don't need to redeploy or change your existing Microsoft Entra Kerberos deployment to support Windows Hello for Business, and you can skip to the Configure Windows Hello for Business policy settings section.

If you haven't deployed Microsoft Entra Kerberos, follow the instructions in the Enable passwordless security key sign-in documentation. This page includes information on how to install and use the Microsoft Entra Kerberos PowerShell module. Use the module to create a Microsoft Entra Kerberos server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust.

Microsoft Entra Kerberos and cloud Kerberos trust authentication

When Microsoft Entra Kerberos is enabled in an Active Directory domain, an AzureADKerberos computer object is created in the domain. This object:

  • Appears as a Read Only Domain Controller (RODC) object, but isn't associated with any physical servers

  • Is only used by Microsoft Entra ID to generate TGTs for the Active Directory domain

    Note

    Similar rules and restrictions used for RODCs apply to the AzureADKerberos computer object. For example, users that are direct or indirect members of priviliged built-in security groups won't be able to use cloud Kerberos trust.

Screenshot of the Active Directory Users and Computers console, showing the computer object representing the Microsoft Entra Kerberos server.

For more information about how Microsoft Entra Kerberos works with Windows Hello for Business cloud Kerberos trust, see Windows Hello for Business authentication technical deep dive.

Note

The default Password Replication Policy configured on the AzureADKerberos computer object doesn't allow to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys.

Due to possible attack vectors from Microsoft Entra ID to Active Directory, it's not recommended to unblock these accounts by relaxing the Password Replication Policy of the computer object CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>.

Configure Windows Hello for Business policy settings

After setting up the Microsoft Entra Kerberos object, Windows Hello for business must be enabled and configured to use cloud Kerberos trust. There are two policy settings required to configure Windows Hello for Business in a cloud Kerberos trust model:

Another optional, but recommended, policy setting is:

Important

If the Use certificate for on-premises authentication policy is enabled, certificate trust takes precedence over cloud Kerberos trust. Ensure that the machines that you want to enable cloud Kerberos trust have this policy not configured.

The following instructions explain how to configure your devices using either Microsoft Intune or group policy (GPO).

Note

Review the article Configure Windows Hello for Business using Microsoft Intune to learn about the different options offered by Microsoft Intune to configure Windows Hello for Business.

If the Intune tenant-wide policy is enabled and configured to your needs, you only need to enable the policy setting Use Cloud Trust For On Prem Auth. Otherwise, both settings must be configured.

To configure devices with Microsoft Intune, create a Settings catalog policy and use the following settings:

Category Setting name Value
Windows Hello for Business Use Passport For Work true
Windows Hello for Business Use Cloud Trust For On Prem Auth Enabled
Windows Hello for Business Require Security Device true

Assign the policy to a group that contains as members the devices or users that you want to configure.

Alternatively, you can configure devices using a custom policy with the PassportForWork CSP.

Setting
- OMA-URI: ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork
- Data type: bool
- Value: True
- OMA-URI: ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth
- Data type: bool
- Value: True
- OMA-URI: ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice
- Data type: bool
- Value: True

If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings take precedence, and Intune settings are ignored. For more information about policy conflicts, see Policy conflicts from multiple policy sources.

More policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see Windows Hello for Business policy settings.

Enroll in Windows Hello for Business

The Windows Hello for Business provisioning process begins immediately after a user signs in, if the prerequisite checks pass. Windows Hello for Business cloud Kerberos trust adds a prerequisite check for Microsoft Entra hybrid joined devices when cloud Kerberos trust is enabled by policy.

You can determine the status of the prerequisite check by viewing the User Device Registration admin log under Applications and Services Logs > Microsoft > Windows.
This information is also available using the dsregcmd.exe /status command from a console. For more information, see dsregcmd.

The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Microsoft Entra Kerberos is set up for the user's domain and tenant. If Microsoft Entra Kerberos is set up, the user receives a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The Not Tested state is reported if cloud Kerberos trust isn't enforced by policy or if the device is Microsoft Entra joined.

Note

The cloud Kerberos trust prerequisite check isn't done on Microsoft Entra joined devices. If Microsoft Entra Kerberos isn't provisioned, a user on a Microsoft Entra joined device will still be able to sign in, but won't have SSO to on-premises resources secured by Active Directory.

User experience

After a user signs in, the Windows Hello for Business enrollment process begins:

  1. If the device supports biometric authentication, the user is prompted to set up a biometric gesture. This gesture can be used to unlock the device and authenticate to resources that require Windows Hello for Business. The user can skip this step if they don't want to set up a biometric gesture
  2. The user is prompted to use Windows Hello with the organization account. The user selects OK
  3. 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
  4. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
  5. 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 the IdP to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and access their desktop

Once a user completes enrollment with cloud Kerberos trust, the Windows Hello gesture can be used immediately for sign-in. On a Microsoft Entra hybrid joined device, the first use of the PIN requires line of sight to a DC. Once the user signs in or unlocks with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity.

After enrollment, Microsoft Entra Connect synchronizes the user's key from Microsoft Entra ID to Active Directory.

Sequence diagrams

To better understand the provisioning flows, review the following sequence diagrams based on the device join and authentication type:

To better understand the authentication flows, review the following sequence diagram:

Migrate from key trust deployment model to cloud Kerberos trust

If you deployed Windows Hello for Business using the key trust model, and want to migrate to the cloud Kerberos trust model, follow these steps:

  1. Set up Microsoft Entra Kerberos in your hybrid environment
  2. Enable cloud Kerberos trust via Group Policy or Intune
  3. For Microsoft Entra joined devices, sign out and sign in to the device using Windows Hello for Business

Note

For Microsoft Entra hybrid joined devices, users must perform the first sign in with new credentials while having line of sight to a DC.

Migrate from certificate trust deployment model to cloud Kerberos trust

Important

There is no direct migration path from a certificate trust deployment to a cloud Kerberos trust deployment. The Windows Hello container must be deleted before you can migrate to cloud Kerberos trust.

If you deployed Windows Hello for Business using the certificate trust model, and want to use the cloud Kerberos trust model, you must redeploy Windows Hello for Business by following these steps:

  1. Disable the certificate trust policy
  2. Enable cloud Kerberos trust via Group Policy or Intune
  3. Remove the certificate trust credential using the command certutil.exe -deletehellocontainer from the user context
  4. Sign out and sign back in
  5. Provision Windows Hello for Business using a method of your choice

Note

For Microsoft Entra hybrid joined devices, users must perform the first sign-in with new credentials while having line of sight to a DC.

Frequently Asked Questions

For a list of frequently asked questions about Windows Hello for Business cloud Kerberos trust, see Windows Hello for Business Frequently Asked Questions.

Unsupported scenarios

The following scenarios aren't supported using Windows Hello for Business cloud Kerberos trust:

  • RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container)
  • Using cloud Kerberos trust for Run as
  • Signing in with cloud Kerberos trust on a Microsoft Entra hybrid joined device without previously signing in with DC connectivity