US Edition Austin, TX UTC 00:00:00

Kerberos RC4 deprecation: find and fix RC4 usage after CVE-2026-20833

How the Kerberos RC4 deprecation (CVE-2026-20833) works, how to find RC4 with events 4769 and KDCSVC 201-209, and how to fix accounts and keytabs.

Microsoft has stopped letting Active Directory domain controllers assume that service accounts support RC4 for Kerberos. The change is tied to CVE-2026-20833. It started with audit events in January 2026, moved to enforcement with a manual rollback in April 2026, and became enforcement without the rollback switch in updates released from July 2026. To find what still depends on RC4, read the new fields in events 4768 and 4769 and the KDCSVC warnings on your domain controllers. To fix it, give the affected accounts AES keys and an explicit msDS-SupportedEncryptionTypes value.

This guide covers what changed, how to audit for RC4, and the fixes for the cases admins hit most often. The dates and values come from Microsoft's CVE-2026-20833 support article, its "Beyond RC4 for Windows authentication" blog post and the Learn guide to detecting and remediating RC4, as of October 2026.

Why Microsoft is removing RC4 as a default

RC4-HMAC tickets are a common target for Kerberoasting. An attacker with any domain account requests a service ticket for an account that has a service principal name (SPN), then cracks it offline to recover that account's password. A ticket encrypted with RC4 is much cheaper to crack than one encrypted with AES, and service accounts often have old, weak passwords. Microsoft covers the attack in its Kerberoasting mitigation guidance.

The November 2022 updates for CVE-2022-37966 already made AES the default for most accounts. RC4 was still the fallback when an account had no msDS-SupportedEncryptionTypes value and the client or the account's keys pointed to RC4. CVE-2026-20833 closes that fallback.

The CVE-2026-20833 timeline

  • January 13, 2026, initial deployment. Updates add KDCSVC audit events 201–209 to domain controllers. Admins can opt into enforcement early.
  • April 14, 2026, enforcement with manual rollback. For accounts with no explicit msDS-SupportedEncryptionTypes, the assumed default becomes 0x18, which means AES128 and AES256 only. Admins can temporarily return to audit mode with a registry value.
  • July 2026, enforcement. Updates released from July 2026 turn on enforcement programmatically and remove support for the rollback value.

As of October 2026, a domain controller with current updates is in the enforcement phase. Microsoft says explicit settings will still be honored: a value you set on an account, or a DefaultDomainSupportedEncTypes value on the KDC, overrides the new default. The fix for a broken dependency is therefore an explicit configuration, not an older patch level.

The rollback value was RC4DefaultDisablementPhase (REG_DWORD) under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. A value of 1 meant audit and 2 meant enforce. On domain controllers that run July 2026 or later updates, the value no longer has any effect.

Which accounts break

According to the support article, the change affects:

  • Service accounts with no msDS-SupportedEncryptionTypes value, when the client offers only RC4 or the account has only RC4 keys.
  • Accounts set explicitly to AES only, when the client does not offer AES or the account has no AES keys.
  • Non-Windows services such as Linux hosts, NAS appliances and Java applications that authenticate with a keytab containing only RC4 keys, when the AD account does have AES keys but no explicit encryption types. Microsoft calls keytabs the most common source of problems.

Microsoft notes that the KDC usually does not log the keytab failures; the non-Windows service itself reports the authentication error, so check application and system logs on those hosts too. The change applies only to Windows domain controllers. Trust and referral flows with other Windows domain controllers or third-party KDCs are unaffected.

How to find RC4 usage

KDCSVC events 201–209

Domain controllers with the 2026 updates log these KDCSVC events per request. The warnings 201 and 202 mean a request relied on the RC4 default: either the client advertised only RC4, or the service account had no AES keys. Under enforcement, these become 203 and 204, which mean the request was blocked. Events 206 and 207 warn about accounts set to AES only that the client or the stored keys cannot satisfy. Under enforcement, these become the errors 208 and 209. Event 205 is logged when DefaultDomainSupportedEncTypes explicitly enables insecure ciphers.

Security events 4768 and 4769

On Windows Server 2019 and later KDCs, events 4768 (TGT request) and 4769 (service ticket request) include extra fields. Windows Server 2016 gained them in the January 2025 cumulative update. The useful fields are:

  • MSDS-SupportedEncryptionTypes: the encryption types the KDC applied for the account, after processing.
  • Available Keys: the key types stored for the account in AD. RC4 with no AES entries means the password has not been reset since AES keys started being generated.
  • Advertized Etypes: what the client said it supports.
  • Session Encryption Type: what was actually used. 0x17 is RC4-HMAC, 0x11 is AES128 and 0x12 is AES256.

