Background
Flash back to the late 80's...mullets for all, Polo drenched teens, big hair, and RC4 in all it's glory. Life was good. Flash forward to now and all of these things are out of style. In the case of RC4, it is the encryption equivalent of a rotary dial phone and its getting downright irresponsible to keep it around so the IT world is on a crusade to eliminate it. Why would you need RC4 you might be asking? Well, in a strictly modern Windows environment where all items are configured correctly, you shouldn't need it. AES 128 and AES 256 Have been around since Vista/2008 and Windows 7/2008 R2 respectively. The Kerberos negotiation process will settle on the highest level of encryption supported. Now the tough part, a lot of non-Windows systems may either not be configured for the newer encryptions or might not support the newer encryption methods at all. Additionally, misconfigurations of the msds-suppportedEncryptionTypes attribute can also cause the negotiations to settle down to weaker encryption types. You've fixed all of that? Good job!!
Trust Check-Up
One item that is easy to overlook is the encryption support setting on the Trust properties, especially in a parent/child trust that is created automatically. In most cases, these trusts are created and never touched again. Our poor ignored forest trust is about to get some much needed attention. You can check the current setting of the trust by opening the Domains and Trusts console (domain.msc) and right-clicking the forest root domain, and select properties. Select the Trusts tab, highlight the trust, and then click the Properties button. The setting The other domain supports Kerberos AES Encryption will determine whether the trust supports AES encryption or not.
ADSIEDIT.msc msds-SupportedEncryptionTypes value before checking the AES setting on the trust
External Trusts
If you are dealing with a trust that was set up as an external trust, there are some things to keep in mind:- The Domain Functional level needs to be at least 2008.
- The trust must be created using the full DNS domain to support Kerberos referrals
- Kerberos ports (88 & 464) and LDAP ports (389) need to be open
Finding the Evidence
I witnessed this exact same issue recently where RC4 had been disabled and the reported behavior was that systems in the child domain were unable to browse to the SYSVOL or NETLOGON shares in the parent domain. A network trace with Message Analyzer showed what was happening. Notice in the capture details below that in the Pre-Authentication Data section of the Ticket-Granting Service Exchange is using RC4.

Recap
The journey to remove RC4 is not without heartache. The more diverse the environment, the tougher it is to get all systems configured to support AES. Unfortunately we are heading to a point where this configuration has to be dealt with. Systems that can't support AES encryption are increasing the risk of the systems in your environment and it's time to either update, upgrade, or replace systems that are not compliant. I hope this helps you on your path to improve the security of your environment. Until next time.Joel Vickery
Published Nov 26, 2019
Version 1.0Joel Vickery
Microsoft
Joined September 11, 2018
Core Infrastructure and Security Blog
Follow this blog board to get notified when there's new activity