Cloud Kerberos trust deployment

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

Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in a cloud Kerberos trust scenario.

Introduction to cloud Kerberos trust

The goal of Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of passwordless security key sign-in to Windows Hello for Business, and it can be used for new or existing Windows Hello for Business deployments.

Windows Hello for Business cloud Kerberos trust uses Microsoft Entra Kerberos, which enables a simpler deployment when compared to the key trust model:

  • No need to deploy a public key infrastructure (PKI) or to change an existing PKI
  • No need to synchronize public keys between Microsoft Entra ID and Active Directory for users to access on-premises resources. There isn't any delay between the user's Windows Hello for Business provisioning, and being able to authenticate to Active Directory
  • Passwordless security key sign-in can be deployed with minimal extra setup


Windows Hello for Business cloud Kerberos trust is the recommended deployment model when compared to the key trust model. It is also the preferred deployment model if you do not need to support certificate authentication scenarios.

Microsoft Entra Kerberos and cloud Kerberos trust authentication

Key trust and certificate trust use certificate authentication-based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires a PKI for DC certificates, and requires end-user certificates for certificate trust.

Cloud Kerberos trust uses Microsoft Entra Kerberos, which doesn't require a PKI to request TGTs.
With Microsoft Entra Kerberos, Microsoft Entra ID can issue TGTs for one or more AD domains. Windows can request a TGT from Microsoft Entra ID when authenticating with Windows Hello for Business, and use the returned TGT for sign-in or to access AD-based resources. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization.

When 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


    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.

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

For more information about how Microsoft Entra Kerberos enables access to on-premises resources, see enabling passwordless security key sign-in to on-premises resources.
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.


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.


Requirement Notes
Multifactor authentication This requirement can be met using Microsoft Entra multifactor authentication, multifactor authentication provided through AD FS, or a comparable solution.
Windows 10, version 21H2 or Windows 11 and later If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Microsoft Entra joined and Microsoft Entra hybrid joined devices.
Windows Server 2016 or later Domain Controllers If you're using Windows Server 2016, KB3534307 must be installed. If you're using Server 2019, KB4534321 must be installed.
Microsoft Entra Kerberos PowerShell module This module is used for enabling and managing Microsoft Entra Kerberos. It's available through the PowerShell Gallery.
Device management Windows Hello for Business cloud Kerberos trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy.

Unsupported scenarios

The following scenarios aren't supported using Windows Hello for Business cloud Kerberos 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)
  • 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


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 isn't recommended to unblock these accounts by relaxing the Password Replication Policy of the computer object CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>.

Next steps

Once the prerequisites are met, deploying Windows Hello for Business with a cloud Kerberos trust model consists of the following steps:

  • Deploy Microsoft Entra Kerberos
  • Configure Windows Hello for Business settings
  • Provision Windows Hello for Business on Windows clients