Enforcing AES for Kerberos: A Practical Guide

Over the years, RC4 encryption has proven to be weak, especially vulnerable to modern attacks like Kerberoasting. If you’re serious about hardening your environment, shifting to AES encryption for Kerberos authentication is a no-brainer.

Here’s the deal: the msDS-SupportedEncryptionTypes attribute on accounts determines what encryption types are used when Kerberos tickets are issued. If that attribute is empty (which is the default for most user accounts), the Key Distribution Center (KDC) falls back to using RC4. Not good.

But be warned — disabling RC4 across the board without proper preparation is risky. Many systems still rely on it, especially older or misconfigured ones. So before you flip the switch, it's critical to identify and fix RC4 dependencies.

A Better Way to Spot RC4-Only Devices

Historically, figuring out which devices still use RC4 hasn’t been easy. You might’ve looked at event ID 4769 for service tickets. But there’s a better method now.

Enter event ID 4768

This log captures TGT (Ticket Granting Ticket) requests. What’s new is that it now reveals the session key encryption type used with the TGT — not just the ticket encryption. That matters because the session key reflects what the client system actually supports and negotiated with the KDC.

If a device only supports RC4, the session key will be RC4 even if the TGT itself is encrypted with AES (which the client doesn’t read anyway). This makes event ID 4768 incredibly valuable in spotting devices that need attention.

Real-World Examples of RC4 Dependents

Here are four common scenarios where you’ll see RC4 pop up.

1. Devices using keytab files that only include the NTLM hash (RC4): You’ll need to generate new keytabs with AES-enabled credentials.
2. Non-Windows systems integrated into AD (Linux, NAS, etc.): Check their Kerberos configs; many support AES but default to RC4.
3. Windows machines with AES disabled via GPO or registry: This is a bad practice and should be reversed.
4. Legacy systems (Windows 2003, XP): If you're still running these, it's time to retire them. If not possible, use very strong passwords and consider insurance!

Planning a Smooth Transition

Once you’ve remediated those problematic systems, start updating service accounts — especially those with SPNs — to support AES. Don’t update them all at once, but don’t delay either. The longer RC4 stays around, the more risk you're carrying.

But here’s a catch: event ID 4768 only logs when a system authenticates. So if a service uses a keytab but never authenticates (i.e., doesn’t generate AS-REQs), you won’t see it in the logs. Those cases are rare, but be aware of the limitation.

Good News – Logging Just Got Better

Starting with the January 2025 Cumulative Update for Server 2016 and up, Microsoft enhanced Kerberos logging. Now 4768 and 4769 events show.

• The session key type for both TGTs and service tickets.
• What encryption types the client advertised during authentication.
• What keys were available on both client and service accounts.

This is a huge win for visibility.

Quick Notes from the November 2022 Update

That update changed how KDCs issue session keys. By default, they now prefer AES — but only if the device supports it. For service tickets, however, the selected encryption still depends on the msDS-SupportedEncryptionTypes value of the target account. So, don’t skip setting that.

Also, cross-domain referrals are now encrypted with AES by default — no need to tweak the trust settings anymore.

Do’s and Don’ts

Let’s wrap this up with some clear best practices.

• Do reset passwords for service accounts to generate AES keys
• Do set msDS-SupportedEncryptionTypes on SPN-enabled accounts
• Do monitor Events 16 and 27 on DCs for missing encryption keys
• Do disable RC4 using GPO after confirming the device is ready
• Do configure provisioning tools to set the correct encryption type

1. Don’t worry about regular user accounts without SPNs
2. Don’t manually edit computer account encryption types — they update automatically
3. Don’t touch the KRBTGT account unless you’re rotating it
4. Don’t rely on tools like ADMT to copy AES keys — they usually don’t

And lastly — don’t forget about ticket caching. Kerberos tickets can live up to 10 hours, so flush those caches when testing changes.

Wrapping Up

RC4 has had a long run, but it’s well past its expiration date. Modern Windows systems support AES out of the box, and the tooling has finally caught up to help you spot what still relies on RC4.

With enhanced event logging and smart remediation practices, phasing out RC4 is finally achievable — and safer than ever.

Need help setting up event forwarding or parsing 4768/4769 events.