Edit

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 Azure AD 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 Azure AD and Active Directory for users to access on-premises resources. There isn't any delay between the user's Windows Hello for Business provisioning, and being able to authenticate to Active Directory
  • Passwordless security key sign-in can be deployed with minimal extra setup

Note

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

Azure AD 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 Azure AD Kerberos, which doesn't require a PKI to request TGTs.
With Azure AD Kerberos, Azure AD can issue TGTs for one or more AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business, and use the returned TGT for sign-in or to access AD-based resources. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization.

When Azure AD Kerberos is enabled in an Active Directory domain, an Azure AD Kerberos server 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 Azure AD to generate TGTs for the Active Directory domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object

Active Directory Users and Computers console, showing the computer object representing the Azure AD Kerberos server

For more information about how Azure AD Kerberos enables access to on-premises resources, see enabling passwordless security key sign-in to on-premises resources.
For more information about how Azure AD Kerberos works with Windows Hello for Business cloud Kerberos trust, see Windows Hello for Business authentication technical deep dive.

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.

Prerequisites

Requirement Notes
Multi-factor Authentication This requirement can be met using Azure AD multi-factor authentication, multi-factor authentication provided through AD FS, or a comparable solution.
Windows 10, version 21H2 or Windows 11 and later If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices.
Windows 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.
Azure AD Kerberos PowerShell module This module is used for enabling and managing Azure AD 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 Hybrid Azure AD joined device without previously signing in with DC connectivity

Note

The default security policy for AD does not grant permission to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys.

To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos 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 Azure AD Kerberos
  • Configure Windows Hello for Business settings
  • Provision Windows Hello for Business on Windows clients

Next: configure and provision Windows Hello for Business >