Cloud Kerberos Trust is a feature used in hybrid environments, where Active Directory (AD) and Azure Active Directory (Azure AD) coexist. This trust enables passwordless authentication methods for AD-connected resources. In this article, we will delve into the intricacies of Cloud Kerberos Trust, its potential security implications, and how to secure your hybrid environment against potential attacks.
Hybrid Environment Dynamics
Active Directory plays a vital role in managing identities within an organization’s on-premises infrastructure. With the increasing adoption of cloud-based solutions, Azure Active Directory has emerged as the go-to choice for managing cloud-based identities. In most hybrid environments, identities synchronize from on-premises AD to Azure AD, making on-premises AD the authoritative source.
Lateral Movement in Hybrid Environments
Lateral movement typically occurs from on-premises AD to Azure AD due to the synchronization of identities. This means that a compromised AD often results in a vulnerable Azure AD. However, lateral movement from Azure AD to on-premises AD is rare since AD does not usually sync much information from Azure AD.
The Cloud Kerberos Trust model stands out as an exception, as it establishes a trust between on-premises AD and Azure AD. This trust allows Azure AD to authenticate users for on-premises AD-connected resources using passwordless methods, thereby introducing potential risks for organizations.
The Fundamentals of Cloud Kerberos Trust
To understand Cloud Kerberos Trust, let’s explore the core components involved in the process:
Read-Only Domain Controller (RODC)
When setting up Cloud Kerberos Trust, a Read-Only Domain Controller (RODC) is created in AD using a PowerShell script. The RODC consists of two important components:
- The RODC computer account, named
AzureADKerberos$. Its presence indicates that Cloud Kerberos is in use within the domain.
- A secondary
krbtgt_AzureAD, which contains the Kerberos keys used for tickets created by Azure AD. The SAM account name includes the key ID, for example
These components are connected through the
msDS-KrbTgtLinkBl attribute. The RODC imposes restrictions on which accounts can be authenticated using the Cloud Kerberos Trust. The “Password Replication Policy” in the RODC configuration determines which accounts are allowed and denied for authentication.
Azure AD’s Role in Issuing Kerberos Tickets
When a user authenticates on a Windows device using a hybrid identity, Azure AD issues partial Kerberos tickets alongside the Primary Refresh Token (PRT). Windows sends a request to Azure AD, indicating that it wants a Ticket Granting Ticket (TGT) by setting the
tgt parameter to
true. Azure AD responds with a partial TGT that can be used for Azure AD Kerberos.
To convert the partial TGT into a full TGT, Windows sends a TGS-REQ message to a Domain Controller. The Domain Controller replies with a TGS-REP message containing a new TGT, which now includes a full Privilege Attribute Certificate (PAC) with all user attributes and group memberships.
NTLM Authentication with Cloud Kerberos Trust
Cloud Kerberos Trust also supports NTLM authentication for services that don’t support Kerberos. Microsoft designed an extension to the Kerberos protocol that allows RODCs to obtain the NT hash of a user when exchanging a partial TGT signed with a secondary
krbtgt key for a full one signed with the primary
To request the NT hash, the
KERB-KEY-LIST-REQ field must be included in the PADATA part of the request. The KDC will then include the long-term secrets, such as the NT hash of the user account’s password, in the reply.
Leveraging Cloud Kerberos Trust for Lateral Movement
An attacker with Global Admin privileges in Azure AD can exploit Cloud Kerberos Trust to elevate their access to Domain Admin in a hybrid environment. This attack requires the following prerequisites:
- The attacker has Global Admin privileges in Azure AD.
- The attacker has network connectivity to at least one Domain Controller of the on-premises AD.
- Cloud Kerberos Trust is set up and functioning correctly.
Potential Attack Scenarios
There are several methods to gain access to a hybrid account and perform the attack:
- Obtaining the password for any synced account.
- Resetting the password for a hybrid account via the Admin Portal.
- Changing the password for a synchronized Azure AD account using the Synchronization API.
- Assigning passwordless credentials to the account.
- Creating a new user account with a known password via the Synchronization API and setting the target SID directly.
The target account should have Domain Admin or equivalent privileges and should not be denied in the RODC replication configuration. The ideal target would be the AD Connect Sync service account, which has Domain Admin-equivalent privileges and is not synced to Azure AD.
Defending Against Cloud Kerberos Trust Attacks
To secure your hybrid environment against potential Cloud Kerberos Trust attacks, follow these best practices:
- Protect your highly privileged Azure AD identities using the available security tools.
- Ensure that highly privileged users exist only in the environment they manage. Avoid syncing AD admin accounts to Azure AD and vice versa.
- Add additional accounts and groups to the “Denied password replication” list in the RODC configuration.
While Azure AD does not log changes to the SAM name and SID property, you can monitor for irregular activity by tracking changes made via the synchronization API. Pay attention to Global Admin accounts using the synchronization API, as this could indicate an ongoing attack.
Cloud Kerberos Trust is a powerful feature that enables passwordless authentication in hybrid environments. However, it also presents potential security risks that organizations must be aware of. By understanding the underlying mechanisms of Cloud Kerberos Trust, implementing robust security measures, and actively monitoring for suspicious activity, organizations can protect their hybrid environments from potential attacks.