AD-KRB-005: RC4 readiness: Kerberos encryption settings of service accounts¶

low medium Kerberos MITRE ATT&CK T1558.003 Reads: LDAP

Enabled accounts with an SPN that are set to RC4 only, rely on the domain default, or look like they have no AES keys, read from configuration, not from the keys themselves.

Also known as: rc4-only, rc4-readiness

Why it matters¶

A service ticket is encrypted with a key of the service account. With RC4-HMAC (etype 23) that key is just the NT hash of the password, so offline guessing is far faster than against AES tickets, which go through thousands of PBKDF2 iterations per guess.

CVE-2026-20833 changed how the KDC picks that key. Updates from January 2026 added audit events, and later updates make AES-SHA1 (0x18) the KDC default for accounts without msDS-SupportedEncryptionTypes. Microsoft's article gives both April and July 2026 for the start of enforcement, and says the rollback value RC4DefaultDisablementPhase goes away in July 2026. That creates two different problems:

Accounts that keep RC4. An explicit value is honoured, so an account set to RC4 only still gets RC4 tickets, on a fully updated DC too.
Accounts that can break. An account that relies on the default gets AES only. That fails if the account has no AES keys (events 202/204, and 207/209 for AES-only values) or a client asks for RC4 only (201/203, 206/208).

An account gets AES keys when its password is set on a DC that can make them. A password older than the domain's first Server 2008 DC was never turned into AES keys.

How ad-doctor detects it¶

From the LDAP snapshot, over enabled users and computers with at least one servicePrincipalName; gMSA, sMSA and dMSA are skipped. Each account gets one line, and the line says which of these applies:

No AES in the value: msDS-SupportedEncryptionTypes is set and has neither 0x8 nor 0x10, for example 0x4, or Microsoft's 0x24. The value 0 counts as not set.
No value set: the domain default applies. Non-DC computers in this state are normal on non-Windows hosts, so they share one line with a count and the first five names. An attribute the account cannot read looks the same as no value.
Suspected no AES keys: the time the password was last set is more than an hour older than the whenCreated of the Read-only Domain Controllers group (RID 521), which the first Server 2008 DC creates. The hour allows for accounts made during domain creation. When pwdLastSet was not read, whenCreated of the account is used. pwdLastSet = 0 (must change at next logon) leaves the age unknown, so that account gets no such line. krbtgt is judged by this rule alone, even though it is disabled. For tier-0 accounts the older of pwdLastSet and the unicodePwd metadata counts (AD-ACC-012).
DC: the same rules on domain controller accounts, with DC in the line.

This reads configuration, not keys. Stored keys are not readable over LDAP, so the third line is a heuristic taken from PingCastle's S-AesNotEnabled and RC4_AD_Check. A faked pwdLastSet on a non-tier-0 account hides it. If the group cannot be read, the scan says so in a note and this part is skipped.

Not visible: DefaultDomainSupportedEncTypes and RC4DefaultDisablementPhase in the DCs' registry, the DCs' update level, and what clients ask for. A value with AES next to RC4, such as the usual 0x1C on a DC, is not reported.

Attributes and probes read

msDS-SupportedEncryptionTypes
servicePrincipalName
userAccountControl
objectClass
pwdLastSet
whenCreated
whenCreated of the Read-only Domain Controllers group (RID 521)
msDS-ReplAttributeMetaData (unicodePwd, tier-0 accounts only)

Severity¶

Medium when an account has an explicit value without AES, or is suspected of having no AES keys. Low when the only thing to report is that no value is set: after the 2026 KDC change that is usually fine, it just needs a look before a service breaks.

False positives and limits¶

No value set, and everything works. After the KDC change this is the expected state for an account with AES keys. Windows clients and an account whose password was reset after the 2008 move are fine. The DC events say more than this line can.
Suspected no AES keys, but the keys exist. The group date is a proxy. A domain restored or rebuilt from an old backup can also shift it.
A service that genuinely cannot use AES. Microsoft's way to keep RC4 is 0x24 on that account. Record it in an accepted-risk file and make the password 25+ random characters, so RC4 cracking stays impractical.

Fix¶

Look at the DCs first (read-only): KDCSVC events 201 to 209 in the System log name the account, the client and the available keys.

See the current values (read-only):

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' `
    -Properties 'msDS-SupportedEncryptionTypes', PasswordLastSet |
    Select-Object SamAccountName, 'msDS-SupportedEncryptionTypes', PasswordLastSet

Reset the password of accounts suspected of having no AES keys, with a long random password, before step 4: an AES-only value without AES keys makes the KDC deny the ticket. For krbtgt, rotate twice, waiting for replication in between. Keytabs of non-Windows services must be exported again.

Allow AES on each account (this sets 0x18):

Set-ADUser svc_web -KerberosEncryptionType AES128, AES256 -WhatIf

Test the service, then watch event 4769 on the DCs: the Ticket Encryption Type for this account should be 0x12 (AES256), not 0x17 (RC4).
Better: replace the account with a gMSA, as described in AD-KRB-003.

Avoid putting RC4 back in DefaultDomainSupportedEncTypes: Microsoft calls that a last resort, because it exposes every account in the domain.

Verify¶

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-KRB-005

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-KRB-005"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

References¶

Microsoft and vendors

Specifications

[MS-KILE]: Supported Encryption Types Bit Flags

Tools

MITRE ATT&CK

T1558.003

Available since 0.1.0.