Hi everyone, Alex here again.
Today we’re talking about a change in Active Directory authentication that may look small on paper but could have very real operational consequences if administrators are not prepared. In just over a month, the April Windows update will shift Kerberos service tickets to AES encryption by default, moving domains further away from the long-standing RC4 fallback.
For most modern environments this transition should happen quietly in the background. But as always with authentication infrastructure, the real world is rarely perfectly clean. Legacy systems, forgotten service accounts and older devices can quickly turn a cryptographic improvement into a troubleshooting marathon.
Let’s take a closer look at what is changing and what administrators should be checking right now before enforcement becomes the default behaviour.
Why Microsoft is pushing Kerberos toward AES
Kerberos has supported AES encryption since Windows Server 2008, yet many environments still rely heavily on RC4 due to compatibility and historical configuration decisions.
The problem is that RC4 is considered cryptographically weak by modern standards. Over time it has become a favourite target in credential-theft techniques such as:
-
Kerberoasting
-
Ticket cracking attacks
-
Offline password brute forcing
By defaulting Kerberos tickets to AES encryption, Microsoft is continuing its broader effort to eliminate legacy cryptographic dependencies across the Windows ecosystem.
For organisations that have already modernised their environments, this change should be largely invisible. But older configurations can expose a number of edge cases.
Service accounts without msds-supportedEncryptionTypes
One of the most important areas to review is service accounts that have Service Principal Names (SPNs) but no value configured in the msds-supportedEncryptionTypes attribute.
Until now, these accounts have typically defaulted to RC4 encryption for service tickets. After the domain moves into enforcement mode, that behaviour changes. Service tickets will automatically shift from RC4 to AES.
If the receiving application servers support AES, the transition will happen smoothly. But from a change management perspective, administrators may not want hundreds of services switching encryption algorithms at exactly the same moment.
A practical way to control the transition is to roll out AES support gradually.
Administrators can incrementally configure the attribute with the value:
msds-supportedEncryptionTypes = 24 (0x18)
This explicitly enables AES and allows service accounts to transition before enforcement becomes mandatory.
Logging requirements: events 201–209
Another area that frequently surprises administrators is logging visibility.
The Kerberos monitoring events 201–209 only appear if the domain controllers are already logging event 4769, which represents service ticket requests.
If that auditing is not enabled, administrators may mistakenly believe that everything is working normally while potential problems remain invisible.
A quick validation approach is to create a controlled test scenario.
Configure a single domain device so that it only supports RC4, then request a service ticket from an account configured for AES. The resulting mismatch should generate the relevant events in the security logs, confirming that auditing is functioning correctly.
Without proper auditing in place, troubleshooting Kerberos encryption issues becomes significantly more difficult.
Legacy Windows systems will stop working
Perhaps the most straightforward — and controversial — part of the transition concerns very old Windows systems.
When the operatingSystemVersion attribute of a computer account is less than 6, the Kerberos Key Distribution Center ignores the msds-supportedEncryptionTypes setting.
Once enforcement mode changes the domain default to AES, these systems will begin receiving AES-encrypted tickets by default.
Older platforms such as:
-
Windows Server 2003
-
Windows XP
-
other pre-Vista systems
do not support AES encryption for Kerberos. As a result, they will reject the tickets entirely, effectively breaking authentication.
From a security perspective this is not really negotiable. Systems that old represent a significant risk to the domain. If they still exist in the environment, the upcoming change simply forces a decision that should probably have been made years ago.
Third-party devices may also be affected
Kerberos authentication is not limited to Windows machines. Many network appliances, storage systems and other third-party devices integrate with Active Directory for authentication.
The same logic applies to those devices.
If a computer object contains an operatingSystemVersion value below 6, the domain controller ignores the encryption configuration. This means that when the domain defaults to AES, these systems may also encounter authentication failures.
In cases where a device does not support AES, administrators may need to adjust the computer object attributes manually.
Possible workarounds include:
-
setting the
operatingSystemVersionattribute to null -
changing the value to something greater than 5
-
or using a non-numeric value
Once that attribute no longer triggers the legacy logic, administrators can explicitly configure the encryption type with:
msds-supportedEncryptionTypes = 4
which forces RC4 usage for that specific object.
Of course, this should be treated as a temporary compatibility workaround, not a long-term solution.
Event 4768 is your best detection tool
While the new 201–209 Kerberos events warn about failures, administrators should not rely on them as the primary detection method.
A far more effective approach is proactively analysing event 4768 and event 4769.
These events include the Advertised Etype field, which indicates what encryption algorithms the requesting device supports.
Devices that only advertise RC4 support can be identified long before enforcement begins.
This allows administrators to locate problematic systems early, investigate compatibility requirements and plan remediation without waiting for authentication failures to appear in production.
Final thoughts
The upcoming shift to AES-by-default Kerberos tickets is part of a much broader effort to modernise security across the Windows platform.
For most environments the transition will be uneventful. Modern Windows versions, properly configured service accounts and updated infrastructure already support AES.
But environments with legacy systems, unmanaged service accounts or older third-party integrations may encounter issues if the transition is not planned carefully.
Administrators should use the remaining time before enforcement to:
-
review service accounts and SPNs
-
verify Kerberos auditing on domain controllers
-
identify devices limited to RC4 encryption
-
validate compatibility for older systems and appliances
Kerberos authentication sits at the very heart of Active Directory security. When cryptographic defaults change, even small oversights can create widespread operational impact.
The good news is that with the right visibility and preparation, this transition can be handled smoothly — and ultimately leaves your domain significantly more secure.