Disabling RC4 and forcing AES encryption
Posted by denstorepingvin@reddit | sysadmin | View on Reddit | 7 comments
Hey folks,
I've been looking into weather or not it's possible for us to disable RC4 encryption fully in the domain.
As i understand, RC4 is sort of native fallback encryption, if KDC doesn't detect that higher alternativies are a possiblity.
However, i find it a bit difficult to fully understand when and when it's not possible. I've reviewed security event logs 4769 on our DC's to get insights if any ticket encryption type was indicating that RC4 is being used.
I found a couple of service accounts, from events looking like this:
A Kerberos service ticket was requested.
Account Information:
Account Name:ACCOUNT@DOMAIN.COM
Account DOMAIN.COM
MSDS-SupportedEncryptionTypes:N/A
Available Keys:N/A
Service Information:
Service Name:SA01
Service ID:DOMAIN\SA01
MSDS-SupportedEncryptionTypes:0x27 (DES, RC4, AES-Sk)
Available Keys:AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes:0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys:AES-SHA1, RC4
Network Information:
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
RC4-HMAC-NT-EXP
RC4-HMAC-OLD-EXP
Additional Information:
Ticket Options:0x40810000
Ticket Encryption Type:0x17
Session Encryption Type:0x12
So as i understand it. The user account account@domain.com has N/A in MSDS-SupportedEncryption due to not having the attribute present or the attribute is empty within attribute editor.
SA01, somehow provides encryptiontypes, although not having anything specified in AD either under MSDS-supportedencryption. I don't understand how this was selected?
Advertized etypes confirms that the requested client, supports AES encryption. We do not have any legacy OS, so this is expected all around the infrastructure.
To get further in the testing, i can add MSDS-supportedencryption attribute with AES, change password and then test weather authentication breaks. However, i'm very uncertain if this is the proper way to go, i feel like it's a bit risky. I was thinking also, that i might be able to add AES and RC4 as supported encryption, then assuming it will grab the highest encryption option available if supported, right?
Anyone with experience doing this?
SteveSyfuhs@reddit
The answer is right in the event log:
You have a service that is explicitly configured to support DES, RC4, and this thing called AES-Sk. The keys available are AES-SHA1 and RC4. AES-Sk != AES-SHA1, therefore the only available etype that can be used is RC4. The whole name of the etype matters, not just a subset of it.
picklednull@reddit
Unless you're using Server 2003 or some ancient Linux somewhere, everything can be configured to support AES (only).
For computer objects, you don't manually set
msDS-SupportedEncryptionTypes, the computer manages it on its own based on the GPO configuration for Kerberos encryption types.For user objects with SPN's, you're supposed to set the tickboxes for "This account supports Kerberos AES xxx bit encryption".
If
msDS-SupportedEncryptionTypesis not set for an account, the types inDefaultDomainSupportedEncTypesare used by default. You need to configure it properly.Finally, what's ultimately allowed by the Domain Controller (or the client when the ticket gets returned?) is based on its GPO configuration for Kerberos encryption types.
It's also limited by what's actually stored for the account in NTDS.DIT (the Active Directory database) - until Server 2025, only the encryption key types that were configured as allowed in the Domain Controller's Kerberos encryption types policy were persisted. (And I suppose it's also limited by what the client provided at the time of its password change?) AFAIK, there's no built-in utility to audit what's actually stored in the AD database for an account.
If an account doesn't have a given encryption key type stored in the AD database, its password needs to be reset to persist the new encryption key types.
Asleep_Spray274@reddit
Ensure the account has aes enabled and the password has been reset after you enable it. It won't generate the AES keys until it gets a new password to generate them
denstorepingvin@reddit (OP)
Isn't that what i describe at the end by adding AES the the MSDS-supportedencryption attribute and changing the password afterwards?
Asleep_Spray274@reddit
Sorry, I dont think I made it that far down 🤷.
Ensure the device you are authenticating from also supports AES. The user, device and server you are going to needs to support AES
AegonsDragons@reddit
I did this last week and I haven't noticed anything breaking. I reset the password for the krbtgt password twice before I started making any changes. And I followed this guide to help. They have some updated info in it that explains Do and Don'ts Active Directory Hardening Series Part 4
CheekyPeachbuti@reddit
Don't you just love when 'improving security' means 'breaking everything'?