I am pretty sure I am preaching to the choir, but just in case some of you haven´t noticed – RC4 support in Active Directory will no longer be supported after the July 2026 update. I will try to explain why and what to do, other than calling Mindcore off-course. 😉
The reason behind changing encryption mechanism is that RC4 encryption is too weak and an authenticated user can download the RC4 encrypted ticket, decrypt it and extract the password. With AES encryption in place this risk is removed.
Microsoft is implementing this change in 3 stages, where the first stage was in January 2026 and the third and final stage will be in July 2026.
January 2026 update (audit phase)
The audit phase introduces new event id´s that are specifically targeted to track the usage of RC4 in Active Directory Domains.
The following kdssvc event ID´s 201-209 were introduced:
Event ID 201 RC4 usage detected because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined.
Event ID 202 RC4 usage detected because the service account does not have AES keys and the msDS-SupportedEncryptionTypes attribute is not defined.
Event ID 203 RC4 usage blocked (enforcement phase) because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined.
Event ID 204 RC4 usage blocked (enforcement phase) because the service account does not have AES keys and msDS-SupportedEncryptionTypes is not defined.
Event ID 205 Detection of explicit enablement of insecure algorithms (such as RC4) in the domain policy DefaultDomainSupportedEncTypes.
Event ID 206 RC4 usage detected because the service accepts only AES, but the client does not advertise AES support.
Event ID 207 RC4 usage detected because the service is configured for AES, but the service account does not have AES keys.
Event ID 208 RC4 usage blocked (enforcement phase) because the service accepts only AES and the client does not advertise AES support.
Event ID 209 RC4 usage blocked (enforcement phase) because the service accepts only AES, but the service account does not have AES keys.
April 2026 update (enforcement with manual rollback)
Now the fun begins. The KDC begins operating in AES-only mode (0x18) when the msDS-SupportedEncryptionTypes attribute is not defined. This means RC4 is no longer accepted as an implicit fallback.
It is still possible to do a rollback and postpone, but you need to address issues before July, so if not already started, April is hopefully where you started reporting on the usage of RC4 in your environments.
Microsoft has created 2 scripts for reporting on the usage that you could use for this.
These can be found here: https://github.com/microsoft/Kerberos-Crypto/tree/main/scripts
The analysis relies on two primary scripts:
Get-KerbEncryptionUsage.ps1
List-AccountKeys.ps1
Get-KerbEncryptionUsage.ps1
The Get-KerbEncryptionUsage.ps1 script, provided by Microsoft as part of the Kerberos-Crypto repository, is designed to analyze how Kerberos tickets are issued within an environment. It does so by examining authentication events recorded on Domain Controllers.
Data collection is primarily based on the following security events:
Event ID 4768 Kerberos Authentication Service (AS-REQ / TGT issuance)
Event ID 4769 Kerberos Service Ticket Operations (TGS issuance)
From these events, the script extracts and aggregates key fields used to analyze authentication flows:
Time Timestamp of the authentication event
Requestor IP address or hostname initiating the request
Source Account requesting the ticket
Target Requested service or Service Principal Name (SPN)
Type Operation type (AS or TGS)
Ticket Encryption algorithm used for the ticket
SessionKey Encryption algorithm used to protect the session key
By correlating this data, the script provides an objective view of which encryption algorithms are actively used in the environment for both ticket issuance and session establishment.
This level of visibility is critical for identifying dependencies on legacy algorithms such as RC4 within the Kerberos authentication flow. It enables precise detection of clients, services, or accounts that still rely on outdated encryption methods.
List-AccountKeys.ps1
The List-AccountKeys.ps1 script is used to identify which long-term cryptographic keys are associated with user, computer, and service accounts. This allows organizations to verify whether RC4 is still required or if stronger encryption methods, such as AES128 or AES256, are already available.
This information is essential for assessing readiness to disable RC4 and transition fully to modern, more secure Kerberos encryption standards.
July 2026 update (final enforcement)
Starting in July 2026, audit mode and rollback options are removed. RC4 will only function if explicitly configured, a practice that is strongly discouraged.
What do I do now???
First of all, you could call us, then we will help you analyse and implement the needed changes.
If you have insights in to Active Directory and want to do it yourself, then the following is the approach.
Identify
Use the scripts to get an overview of the usage of RC4 in your environment.
Analyse
When the scripts are run and you know where RC4 is used, you need to find out why and start updating MsDS-SupportedEncryptionTypes attribute on your service accounts to support AES-128 and AES-256 instead of leaving the field blank.
Then go back to analyze to see what changed and identity accounts still using RC4.
That should be it..
Note that during this phase you stumble onto old systems like Windows XP and Windows server 2003. If these are expected to run you could enable RC4 for them, but it is strongly recommended that you start upgrading to modern platforms.
Good luck.
