On Active Directory trust settings, the option is available to enable “The other domain supports Kerberos AES Encryption“. Unfortunately, this setting is very sparsely documented by Microsoft and few resources online describes it.
Common questions are:
- If the AES option is not set, can AES ever be used when consuming resources across the trust?
- If the option is set, can only AES be used for Kerberos encryption, while RC4 is denied?
- What requirements need to be met before enabling the option?
- If enabled, what object and attributes are actually modified?
- Has Microsoft changed any of the default values regarding this setting over the years?
This article will answer these questions and explain the actual purpose of the “The other domain supports Kerberos AES Encryption” option.
When an Active Directory trust is created, a Trusted Domain Object (TDO) is created in both domains.
The TDO object is stored in the System container in the domain root. The System container can be viewed with, e.g., ADSIEDIT, but also Users and Computers. The container is only visible when enabling “Advanced view” in Users and Computers. The name of the TDO is the fully qualified domain name of the remote side of the trust.
Typically, trusts and trust settings are managed through the “Domains and Trusts” GUI tool. The options that are configured are stored in the TDO object in the Systems container.
Active Directory trusts have terminology that can be confusing. If configuring a one-way trust, one of the domains will be “trusting“, which can also be stated as the domain having the “outgoing” trust. The “incoming” end of the trust is called the “trusted” domain. In illustrations, the trust is depicted as an arrow pointing from the trusting domain – towards the trusted AD domain.
The terminology and arrow visualization are often misunderstood. The users can not “ride the arrow” to consume resources in the other domain. Instead, the direction of access is opposite of the direction of the trust-arrow.
Authentication across trusts can use either the legacy NTLM or the stronger Kerberos protocol. This article discusses the use of Kerberos.
When users in the trusted domain are to access a resource in the trusting domain, Kerberos tickets must be issued. The Kerberos tickets can be encrypted with one the following three main algorithms: DES, RC4, and AES. By far, the most robust and strong encryption method is AES. Windows supports AES with a length of 128 and 256 bits. For Kerberos to work, the client, the resource server, and the Domain Controller must support the same encryption method.
To utilize AES, in either 128 or 256 bit form, the domain must be running on Windows 2008 or later. Any legacy domain, or computer, running, e.g., Windows Server 2003, or Windows XP on the client side, will not be able to managed Kerberos tickets encrypted with AES. Obviously, these operating systems are out of official support since many years.
Additionally, since the release of Windows 2008 R2 and Windows 7, the old and weak DES encryption method is, by default, forbidden for usage of Kerberos ticket encryption. This leaves the RC4 and the AES methods available for the currently supported operating systems.
In an one-way forest trust, the option “The other domain supports Kerberos AES Encryption” can be set in the trusting domain only.
Assume a situation where a user in the abc.int domain, called abc-user-01, is to access a file server called xyz-srv-01 in the xyz.int domain.
To access the file server, the user needs two Kerberos tickets related to the remote domain: a Kerberos referral Ticket Granting Ticket (TGT) for xyz.int, and also a service ticket for the actual resource, here the file server.
Below is the Kerberos encryption options set directly on the file server computer object in the remote Active Directory:
Typically, when consuming a resource with Kerberos as authentication method, the attribute msDS-SupportedEncryptionTypes on the hosting computer object (or service account) determines the allowed encryption methods. Above is the file server in the resource domain, with the default value of 28, meaning RC4, AES128, and AES256 are allowed.
However, the AES option on the trust object itself is not enabled. Would we still be able to acquire the stronger AES encryption when consuming the file server in the remote domain?
To make matters slightly more complex, the result will be different depending on whether the November 2022 Kerberos Update is installed or not.
The user account abc-user-01 in the abc.int domain now attempts to reach the file server xyz-srv-01 in the xyz.int domain. Let us investigate the results with the following setup:
The AES-trust flag not set, and the November 2022 patch not installed.
For the user account “abc-user-01”, using the command line tool klist, we can see that the cross-forest referral Ticket Granting Ticket (TGT) for the remote domain is not encrypted by AES, but the weaker RC4.
However, the Kerberos service ticket, from the trusting domain, for the actual file server access, is indeed encrypted with the much stronger AES256. This value is determined by the msDS-SupportedEncryptionTypes on the computer object in the remote domain.
Still with the AES option on the trust not enabled, the non-set GUI option has the following value on the corresponding TDO :
As shown, the attribute value of the msDS-SupportedEncryptionTypes is blank on the TDO object when the AES option is not set in the GUI.
Assume now that we use the Domains and Trusts tool and do enable the “The other domain supports Kerberos AES Encryption” in the trusted domain.
The GUI change will result in this change on the TDO object:
The checkbox in the Domain and Trusts tool alter the blank default value of the msDS-SupportedEncryptionTypes attribute of the TDO object to the value 24. This number translates to:
24 = Allow only AES128 and AES256.
When the client user again access the resource in the trusting domain, the Kerberos TGT ticket for the remote domain is now encrypted with AES-256.
(Additionally, the service ticket to the resource itself remains as previously, i.e., determined by the computer object or service account itself.)
The AES-trust flag not set, but the November 2022 patch is installed on Domain Controllers.
We will now investigate the difference where the GUI option is not set on the domain, but the Domain Controllers have been updated with the November 2022 Kerberos patch.
The “The other domain supports Kerberos AES Encryption” is not enabled.
Yet again the end-user client attempts to access a resource across the forest trust. Two Kerberos tickets must be issued for the remote domain: one TGT referral ticket and one service ticket for the resource itself.
In the pre-November 2022 state, the referral TGT ticket was encrypted with RC4 when the AES option was not set. Now, with the AES option not enabled on the trust, the cross-forest TGT is, automatically, encrypted by AES.
This difference in the behavior is due to Microsoft, in the November 2022 Kerberos update, silently changed the interpretation of a blank value of msDS-SupportedEncryptionTypes of the TDO trust object.
Before November 2022, an empty TDO value was interpreted as RC4.
After November 2022, an empty TDO value is interpreted as AES.
(This behavior also removes all cross-forest Kerberos interoperability with any potentially remaining Windows 2003 domains.)
With the November 2022 patch installed on the Domain Controllers, and the AES value not set explicitly on the trust, we still receive an AES encrypted cross-forest TGT referral ticket. The internal change of behavior basically enforces the use of AES for all cross-forest referral TGT tickets.
Note that RC4 still works, if needed, when accessing resources across the trust. Suppose a remote service is running as a service account with AES not enabled:
An empty msDS-SupportedEncryptionTypes on a user account is interpreted as RC4. For any service running as a user account (not gMSA or running as local SYSTEM), it is crucial to add the AES bits.
When consuming this resource across the trust, we receive a Kerberos service ticket encrypted with RC4. The non-security optimally configured service account, implicitly only allowing RC4, will still work over the “AES-enforced” trust.
Kerberos encryption algorithms across trusts:
| Cross-forest TGT referral ticket | Cross-forest service with AES enabled | Cross-forest service without AES enabled | |
| Pre-November 2022 AES trust option OFF | RC4 | AES | RC4 |
| Pre-November 2022 AES trust option ON | AES | AES | RC4 |
| November 2022 patch AES trust option OFF | AES | AES | RC4 |
| November 2022 patch AES trust option ON | AES | AES | RC4 |
KEY POINTS:
- The trust option “The other domain supports AES Encryption” only relates to the cross-forest TGT referral tickets.
- Encryption algorithm for service tickets for accessing resources across the trust is determined by settings on the computer and service accounts in the trusting domain.
- After November 2022, the GUI option on the trust object have no meaning since the AES option is enforced.
RECOMMENDATION:
Enable the option in the GUI in Domains and Trusts. This aligns the visual setting with the actual enforced value and prevents confusion, as well as avoiding false positives in security reviews.