A failed request that shows failure code 0xE (KDC_ERR_ETYPE_NOTSUPP) in event 4769 is the usual sign that enforcement has blocked something.

Microsoft's audit scripts

Microsoft publishes two PowerShell scripts in its Kerberos-Crypto repository on GitHub. Both parse the security log on a domain controller:

  1. List-AccountKeys.ps1 lists the key types available for each account found in the log.
  2. Get-KerbEncryptionUsage.ps1 lists requests with the source, the target and the ticket and session key types. Run .\Get-KerbEncryptionUsage.ps1 -Encryption RC4 to see only RC4.

A single DC's log covers only that DC and only its retention window. For a domain-wide view, collect the events centrally with Windows Event Forwarding or a SIEM such as Microsoft Sentinel and filter on the same fields.

How to fix each case

The account has only RC4 keys

Reset the account's password. The reset creates AES128 and AES256 keys. This covers old service accounts and user accounts whose passwords have not changed in many years.

The account has no msDS-SupportedEncryptionTypes value

Set the value explicitly on the account that holds the SPN. 24 (0x18) means AES128 and AES256 only. 28 (0x1C) also allows RC4, so use it only while you finish a migration. To check the value:

Get-ADObject -Filter "Name -eq 'svc-app'" -Properties msDS-SupportedEncryptionTypes

For computer accounts, the value comes from the Network security: Configure encryption types allowed for Kerberos Group Policy setting. The machine writes the value to AD after a restart. Microsoft documents the full bit map in the Learn article.

A non-Windows service uses an RC4 keytab

Regenerate the keytab with AES keys, for example with ktpass and an AES crypto type, or with the keytab tool the product supports. Then restart the service. Also check the Kerberos configuration (often krb5.conf) on the Linux host or appliance in case it still restricts permitted encryption types to RC4.

A device really cannot do AES

Microsoft's preferred workaround is to set msDS-SupportedEncryptionTypes on that one service account to 0x24. That value allows RC4 for the ticket but uses AES session keys. The last resort is to set DefaultDomainSupportedEncTypes under HKLM\System\CurrentControlSet\services\KDC to 0x24 on every KDC. Microsoft warns that this leaves every account in the domain exposed to CVE-2026-20833. For third-party devices without AES support, Microsoft asks vendors and customers to write to stillneedrc4@microsoft.com.

Turning RC4 off completely

The CVE-2026-20833 change removes RC4 as the assumed default. It does not forbid RC4 that you configure explicitly. To remove RC4 entirely, use the encryption types Group Policy setting with only AES128_HMAC_SHA1 and AES256_HMAC_SHA1 selected. You can also set DefaultDomainSupportedEncTypes to 0x18 on the domain controllers. The Windows Server 2025 security baseline already disables RC4 for Kerberos, and Windows Server 2025 domain controllers do not issue RC4 TGTs. Roll out the setting one OU at a time and watch for 0xE failures before you widen it.

For other dated Windows changes, see our Patch Tuesday calendar and the Secure Boot certificate expiry guide. Ongoing coverage is in the Security and Vulnerabilities sections.

Frequently asked questions

What is CVE-2026-20833?

It is the Kerberos vulnerability that Microsoft cites for removing RC4 as the default assumed encryption type on domain controllers. The fix shipped in stages from January 2026 and was fully enforced by updates released from July 2026.

Can I still roll back Kerberos RC4 enforcement?

Not with the RC4DefaultDisablementPhase registry value, which is no longer supported from the July 2026 updates. You can still allow RC4 for a specific account with an explicit msDS-SupportedEncryptionTypes value, preferably 0x24.

What does msDS-SupportedEncryptionTypes value 24 mean?

24 (0x18) means AES128 and AES256 only. 28 (0x1C) adds RC4, 4 (0x4) is RC4 only, and 0 or no value means the KDC falls back to its domain default.

Which event IDs show Kerberos RC4 usage?

Security events 4768 and 4769 on domain controllers show the session encryption type and the available keys. KDCSVC events 201–209 flag requests that depended on the RC4 default or were blocked by enforcement.

Do I need to reset the krbtgt password?

Microsoft's CVE-2026-20833 guidance does not require it. If List-AccountKeys.ps1 shows that any account, krbtgt included, has no AES keys, a password reset is what generates them.