RC4DefaultDisablementPhase - How to Identify Accounts Affected by Kerberos Hardening

The Kerberos hardening documented in KB5073381 is getting closer to being enforced. In just a few weeks, Microsoft will release a cumulative update that will establish AES as the default encryption for service accounts. At this point, it's recommended to have an advanced RC4 usage audit, a topic I'll cover in this article. And be warned! There are some surprises coming...

Command to identify potentially affected accounts

There are three criteria for identifying accounts that can have authentication issues after Kerberos hardening:

1. It's a user, machine, or service account. It doesn't affect trust relationships.

2. The account has one or more SPNs registered.

3. The account does not have the msDS-SupportedEncryptionTypes field set, or it is set to 0.

This starting point is essential for a complete understanding of the potential impact. To obtain all the accounts, we can use a command I've prepared:

get-adobject -filter "(-not msDS-SupportedEncryptionTypes -bor 0x1f) -and ServicePrincipalName -like '*' -and (objectclass -eq 'computer' -or objectclass -eq 'user' -or objectclass -eq 'msDS-ManagedServiceAccount' -or objectclass -eq 'msDS-GroupManagedServiceAccount' -or objectclass -eq 'msDS-DelegatedManagedServiceAccount')"

With the result of this command, we should notify the administrators of each account so they can confirm with their application providers that their applications support AES encryption.

Events Dedicated to Hardening

If the January 2026 cumulative update or a later update has been installed on the Domain Controllers, there are audit events that will partially assist with hardening. The appearance of these events depends in part on whether the following registry keys are configured on the Domain Controllers:

• HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC

• DefaultDomainSupportedEncTypes

• Values: msDS-SupportedEncryptionTypes

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\kerberos\parameters

• RC4DefaultDisablementPhase

• Values: No Auditing (0), Audit Mode (1), Forced Hardening (2).

These events are numbered 201-209 and will appear in the System log of the DCs. Its appearance will alert us of situations that need to be addressed, particularly client machines that do not support AES and service accounts that lack AES hashes in Active Directory. Here is a summary of the conditions that trigger the events:

Event 201

• Client machine can only use RC4.

• Service without msDS-SupportedEncryptionTypes defined.

• DC without DefaultDomainSupportedEncTypes defined.

• RC4DefaultDisablementPhase set to 1.

Event 202

• Service without AES keys.

• Service without msDS-SupportedEncryptionTypes defined.

• DC without DefaultDomainSupportedEncTypes defined.

• RC4DefaultDisablementPhase set to 1.

Event 203

• Client machine can only use RC4.

• Service without msDS-SupportedEncryptionTypes defined.

• DC without DefaultDomainSupportedEncTypes defined.

• RC4DefaultDisablementPhase with a value of 2.

Event 204

• Service without AES keys.

• Service without msDS-SupportedEncryptionTypes defined.

• DC without DefaultDomainSupportedEncTypes defined.

• RC4DefaultDisablementPhase with a value of 2.

Event 205

• DC with DefaultDomainSupportedEncTypes defined with a value other than AES.

Event 206

• Client can only use RC4.

• msDS-SupportedEncryptionTypes or DefaultDomainSupportedEncTypes with a value of AES only.

• RC4DefaultDisablementPhase with a value of 1.

Event 207

• Service without AES keys.

• msDS-SupportedEncryptionTypes or DefaultDomainSupportedEncTypes with a value of AES only.

• RC4DefaultDisablementPhase set to 1.

Event 208

• Client can only use RC4.

• msDS-SupportedEncryptionTypes or DefaultDomainSupportedEncTypes set to AES only.

• RC4DefaultDisablementPhase set to 2.

Event 209

• Service without AES keys.

• msDS-SupportedEncryptionTypes or DefaultDomainSupportedEncTypes set to AES only.

• RC4DefaultDisablementPhase set to 2.

Client computers that can only use RC4 must modify the policy ‘Network Security: Configure Encryption Types allowed for Kerberos’. Services without AES keys will require a password reset (and likely, keytab recreation) to generate only an RC4 key. Interestingly, if an account only has AES keys in Active Directory, it's likely that its password hasn't been changed since before Windows Server 2008 version was deployed on a domain controller... or a very unusual situation has been created to prevent it from having other hashes (it's not easy to create an account with a password only in RC4).

It's worth noting that these situations Microsoft is warning about, especially those related to events 206 and 207, are anomalous. Due to a glitch, it is still possible to obtain tickets with RC4 encryption even when the service account attempts to force the use AES256. This is corrected with the hardening, making it impossible to continue exploiting this small security vulnerability.

Getting TGS: Event 4769

In addition to the hardening events, we also have the Security log events that inform us about the generation of Kerberos tickets: 4768 (TGT) and 4769 (TGS). Since we are only interested in services, we will only consider event 4769. What additional information does this provide? It helps us see which services are using RC4. We should look at the service name to identify the service account and at the ticket encryption type (etype). Those with a value of 0x17 (23) or 0x18 (24) indicate current RC4 usage. Logically, with the enormous number of events in the Security log, using a SIEM to filter information from millions of events becomes essential.

Conclusion

We've seen up to three ways to obtain accounts and audit data to avoid impact on April update. All three have their purpose and are useful to different degrees. But why do we need so much information?

1. The command to identify potentially affected accounts serves as a basis for understanding which accounts might cause problems if the service is not compatible with AES. In other words, all accounts affected by the DDSET modification.

2. Auditing events 201-209 help us identify client computers that do not support AES and service accounts without AES keys. Both scenarios anticipate authentication problems after hardening, including those triggered by a glitch that Microsoft will fix. However, services using RC4 keytabs might go undetected in these events.

3. Event 4769 displays information for each generated TGS ticket. This help us to identify if an account potentially affected is actually being used for services. We may have accounts with SPNs that are not being used and, therefore, will not be affected by the hardening.

In the next content, the last in this series dedicated to Kerberos hardening, I will show you how to handle the different phases of this hardening, including the cumulative updates from January, April, and July. I hope you find it useful!