Kerberos RC4 hardening: reading the KDCSVC events and finding the accounts that break in April

Jan 21, 2026 · Samantha Kloos-Kilkens

Since the January 2026 updates, domain controllers log KDCSVC events 201 to 209 whenever a service ticket depends on RC4 in a way that the April 2026 update will stop allowing. The phase timeline for CVE-2026-20833 has been covered well elsewhere, so I'll keep that short and spend this post on the part that takes the actual work: what each event tells you, which accounts end up in them (and which ones never show up there), and how to find those accounts with PowerShell before April.

Photo: Planet Volumes on Unsplash

What the January update changes and what it leaves alone

Windows updates released on or after 13 January 2026 address CVE-2026-20833, where an attacker obtains service tickets encrypted with RC4 and tries to recover the service account password offline. The January update is mostly instrumentation: the audit events plus a temporary REG_DWORD, RC4DefaultDisablementPhase under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters (1 is the current default and only logs, 2 makes the KDC assume RC4 is not enabled by default, restart required). With the April 2026 update the assumed default for accounts without msDS-SupportedEncryptionTypes becomes AES-SHA1 only (0x18), with phase 1 still available as a manual rollback. In July 2026 the registry value is no longer read. Installing the January update does not mitigate the CVE by itself; you are only protected once a DC runs in phase 2.

Many environments depend on the behaviour April changes without anyone being aware of it. A service account without msDS-SupportedEncryptionTypes falls back to DefaultDomainSupportedEncTypes on the KDC, and when that isn't set, the KDC has assumed RC4 with AES session keys since the November 2022 changes. That is why a Windows 11 client that happily advertises AES still receives an RC4-encrypted ticket for the typical SQL or IIS service account in a user object.

Reading events 201 to 209

The events land in the System log of each DC (source Kdcsvc) and carry the service, its msDS-SupportedEncryptionTypes and available keys, the same for the DC, the DefaultDomainSupportedEncTypes value, the client address and the encryption types the client advertised. Most come in pairs: an audit event while the DC is in phase 1, and the matching block event once it enforces (the KB calls the latter errors, but its own table lists every event type as Warning, so don't filter on level).

201 (audit) and 203 (blocked): the client advertised only RC4, the service has no msDS-SupportedEncryptionTypes and the DC has no explicit DefaultDomainSupportedEncTypes. The account is fine; the client is the problem.
202 and 204: no attribute on the service and no explicit value on the DC, and the service account only has insecure keys. No AES keys means its password was last set before the domain could generate them. A client fix won't help here, the account needs a new password.
205: DefaultDomainSupportedEncTypes is explicitly set to something beyond AES-SHA1. Logged at every start of the KDC service and never turns into a block.
206 and 208: the service (through its own attribute) or the DC (through DefaultDomainSupportedEncTypes) is already AES-SHA1 only, and the client advertised only RC4.
207 and 209: AES-SHA1 only is configured, but the service account has no AES keys.

So 201 and 206 point at the client, 202 and 207 at the account, and the difference between the pairs is whether the AES-only requirement comes from the new default or from configuration someone already put in place. Two details from the KB change how you read the log. 201 and 202 are not logged at all when DefaultDomainSupportedEncTypes is set manually, so a DC with an explicit value that still includes RC4 shows you a 205 at boot and then nothing, while a DC where an earlier hardening attempt set an explicit 0x18 logs 206 and 207 instead of 201 and 202. The KDC keeps honouring an explicit value after April.

The events also have a blind spot, and in my view that is where most of the risk sits. They only fire when the KDC cannot produce what the new default requires. A service account without the attribute but with AES keys, contacted by a Windows client that advertises AES, generates no event: in April its tickets switch from RC4 to AES without anything being logged. A Windows service derives its keys from its password and won't notice. It breaks when the service side holds its own copy of the key and that copy is RC4 only, as with a keytab exported years ago with ktpass /crypto RC4-HMAC-NT or an appliance that was joined once and never touched again. The KDC issues a valid AES ticket, the service cannot decrypt it, and the error shows up at the service instead of on the DC. You find these through the 4769 events (Ticket Encryption Type 0x17 to accounts without the attribute), or with Get-KerbEncryptionUsage.ps1 -Encryption RC4 from Microsoft's Kerberos-Crypto repository.

Which accounts are actually at risk

User accounts with a service principal name are the main group: they rarely have msDS-SupportedEncryptionTypes, and the older ones lack AES keys. Windows computer accounts write their own attribute and rotate their passwords, so a computer object without the attribute is usually a Linux host, a NAS, an appliance or something that died years ago. gMSAs get their passwords from the DCs and have AES keys. The KDC encrypts TGTs with AES when krbtgt has an AES key, so check when the krbtgt password was last set; if that predates AES in the domain, a (double, 10 hours apart) reset was overdue anyway. Trusts are out of scope: the KB states that trust and referral flows to other Windows DCs or third-party KDCs are unaffected.

Finding them up front with PowerShell

First check what each DC is actually running with, because an explicit DefaultDomainSupportedEncTypes changes how you interpret everything else.

Get-ADDomainController -Filter * | ForEach-Object {
    Invoke-Command -ComputerName $_.HostName -ScriptBlock {
        [pscustomobject]@{
            DC    = $env:COMPUTERNAME
            DDSET = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' -ErrorAction SilentlyContinue).DefaultDomainSupportedEncTypes
            Phase = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' -ErrorAction SilentlyContinue).RC4DefaultDisablementPhase
        }
    }
}

Then collect the events from all DCs and group them by event, service and client, so you get a worklist instead of a log.

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{ LogName = 'System'; Id = 201..209 } -ErrorAction SilentlyContinue |
        Where-Object ProviderName -match 'Kdc|Key-Distribution'
} | ForEach-Object {
    [pscustomobject]@{
        Id      = $_.Id
        Service = if ($_.Message -match 'Service Name:\s+(\S+)')   { $Matches[1] }
        Client  = if ($_.Message -match 'Client Address:\s+(\S+)') { $Matches[1] }
    }
} | Group-Object Id, Service, Client | Sort-Object Count -Descending | Select-Object Count, Name

