RC4-HMAC has long been regarded as a insecure and attackble Encryption Algorithm. If it is used in an Active Directory Domain to encrypt Kerberos tickets, there is even the risk of a Kerberoasting Attackwhere an attacker can take over control of service account accounts.
For mitigation, disabling RC4-HMAC algorithms and enabling AES128 and AES256 algorithms of Kerberos tickets has been recommended since Windows Server 2008. For some incomprehensible reason, it was not until Windows Server 2019 that Microsoft decided to disable or no longer support RC4-HMAC by default.
If Azure AD Connect with Single Sign On is also used, it was not possible to disable RC4-HMAC until fall 2020 as the AES128/AES256 algorithms were not supported. In the meantime, the more modern algorithms are supported. In this article, I explain the necessary steps for switching to the more secure AES algorithms.
Let's first look at how we can identify authentication operations using the RC4 HMAC algorithm. Issuing a Kerberos ticket is done according to Enabling Kerberos Logging with Event ID 4769 logged in the security log on a domain controller. In the screenshot below, the following is displayed as Ticket Encryption Type the value 0x17 is specified:
According to the following listing, this is a Kerberos ticket encrypted with the RC4-HMAC algorithm:
- 0x11 - AES128-HMAC-SHA1
- 0x12 - AES256-HMAC-SHA1
- 0x17 - RC4-HMAC
To disable RC4-HMAC encryption, the following steps are necessary:
- Enable AES support in domain trusts (if trusts exist)
- Enforcing AES256 for the Azure AD SSO Account in Active Directory
- Roll-Over of the Kerberos Decryption Key (to enable SSO again)
- Disabling RC4-HMAC via Group Policy
1. enable AES256 support in AD Trusts
If multiple Active Directory domains are linked via trust, the RC4 algorithm is used by default for access to additional domains within the forest. Therefore, if we disable RC4-HMAC in the last step, access to additional domains within the forest is no longer possible without the subsequent change.
Use the following steps to enable AES256 support for domain trusts:
- Open Active Directory Domains and Trusts and navigate to the affected domain (in this example contoso.com)
- Click on the domain with the right mouse button contoso.com and then on Properties
- Select the Trusts tab and check in the box Domains that trust this domain (incoming trusts) the corresponding partner domain with a mouse click and click again on Properties
- Activate the box The other domain supports Kerberos AES Encryption and confirm with a click on OK
- Repeat these steps for the outgoing trusts and in the corresponding partner domain analogously.
2. enforce AES256 for Azure AD SSO
To make the switch to AES256 as non-disruptive as possible, we explicitly enforce AES256 on the Azure AD SSO account before globally disabling RC4-HMAC via group policy.
Use the following steps to enforce AES256 for the Azure AD SSO account:
- Open Active Directory Users and Computers and activate the Advanced Features in the menu bar under the item View
- Navigate to the OU where the AZUREADSSOACC object is located and open it with a double click.
- Click on the Attribute Editor tab and navigate to the entry msDS-SupportedEncryptionTypes
- Set the value for the entry 16 and confirm with OK
3. rollover of the SSO decryption key
After enforcing AES256 for the Azure AD SSO account, we need to renew the Kerberos Decryption Key in Azure AD to ensure that SSO continues to work.
The rollover of the SSO decryption key is done with a few steps. Since there are already extensive and very good instructions for this, I have refrained from creating another tutorial 🙂 This tutorial is in my opinion one of the best and most understandable: Roll over Kerberos decryption key for Seamless SSO computer account - Azure Cloud & AI Blog
Side Note: Securing the Azure AD SSO Account
When you set up SSO, Azure AD Connect automatically creates a computer account ("AZUREADSSOACC"). This account represents the Azure AD in Active Directory.
This is how a login via SSO works: The user's browser requests a Kerberos ticket for the AZUREADSSOACC account. Upon a successful login, a Kerberos ticket is issued by a domain controller for that computer account and sent to the browser. The browser then logs in to Azure AD using the Kerberos ticket.
Since all login operations are performed via the AZUREADSSOACC account, it is classified as extremely sensitive. If this account is successfully attacked, the attacker can gain access to the resources of users who log on via SSO. For this reason, Microsoft recommends rollover the Kerberos Decryption Key every 30 days!
4. disable RC4-HMAC via GPO
We have now completed all preparations and can finally get rid of RC4-HMAC with the help of a group policy!
- Open the Group Policy Management (gpmc.msc) and navigate to Group Policy Objects
- The following changes should be made in a Group Policy that is applied to all computer objects in the domain.
- Open the desired group policy object by right-clicking on it and clicking on Edit
- Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
- Open the policy Network security: Configure encryption types allowed for Kerberos
- Deactivate the following entries and confirm with a click on OK:
- DES_CBC_CRC
- DES_CBC_MD5
- RC4_HMAC_MD5
Now that you have completed all the work and all Domain Controllers have applied the new policy setting, you will see in the Security Log that only AES256 (or AES128) Kerberos tickets are being issued:
Tobi is focusing for more than 15 years in Information Technology. After a successful exit of his Microsoft-focused hosting company, he helps SMBs to secure and automate their cloud environments.
English 
Deutsch
People reacted to this story.
Show comments Hide commentsThanks Tobi for the nice article! We just recently enabled SSO for Azure AD and I used this article as a guide for changing the encryption from RC4-HMAC to AES256-HMAC-SHA1.
thank you thank you.