Managing Active Directory: Removing RC4 encryption from your domain

I manage a few Active Directory domains as my day job. Over several years, I have address a host of AD related challenges, so I figured I would share this one in case it helps another AD admin out there.

I was able to finally remove the deprecated encryption, RC4, from our primary domain. This took weeks of planning, troubleshooting, auditing, and some head-scratching moments. I will outline a potential playbook if you want to remove RC4 on your schedule instead of when Microsoft removes RC4 on their schedule.

Step 1 - Read the documentation

Reviewing the Microsoft documentation is where you should begin:

https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos

Wish I had more insight, but this article should be the foundation for your RC4 removal strategy.

Step 2 - Know your environment before you change it

Like with most things in IT, you need to know what you have first before you plan on changing it. Find out what encryption types your Domain Controllers (DCs) currently support. Unless you are enforcing supported encryption types on your DCs via:

GPO

Local registry settings

msDS-SupportedEncryptionType attribute on the DC's computer object

That means your DCs are accepting RC4 as an encryption type.

"Encryption type for what?", you may ask. Primarily the encryption I am talking about is used for Kerberos ticket requests. Clients (workstations and servers) negotiate with the DCs to determine the best encryption type to use during Kerberos requests. Unless you tell your DCs explicitly NOT to use RC4, they will. You might be tempted to just turn it off, but if your clients do not support stronger encryption like AES128 and AES256, then your clients will not have a way to request Kerberos tickets anymore.

Step 3 - Audit. Re-Audit. Audit some more.

Find events for Kerberos authentication tickets (Event ID 4768) and Kerberos service tickets (Event ID 4769). Hopefully you have a SIEM solution like Splunk where you can search through all your DC's Event Logs in one place. Otherwise, you will need to check these Event Logs from each DC. You will be looking for the attribute "Ticket Encryption Type" on those 2 events. You can find tables that show what each value means, but the TL;DR version is that 0x17 means that ticket used RC4 encryption.

If you found RC4 being used, you need to know if your clients can use higher level encryption (AES). Modern operating systems support both AES types out of the box, so unless you have Windows 7 workstations and Windows Server 2008 in your domain, then the clients are ready to use AES. However, the users and service accounts might be another story.

Step 4 - Identify the RC4 culprits

I found the accounts that used RC4 encryption the most were service accounts that did not update their passwords. These accounts still had their original password from a time before AES was supported. AES support was typically added after the first Windows Server 2012 Domain Controller was promoted. I chose to focus on service accounts that had Service Principal Names (SPNs) configured. I made sure that the service account msDS-SupportedEncryptionType attribute was set to include AES support.

Common msDS-SupportedEncryptionType attribute values:

24 = AES128 + AES256

28 = RC4 + AES128 + AES256

30 = DES + RC4 + AES128 + AES256

This attribute applies to computer objects as well. In my environment, I found non-Windows storage devices that had their msDS-SupportedEncryptionType attribute set to 6. Yeah...6. That means they only supported DES and RC4. If I removed RC4 from the DCs, these non-Windows devices would no longer have a viable encryption type to use. Supported encryption type was configured at the OS level for these non-Windows devices, which in turn would update their computer object's msDS-SupportedEncryptionType attribute.

Step 5 - More auditing, please

After I knew that client computers and accounts supported AES, I was ready to audit some more. I kept checking Event IDs 4768 and 4769 for more RC4 usage. Glad I did, because I found some administrator accounts used to manage WiFi devices were explicitly set to use RC4 based on their msDS-SupportedEncryptionType attribute. Once those were updated to support AES, then the RC4 usage dropped considerably.

Now we can turn off RC4 on the DCs? No, because I noticed RC4 based tickets kept coming in from workstations, almost randomly. Turns out newly provisioned workstations would make a Kerberos request using RC4 initially, then their subsequent Kerberos requests used AES. Turns out they used RC4 because nothing was telling them NOT to. This took a while to figure out, but I was confident that the workstations would use AES, if forced.

Step 6 - Enforce what you already have

I highly recommend enforcing what your DCs currently support via GPO before setting it to only support AES.

Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.

Locate: Network security: Configure encryption types allowed for Kerberos.

Place a Check next to each of these:

RC4_HMAC_MD5

AES128_HMAC_SHA1

AES256_HMAC_SHA1

But Steve, I thought we want to REMOVE RC4, not enforce it! Enforcing what we already have before we implement the new setting makes the final step much easier to implement and more importantly, easier to revert.

Step 7 - Audit redux

You're going to hate this part, but before you change that GPO, you need to audit those same Event IDs again. Get to the point where you are so familiar with those Event IDs, that you will recognize the users and computer that show RC4 usage. For me, I took a few extra weeks before I was ready. I chose a manageable time period (3 days) to analyze events.

Step 8 - Uncheck that RC4 box!

Finally, after drastically reducing the RC4 usage and identifying the remaining RC4 usage, I was ready to uncheck RC4_HMAC_MD5 from the GPO linked at my Domain Controllers container in the domain.

After I finally removed RC4 support from my DCs, I kept an eye on those same 2 Event IDs for Failure Code 0x19, which would mean that a client tried to use the available encryptions (AES128/AES256) but could not. Due to all the prep work I detailed, I did not see any events with Failure Code 0x19 at all.

Removing RC4 is not a simple checkbox—it is a long journey full of preparation and observation. And mostly auditing.

Hopefully these steps help you prepare your environment, avoid outages, and keep Kerberos working. If you are planning your own RC4 removal, I wish you luck!