Hey everyone,
I've been digging into the possibility of completely disabling RC4 encryption in my domain, but I find it a little confusing. As far as I understand, RC4 is like a fallback option where the Key Distribution Center (KDC) will use it if it doesn't detect that better encryption methods are available.
I've looked at the security event logs (event 4769) on our domain controllers, which show if RC4 is being used for ticket encryption. I found a few service accounts that seem to indicate RC4 is in use based on certain log entries.
One specific log mentions:
- Account Name: [email protected]
- Service Name: SA01
- Various supported encryption types, including RC4 and AES.
Now, it looks like the user account has an N/A in the MSDS-SupportedEncryptionTypes field, suggesting it might not be configured for any specific types. However, the service account has encryption types available, even though it doesn't show anything in Active Directory (AD) either. I'm puzzled about how that decision was made.
The logs do show that the advertised encryption types include AES, and since we don't actually have any legacy systems, I expected that would be the norm throughout our setup.
I'm thinking of adding the MSDS-SupportedEncryptionTypes attribute to support AES, changing the password, and then testing to see if authentication works without issues. But I'm feeling a bit hesitant about the risk involved in doing that. My other thought was to set both AES and RC4 as supported options, hoping that the highest available encryption type would be chosen.
Has anyone tackled this type of change before? Any advice would be appreciated!
4 Answers
Gotta love how 'improving security' feels like 'breaking everything' sometimes! It’s a bit of a balancing act, isn’t it?
First things first, make sure that the account actually has AES enabled and remember to reset the password after you enable it. The AES keys won't generate until you do that!
I started looking into this about a month ago because of RC4 events too. I had to reset some service account passwords, and honestly, I didn’t notice any issues after doing that. I even reset the krbtgt password twice. I followed a helpful guide that outlines all the dos and don’ts—here's a great resource you might want to check out! [Active Directory Hardening Series Part 4](https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-4-%E2%80%93-enforcing-aes-for-kerberos/4114965)
Unless you’ve got servers as old as Server 2003 or some ancient Linux systems, everything should be manageable to support just AES. Just keep in mind very old accounts with misconfigured passwords might cause issues. For computer objects, they manage the msDS-SupportedEncryptionTypes based on GPO settings, not manually. If it’s not set, the default settings will kick in.
Yeah, that’s what I mentioned at the end—adding AES to the MSDS-SupportedEncryptionTypes attribute and changing the password afterwards. Just making sure I cover my bases.