We discovered that RC4 is still available in several parts of our Active Directory environment. The krbtgt password is very old and appears to have only an RC4 key. Some service accounts occasionally use RC4, although their msDS-SupportedEncryptionTypes attribute is blank and both the accounts and requesting users appear to support AES. Only a few machine accounts seem to have RC4-only keys.
What order should we follow to remediate this? Should we fix the machine accounts before resetting krbtgt, or can krbtgt be handled first? For AZUREADSSOACC$, should we rotate its password or explicitly configure AES, and does password rotation affect RC4 remediation beyond generating newer encryption keys?
4 Answers
Once krbtgt is handled, rotate passwords for accounts that genuinely have RC4-only keys, including old machine accounts and service accounts where appropriate. A password reset generates AES keys; simply changing msDS-SupportedEncryptionTypes does not create missing keys. Before enforcing AES, test the applications and appliances that use those accounts, then set the domain policy or supported encryption settings to prefer or require AES after the legacy dependencies are resolved.
The blank supported-encryption-types attribute does not prove that RC4 is being used; it often means the account inherits defaults or remains capable of older encryption. Use the DC logs and the Microsoft RC4 detection/remediation guidance to identify actual RC4 use. A few old machines or appliances may need vendor-specific configuration to use AES, so validate those before enforcing AES across the domain.
Start by confirming what is actually using RC4 rather than assuming every account capable of RC4 is actively using it. Domain controller event 4769 can be filtered for ticket encryption type 0x17, which is RC4. Also check that the affected accounts already have AES keys; an account that has never had its password changed may need a password reset to generate them.
After confirming replication is healthy, reset the krbtgt password once, wait for the normal ticket lifetime to pass—commonly around 10–24 hours depending on your configuration—and reset it a second time. The two resets are important because the previous two krbtgt keys remain valid for ticket validation. Do not perform both resets immediately one after another.
Be careful with the account name: it is normally AZUREADSSOACC$. If Seamless SSO is still enabled, do not just set msDS-SupportedEncryptionTypes to AES first. Run the supported Azure AD Connect procedure, including Update-AzureADSSOForest, to roll the account’s Kerberos key, and only then change its encryption settings. Changing the attribute first can break Seamless SSO.
The account’s key should also be rotated regularly—Microsoft’s guidance uses a much shorter interval than two years. If Seamless SSO is no longer used, confirm that before disabling or removing the account rather than assuming it is unnecessary.
The important distinction is that this account needs the Azure SSO key rollover procedure, not merely an ordinary service-account password reset. Run it once per forest and verify the resulting configuration afterward.
The exact waiting period depends on your Kerberos ticket settings. A full day is a conservative choice, but the key point is allowing existing tickets signed with the older key to age out.