Microsoft offers Hybrid Cloud Trust as a way to offer people with synchronized Work or School accounts on Azure AD-joined device seamless single sign-on access to Active Directory-integrated resources. When they sign in with Windows Hello for Business (WHfB), the Active Directory-integrated functionality doesn’t prompt for username and password.

How Hybrid Cloud Trust works

Under the hood, Hybrid Cloud Trust creates:

• A read-only domain controller account named AzureADKerberos in the Domain Controllers Organizational Unit (OU).
• An account named krbtgt_AzureAD in the Users container.

When the person sign ins, Azure AD automatically provides a partial Kerberos ticket-granting tickets (TGTs) that is redeemed to a full TGT when the user accesses Kerberos-integrated on-premises resources and there is a line of sight to at least one Windows Server 2016-based read/write Domain Controller.

The partial TGT is signed and encrypted with the password for the krbtgt_AzureAD account. Obviously, the password needs to be identical in both the Active Directory and Azure AD stores for the functionality to work.

Periodically reset the password

Kerberos was never designed for untrusted networks like the Interne. There have been and might still be vulnerabilities in the Kerberos protocol and/or implementation. When the password for the krbtgt or krbtgt_AzureAD account is leaked, an attacker can impersonate any user within Active Directory. Therefor, just like other krbtgt accounts, the password for the krbtgt_AzureAD account needs to be reset periodically.

However, resetting the password for the krbtgt_AzureADaccount is different to resetting the password for the krbtgt in the Active Directory domain, used by all read/write domain controllers, and the krbtgt_* passwords per read-only domain controller. These passwords merely need to be replicated within Active Directory. The password for the krbtgt_AzureAD account needs to be changed both in Active Directory and in Azure AD.

The New-KrbtgtKeys.ps1 script warns if it stumbles upon the krbtgt_AzureAD account and explicitly doesn’t reset its password. The script cannot be used, but fortunately, there is a way to reset the password for this account.

What could go wrong?

When the password is reset for krbtgt_AzureAD and krbtgt accounts in your Active Directory environment, current sessions won’t be affected. The previous password is retained and used to decrypt and validate Kerberos tokens that were encrypted and signed with the previous password.

Note:
This means that the password for krbtgt_AzureAD and krbtgt accounts should not be reset more often than once every week, unless the goal is to end all Kerberos sessions.

Reset the password for KRBTGT_AzureAD

Perform these steps to reset the password for the krbtgt_AzureAD account:

• Sign in interactively to a Windows Server installation that runs Azure AD Connect with an account that is a member of the Enterprise Admins group.
• Start an elevated Windows PowerShell session and perform the following lines of PowerShell.

Note:
Change the value for contoso.com to the DNS name of the Active Directory domain where the krbtgt_AzureAD account resides.

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

$domain = "contoso.com"

$cloudCred = Get-Credential -Message 'Provide the credentials for an account that has the Global Administrator role in Azure AD.'

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -RotateServerKey

• When prompted for multi-factor authentication by Azure AD, provide the credentials for the account is has the Global Administrator role in Azure AD.
• If prompted for a smart card, Press Cancel.

Call to Action

Please use the same frequency for resetting the krbtgt_AzureAD account as you reset the krbtgt account in your Active Directory environment. Microsoft recommends resetting the password for these accounts every 30 days. Auditors may flag the password when it is older than 180 days.