To find accounts without AES keys before they request a ticket, the usual shortcut is the creation date of the Read-only Domain Controllers group (RID 521), which arrived with the Windows Server 2008 generation that also brought AES to Kerberos. That trick holds in one direction only: a password last set before that date cannot have AES keys. After it, AES keys are likely but not certain, because tools that write only the NT hash (ADMT password migration is the classic example) give you a recent pwdLastSet without AES keys. In a domain created on Windows Server 2008 or later, the date is just the domain's creation date. The other suggestion, the date the domain functional level was raised, is harder than it looks: replication metadata on msDS-Behavior-Version only shows the most recent raise.

$domain  = Get-ADDomain
$aesHint = (Get-ADGroup -Identity "$($domain.DomainSID)-521" -Properties whenCreated).whenCreated

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' -Properties msDS-SupportedEncryptionTypes, pwdLastSet |
    Where-Object SamAccountName -ne 'krbtgt' |
    Select-Object SamAccountName,
        @{ n = 'EncTypes';      e = { $_.'msDS-SupportedEncryptionTypes' } },
        @{ n = 'PwdLastSet';    e = { [datetime]::FromFileTime($_.pwdLastSet) } },
        @{ n = 'BeforeAesHint'; e = { [datetime]::FromFileTime($_.pwdLastSet) -lt $aesHint } } |
    Sort-Object PwdLastSet

Treat that output as a triage list. The real answer is in the Available Keys field of the 4768 and 4769 events (Microsoft's List-AccountKeys.ps1 reads them) and in the 202 and 207 events. That field only exists on DCs running Windows Server 2019 or later, and on 2016 since the January 2025 cumulative update; a Windows Server 2012 R2 DC doesn't log it, so List-AccountKeys.ps1 finds nothing there.

RC4 service tickets and Kerberoasting

Any authenticated user can request a service ticket for any account with an SPN, and part of that ticket is encrypted with the service account's key. With RC4-HMAC that key is the NT hash, an unsalted MD4 of the password, so every cracking guess is cheap. AES keys are derived with PBKDF2 (4096 iterations by default) and salted with realm and principal name, which makes each guess far more expensive. AES slows roasting down but doesn't stop it: a weak password stays crackable, so the durable fix is a long random password or a gMSA. Windows clients don't advertise RC4 only by default, while roasting tools can be told to request RC4 specifically (Rubeus has options for exactly that), so a 201 from an ordinary workstation deserves a look from your SOC as well.

What to fix before April

Patch every DC and run the registry check above. An explicit DefaultDomainSupportedEncTypes that includes RC4 keeps that DC exposed after April, so remove it or keep it as a deliberate decision.
Collect 201 to 209 from all DCs for a few weeks, long enough to include month-end jobs and anything that runs quarterly.
For 202 and 207 accounts, set a new long random password and update everything that uses the account, or move the service to a gMSA.
For 201 and 206 clients, fix the client: enable AES in the krb5.conf or Java configuration, and re-export keytabs with ktpass /crypto AES256-SHA1 (or All). Keep in mind that ktpass sets the account's password while exporting, so anything else using that account needs the new one too.
Where a non-Windows service really can't do AES, set msDS-SupportedEncryptionTypes on that one service account to 0x24 (RC4 with AES session keys), give it a long random password and record it as an exception. Setting DefaultDomainSupportedEncTypes to 0x24 is the last resort and leaves every account in the domain exposed.
For the silent group, list RC4 service tickets to accounts without the attribute, and check every non-Windows service among them for AES keys in its keytab (klist -k -e on MIT systems) before April.
Then set RC4DefaultDisablementPhase to 2 on one DC, restart it, and watch for 203, 204, 208 and 209 before rolling it out to the rest.

Start with step 1 this week: the registry check and a first pull of the events take less than an hour and tell you how big the rest of the list will be.

Update March 2026: Microsoft has since confirmed the blind spot described above: the absence of audit events is no proof that non-Windows services will keep working, and Azure Files shares with on-premises AD DS authentication (FSLogix profile shares included) are explicitly in scope. Storage accounts still on RC4 need to be upgraded to AES-256 (Update-AzStorageAccountAuthForAES256 in AzFilesHybrid), by July for standard SPNs and already by April if you use custom SPNs or a custom DNS suffix; the steps are in Microsoft's Azure Files troubleshooting article. Shares on Entra Kerberos get their tickets from Entra ID, not from your DCs.

The scripts from this post are also on GitHub, in entra-scripts.

Kerberos RC4 hardening: reading the KDCSVC events and finding the accounts that break in April

What the January update changes and what it leaves alone

Reading events 201 to 209

Which accounts are actually at risk

Finding them up front with PowerShell

RC4 service tickets and Kerberoasting

What to fix before April

Sources

Samantha Kloos-Kilkens

Stay in the Loop

You might also like:

The Entra Connect Sync first-party app in Conditional Access and sign-in logs

Entra Kerberos for cloud-only identities: what the Azure Files preview requires and how it differs from hybrid