We discovered that RC4 is still available in several places in our Active Directory environment. The krbtgt password is very old and appears to have only an RC4 key. Some service accounts occasionally use RC4 even though their msDS-SupportedEncryptionTypes attribute is blank; the accounts and requesting users appear to support AES. We also found a small number of computer accounts that only have RC4 keys. One account is AZUREADSSOACC$, used for Seamless SSO, and its password is about two years old. Should we fix the computer accounts first, or can we reset krbtgt immediately? For AZUREADSSOACC$, should we rotate its password or configure AES first, and does password rotation help with enforcement beyond generating AES keys?
3 Answers
Be especially careful with AZUREADSSOACC$. Verify the account name and whether Seamless SSO is still in use before changing it. If it is in use, roll the Seamless SSO Kerberos decryption key with the supported Azure AD Connect procedure first, then configure the account for AES; changing the encryption setting first can break Seamless SSO. The key is intended to be rotated regularly, so a two-year-old key deserves priority. Do not treat this account like an ordinary service account. For the old computer accounts, a password reset will normally create the missing AES keys, but check whether any legacy device or application depends on RC4 before enforcing AES globally.
The krbtgt account should be handled early, but do it carefully. Reset its password once, allow the new key to replicate throughout the domain and wait at least the normal ticket lifetime, then reset it a second time. The two resets are intentional because the current and previous krbtgt keys remain valid for ticket processing. Do not perform both resets back-to-back, and verify domain-controller replication first. Afterward, rotate passwords for accounts that lack AES keys; that generates AES keys even when the account’s password itself is unchanged from the user’s perspective. Only enforce AES after the dependent services and accounts have been tested.
The exact waiting period depends on ticket and replication settings, but using roughly 24 hours between krbtgt resets is a conservative operational practice. The important part is not to reset it twice immediately and accidentally invalidate active authentication across the environment.
Start by checking actual Kerberos usage rather than relying only on the encryption-type attributes. A blank msDS-SupportedEncryptionTypes value does not prove that an account is actively using RC4. Security event 4769 on the domain controllers can be filtered for RC4 ticket encryption, which usually produces a much shorter list of accounts to investigate. Confirm that replication is healthy before making key changes.
If Seamless SSO is no longer needed in the environment, confirm that carefully and remove or disable the account through the supported process rather than changing its attributes blindly. Otherwise, perform the key rollover before changing encryption settings.