In a world with both Active Directory and Azure AD, organizations have to make choices. It seems they can either stick with their proven Active Directory, or jump ahead to Azure AD. Luckily, there’s a third option. Using Azure AD Connect, organizations can have the best of the Active Directory and Azure AD worlds.

The best or the worst of both worlds?

When Azure AD benefits, like Azure Multi-factor Authentication, Dynamic Groups and Access Reviews are coupled with the robustness and data sovereignty of Active Directory, benefits like single sign-on, cloud AI, and high availability emerge. This is typically referred to as ‘Hybrid Identity’.

When done wrong, an attacker who successfully pwns Active Directory also pwns the organization’s Microsoft 365 data. This is typically referred to in biblical terms.

The right choices need to be made.

Where Passwordless comes in

In a Hybrid Identity setup, single sign-on can be based on federation, or either (hybrid) Azure AD Join or Azure AD Connect’s Seamless Single Sign-in option.

However, Microsoft’s Passwordless authentication methods, like Windows Hello for Business, Microsoft Authenticator’s Phone Sign-in and FIDO2 are all engineered with their basis firmly in Azure AD. Active Directory is still stuck in the 90s with passwords, certificates, enhanced by occasional Kerberos improvements ever since Windows NT 5 Beta 5.

Windows Hello for Business is a prime specimen of Microsoft Passwordless technologies. It allows interactive sign-ins to devices that run Windows 10 or Windows 11 and are either Azure AD-joined or hybrid Azure AD-joined.

Several members of the Identity Division have been quoted to say something along the lines of:

When you Hybrid Azure AD join instead of Azure AD join, an angel loses its wings.

With organizations going the pure Azure AD Join route for devices with default settings, the interesting situation occurs that people can have seamless access to the on-premises resources when the device is on-premises (or connected to a VPN) when they sign in with username and password, but are prompted for a username and password when they’ve signed in using Windows Hello for Business…

Trust

Luckily, you can make this work without password prompts. There are three ways to have Active Directory trust Azure AD sign-ins:

1. Key Trust
   With key trust, when a person successfully configures Windows Hello for Business, a key credential is generated. Azure AD Connect writes a link to this RSA 2048-bit asymmetric key to the mSDS-KeyCredentialLink attribute of the user object in Active Directory. When accessing on-premises resources, the user provides the necessary information regarding the value for that attribute and the Domain Controller is able to verify the user’s identity with that information (if it’s running Windows Server 2016, or up).
2. Certificate Trust
   With certificate trust, when a person successfully configures Windows Hello for Business, the Azure AD-joined device requests a user certificate for the user and the private key is stored on the device, protected by the TPM chip. The Certificate Connector for Microsoft Intune provides the bridge to the internal CA. When accessing on-premises resources, the user signs in with certificate-based authentication, just like when he or she would use a (virtual) smart card.
3. Cloud Trust
   With cloud trust, Azure AD acts as a read-only domain controller. Regardless of the sign-in method, the device receives (or updates) both a Primary Refresh Token (PRT) from Azure AD and a partial Kerberos Ticket Granting Ticket (TGT) from Active Directory. When accessing on-premises resources, the partial TGT is automatically exchanged with a TGT from a domain controller that provides access to on-premises resources.

The first two trust types are based on a certificate key tab or a full-blown user certificate that the user presents to Active Directory. As Active Directory understands certificates, this works as well as you might expect.

Cloud Trust

The latter trust types uses plain old Kerberos, but it has some tricks up its sleeve to make it all work seamlessly. That makes the hybrid cloud trust model the preferred model, as long as you have devices that run Windows 10 version 22H2 (or up), Domain Controllers that run Windows Server 2016 and as long as you use Azure AD Connect.

Let’s dive in!

Hybrid Cloud Trust, How do I set it up?

Setting up hybrid cloud trust requires only four lines of PowerShell on a Windows Server that runs Azure AD Connect v2.x. Perform these four lines in an elevated PowerShell window:

Import-module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1"

$domain = $env:USERDNSDOMAIN

$cloudCred = Get-Credential -Message 'Specify the userPrincipalName for an account with Global Administrators privileges in Azure AD.'

$domainCred = Get-Credential -Message 'Specify an Active Directory user who is a member of the Domain Admins group.'

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

Then, with the Get-AzureADKerberosServer cmdlet from the same PowerShell module, you can get the information on the read-only domain controller object and the last time the shared secret for cloud trust was updated on either end.

Azure AD as an RODC, How does that work?

After you setup cloud trust, a new read-only domain controller appears in the Domain Controllers Organizational Unit (OU) in the Active Directory domain that is configured for cloud trust, named AzureADKerberos.

This computer object does not represent an actual Windows Server installation, but is a representation of a read-only domain controller. The secret for the server object is synchronized to Azure AD.

When cloud trust is configured, Azure AD provides every Windows sign-in to Azure AD-joined devices with a partial Kerberos ticket-granting ticket (TGT) that is encrypted and signed with the password of the krbtgt_AzureAD account, associated with the AzureADKerberos read-only domain controller.

This ticket can be seen on the command line of the device using the following command-line after sign-in:

klist.exe

When the device is used to access domain-joined resources and has a line of sight to one or more Windows Server 2016-based domain controllers (or up), the partial TGT is then exchanged for a TGT that is encrypted and signed by the domain controller. This TGT contains all the group memberships, where the partial TGT did not. Based on the full TGT, a Kerberos service ticket (ST) is then requested to access the domain-joined resource.

Important
Because the AzureADKerberos read-only domain controller is not a real domain controller, do not reset its password as you would for other domain controller. The password for the accompanying krbtgt_AzureAD account needs to be synchronized to Azure AD, so there are other steps involved.

How does an Azure AD-joined device know where to find on-premises domain controllers?

Azure AD Connect provides information on Active Directory to all Azure AD-joined devices. The domain controllers the device knows can be viewed using the following command-line:

nltest.exe /dclist:domain.tld

Replace domain.tld with the DNS domain name of the Active Directory domain.

Concluding

Cloud trust allows people with synchronized accounts to access to Kerberos-based on-premises resources when they sign in using Windows Hello for Business.

However, Microsoft’s recent public preview for single sign-on to Azure Virtual Desktop (AVD)-based devices when not using Active Directory Federation Services (AD FS) also uses cloud trust. Expect more (single) sign-in experiences to emerge based on cloud trust!