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.

 

 

If you are curious, you can check in ADSIEdit to look at the setting.  If you have dealt with RC4 or any other Kerberos issues, you are probably familiar with the msds-SupportedEncryptionTypes attribute that is configured on User and Computer objects to reflect their Kerberos encryption capabilities.  A domain trust in active directory uses this same attribute to configure AES support in this scenario.  Prior to checking the "The other domain supports Kerberos AES Encryption" checkbox, you will notice that the value on the attribute is set to zero.  After checking the setting on the trust, it changes to a value of 24. 

 

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

The full list of requirements is available at this URL.

 

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.

 

 

After enabling AES on the trust, the machines were again able to successfully browse to the parent domain.  Note that the Etype field is now using AES-256, much more secure than before.

 

 

As luck would have it, my lab did have one other issue that was causing issues related to RC4.  The krbtgt account had not had the password reset since upgrading the 2008 domain functional level. Normally, the password on the account at the DFL upgrade since AES support is enabled at this point.  The result was that, even with the correct cipher negotiation, my servers were still negotiating NTLM connections.  The solution was simple, run the krbtgt script from the TechNet gallery to update the account.

 

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