If your helpdesk queue exploded on April 15, 2026, you're not alone. Honestly, half the AD admins I've spoken with this month have the same story: Microsoft's Phase 2 rollout of Kerberos RC4 deprecation kicked in with the April 14, 2026 Windows security updates, and suddenly all those service accounts, legacy NAS appliances, Linux file servers, and bolted-on line-of-business apps that were quietly leaning on RC4 fallback just… stopped authenticating. Add the usual parade of KRB_AP_ERR_MODIFIED, clock skew, and duplicate-SPN tickets on top, and Kerberos is probably the single most expensive authentication protocol your Tier 1 team will touch this quarter.
So, this guide is written for the IT helpdesks who actually have to diagnose Kerberos failures in a post-April-2026 Active Directory environment. We'll cover CVE-2026-20833, the full RC4 rollout timeline, the exact PowerShell you need to find at-risk accounts, the klist and setspn workflows for ticket-level diagnosis, and fixes for the twelve error codes that account for roughly 95% of Kerberos tickets at an enterprise helpdesk.
The 2026 Kerberos Changes You Cannot Ignore
Two rolling enforcement projects are reshaping Kerberos behavior in Active Directory right now. Skip either, and your domain controllers will reject authentication attempts that worked fine last month.
CVE-2026-20833 — RC4 Service Ticket Hardening (Active Now)
CVE-2026-20833 is the driver behind Microsoft's current RC4 deprecation effort. It addresses an information disclosure vulnerability where an attacker can request a service ticket (TGS-REP) encrypted with RC4, capture it, and then perform offline Kerberoasting to recover the service account password. Because RC4 is computationally cheap to crack compared to AES, any service account with a non-trivial-but-not-rotation-hardened password is at meaningful risk.
The rollout has three phases:
- Phase 1 — January 13, 2026 (Audit). Nine new Kerberos audit events appeared on Windows Server 2012 and later domain controllers. Authentication behavior was unchanged, but admins finally got real telemetry on RC4 usage.
- Phase 2 — April 14, 2026 (Enforced by Default). Domain controllers stop negotiating RC4 implicitly. For any account where
msDS-SupportedEncryptionTypesis null or zero, the default flips to AES-SHA1 only (0x18). Individual DCs can still be rolled back to audit mode via registry, but the default is enforcement. - Phase 3 — July 2026 (Full Enforcement, No Rollback). The
RC4DefaultDisablementPhaseregistry value is removed. Only accounts with RC4 explicitly listed inmsDS-SupportedEncryptionTypescontinue to receive RC4 tickets. Everything else is AES-only, permanently.
CVE-2022-37967 — PAC Signature Enforcement (Already Enforced)
PAC (Privilege Attribute Certificate) signing has been fully enforced since the October 10, 2023 cumulative updates. There's no rolling back to audit mode anymore. If you're still seeing Event ID 42 warnings about missing PAC signatures on your DCs, you've got an unpatched or misconfigured endpoint somewhere in your estate — and it will fail to authenticate. The fix is almost always patching the affected client or server, not the DC.
Find At-Risk Accounts Before the Tickets Arrive
The single highest-leverage thing your team can do this week is audit which accounts still use or allow RC4. The goal is to identify them, figure out whether their downstream consumers can speak AES, and then either remediate or explicitly re-enable RC4 with a documented exception.
Audit Domain Controller Defaults
Get-ADObject -Identity "CN=Default Domain Policy,CN=System,DC=contoso,DC=com" `
-Properties msDS-SupportedEncryptionTypes |
Select-Object Name, msDS-SupportedEncryptionTypes
Interpret the result with the bitmask: 0x1 = DES_CBC_CRC, 0x2 = DES_CBC_MD5, 0x4 = RC4_HMAC_MD5, 0x8 = AES128_HMAC_SHA1, 0x10 = AES256_HMAC_SHA1. A null or zero value means "defaults apply" — and as of April 14, 2026, the default is AES-only.
Find User Accounts Still Configured for RC4
Get-ADUser -Filter 'msDS-SupportedEncryptionTypes -band 4' `
-Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
Where-Object { $_.ServicePrincipalName } |
Select-Object Name, SamAccountName, msDS-SupportedEncryptionTypes, ServicePrincipalName |
Export-Csv -Path C:\Audit\rc4-service-accounts.csv -NoTypeInformation
Filtering on accounts with a ServicePrincipalName narrows the list to kerberoastable targets — the ones an attacker would actually go after — and gives you a prioritized remediation queue.
Find Computer Objects With Legacy Encryption
Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes, OperatingSystem |
Group-Object msDS-SupportedEncryptionTypes |
Select-Object Count, Name |
Sort-Object Count -Descending
You'll almost always see a large bucket at $null (inheriting default), a bucket at 28 (RC4 + AES128 + AES256, Microsoft's pre-2016 default), and hopefully small buckets at 4 (RC4 only) and anything with DES bits set. The RC4-only bucket is your urgent list.
Use the Built-In DC Audit Events (New in January 2026)
On DCs patched with the January 2026 cumulative update or later, the System log surfaces nine new Kerberos events. The critical one for remediation is Event ID 31010, logged in the System log under source Kerberos-Key-Distribution-Center, which fires whenever a DC issues an RC4 service ticket. The event payload includes the target SPN, the client IP, and the reason RC4 was chosen.
Collect these centrally for a week and you'll have a near-complete inventory of RC4-dependent applications. (Honestly, this one event has saved me more discovery time than any audit script I've ever written.)
The klist Workflow Every Tier 1 Should Know
When a user says "I can't access the file share" or "SSO is broken," your first move should be klist in the user's session. It shows the tickets that currently exist in the LSA cache, the encryption type each ticket was issued with, and when they expire.
klist # List all tickets in current session
klist tgt # Show only the Ticket-Granting Ticket
klist get cifs/fs01.contoso.com # Force ticket request for a specific SPN
klist purge # Clear the user's ticket cache
klist -li 0x3e7 purge # Clear the SYSTEM account's cache (elevated)
In the output, look at the KerbTicket Encryption Type line. Post-April 2026 you should see AES-256-CTS-HMAC-SHA1-96 or AES-128-CTS-HMAC-SHA1-96. If you see RSADSI RC4-HMAC(NT), either the target account has RC4 explicitly set or something has gone wrong with the key exchange.
Post-password-reset gotcha: users who reset their password but still have a cached TGT from before the reset will hit KDC_ERR_PREAUTH_FAILED on renewal. klist purge followed by lock/unlock usually resolves it without a reboot. (I cannot count how many P2 tickets I've closed in 30 seconds with that one trick.)
The Twelve Error Codes That Cover 95% of Helpdesk Tickets
KDC_ERR_PREAUTH_FAILED (0x18, 24)
Translation: the KDC didn't accept the pre-authentication data the client sent. Causes, in order of frequency: wrong password (by far the most common), account lockout, expired password, stale cached TGT after a password reset, or — for smart-card logon — an expired client certificate.
Helpdesk triage: check lockout status with Get-ADUser -Identity $user -Properties LockedOut, badPwdCount, lastBadPasswordAttempt. If they're not locked, have the user klist purge and lock/unlock. For PKINIT, check certificate expiration in the user's Personal store.
KRB_AP_ERR_MODIFIED (0x29, 41)
Translation: the server can't decrypt the ticket the client presented. This does not mean the ticket was tampered with — it means the key used to encrypt the ticket doesn't match the key the service is trying to decrypt with. Four typical root causes:
- SPN on the wrong account. The SPN for the service resolves to account A, but the service is running as account B. Fix with
setspn -Qandsetspn -S. - Duplicate SPNs. Two accounts claim the same SPN. The KDC picks one, and if the service is running as the other, decryption fails. Find duplicates with
setspn -X. - Service account password change without service restart. The service is still using the old key to decrypt. Restart the service.
- Encryption type mismatch post-April 2026. If a service expects RC4 but the account no longer allows it, the DC issues an AES ticket the service can't decrypt. Either the service needs AES support, or the account needs an explicit RC4 re-enable with justification.
KRB_AP_ERR_SKEW (0x25, 37)
Translation: client and server clocks are more than 5 minutes apart. Fix with w32tm /resync /computer:<target> /rediscover. For persistent drift on VMs, check that the hypervisor time sync isn't fighting the domain time hierarchy — disabling VMware Tools time sync on domain-joined guests is the usual fix.
KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7, 7)
Translation: the SPN the client requested is not registered anywhere. Causes: the service was never registered, a typo in the client's connection string (using NetBIOS name when only an FQDN SPN exists, or vice versa), or the SPN was deleted during a migration. Verify with setspn -Q HTTP/webapp.contoso.com.
KDC_ERR_PRINCIPAL_NOT_UNIQUE (0x8, 8)
Translation: duplicate SPN. setspn -X lists every duplicate in the forest. Remove the stale one with setspn -D <SPN> <wrong-account>.
KDC_ERR_ETYPE_NOTSUPP (0x0E, 14)
Translation: no common encryption type between client, KDC, and target account. In 2026, this is almost always the RC4 deprecation story playing out: the account only allows RC4, the policy only permits AES, and the DC has nowhere to go.
Temporary fix: add AES to the account with Set-ADUser -KerberosEncryptionType "AES128,AES256". Permanent fix: update the downstream service to support AES, or explicitly grant an RC4 exception with documented risk acceptance.
KDC_ERR_CLIENT_REVOKED (0x12, 18)
Translation: the account is disabled, locked out, or has logon-hours restrictions that currently block authentication. Check Enabled, LockedOut, and logonHours on the account. For lockout, the AD account lockout troubleshooting playbook applies — find the source of bad attempts with Event ID 4740 on the PDC emulator.
KDC_ERR_KEY_EXPIRED (0x17, 23)
Translation: the user's password has expired. The user needs to change it (or be forced to at next logon). For service accounts with PasswordNeverExpires = $false that unexpectedly expired, build a reminder-before-expiry report — service account expiration is the single most common cause of "everything was fine last night" P1 incidents. I've seen this one bite ops teams more times than I'd like to admit.
KRB_AP_ERR_TKT_EXPIRED (0x20, 32)
Translation: the service ticket has expired. This is usually a symptom, not a disease — either the service failed to request a new ticket (bug in the client), the TGT's renewal window has passed (default 7 days), or the user's session has been idle through the ticket lifetime. klist purge forces a fresh round trip.
KDC_ERR_WRONG_REALM (0x44, 68)
Translation: the referral chain to another realm is broken. You see this in forest-trust or Kerberos-realm-trust scenarios. Verify trust health with nltest /sc_verify:<trusted-domain> and netdom trust <source> /domain:<target> /verify.
KDC_ERR_BADOPTION (0x0D, 13)
Translation: a requested ticket option isn't permitted. Almost always, this is constrained delegation misconfiguration — the service is trying to use S4U2Proxy or S4U2Self against an SPN it isn't authorized to delegate to. Verify the msDS-AllowedToDelegateTo attribute on the service account.
KDC_ERR_NEVER_VALID (0x0B, 11)
Translation: the ticket's start time is in the future relative to its end time, or the requested window is invalid. Nearly always a clock skew problem — frequently on the DC itself. Check DC time against an external authoritative source with w32tm /monitor and w32tm /query /status /verbose on the PDC emulator.
The setspn Commands That Actually Work
A surprising number of Kerberos problems trace back to SPN registration mistakes. A focused SPN audit resolves a large share of tickets without ever touching the client.
setspn -L CONTOSO\svc_sqlapp # List all SPNs for an account
setspn -Q HTTP/webapp.contoso.com # Query who claims a specific SPN
setspn -X # List every duplicate SPN in the forest
setspn -S HTTP/webapp.contoso.com CONTOSO\svc_webapp # Add an SPN (checks for duplicates)
setspn -D HTTP/oldserver.contoso.com CONTOSO\svc_retired # Delete an incorrect SPN
One rule, no exceptions: never use setspn -A. It skips the duplicate check and is the single most common way duplicates get introduced in the first place. Use -S instead, which fails cleanly if a duplicate would be created.
Post-April 2026 Helpdesk Playbook
When a Kerberos ticket lands on your queue in the current environment, work the following triage tree in order. It resolves about 90% of incoming tickets in under ten minutes.
- Ask when it broke. "Did this work before April 14?" immediately tells you whether to suspect the RC4 enforcement or something unrelated.
- Capture klist on the failing client. Note the encryption type, expiration, and whether the expected service ticket exists at all.
- Check the DC System log for Event ID 31010 or 31011 on one of the authenticating DCs, filtered by source client IP or target SPN. If either is present, you're looking at an RC4-related issue.
- Run
setspn -Qagainst the target SPN to confirm it's registered, points to the right account, and isn't duplicated. - Verify clock skew with
w32tm /stripchart /computer:<DC> /samples:3from the failing client. - Purge tickets and retry.
klist purgefollowed by a fresh access attempt. If this fixes it, the root cause was a stale ticket cache — document but don't escalate. - If it's still failing, escalate with the klist output, the Event ID 31010/31011 payload, and the setspn results. That package is enough for Tier 2 to diagnose without re-running discovery.
Service Account Remediation: AES or Documented Exception
For every service account that still uses or allows RC4, choose one of two paths and document the choice. There's no third option here — "leave it for next quarter" is how production outages are made.
Path A: Migrate to AES
# 1. Confirm the downstream service supports AES
# 2. Update the account
Set-ADUser -Identity svc_sqlapp -KerberosEncryptionType "AES128,AES256"
# 3. Reset the password so AES keys are generated
# (Without this step the account has the AES flag but no AES keys,
# and Kerberos will fail with KDC_ERR_ETYPE_NOTSUPP or KRB_AP_ERR_MODIFIED)
Set-ADAccountPassword -Identity svc_sqlapp -Reset `
-NewPassword (ConvertTo-SecureString -AsPlainText "NewComplexPassword" -Force)
# 4. Update the password in every service/scheduled task/IIS app pool using the account
# 5. Restart the dependent service
# 6. Validate with: klist purge; <trigger auth>; klist
Step 3 is the one teams miss most often. Flipping msDS-SupportedEncryptionTypes doesn't retroactively generate AES keys — they're only created when the password is next set. An account with AES flags but no AES keys will fail authentication even more reliably than one still set to RC4. (Ask me how I know.)
Path B: Documented RC4 Exception
If the downstream application genuinely cannot support AES (legacy appliance, vendor refuses to patch, custom SDK stuck on an old Kerberos implementation), explicitly allow RC4 on the account and log the risk acceptance. This works through Phase 3 (July 2026) for accounts with RC4 explicitly set.
Set-ADUser -Identity svc_legacy_nas -KerberosEncryptionType "RC4,AES128,AES256"
Pair this with rotation: an RC4-allowing account must have a long, high-entropy, frequently-rotated password, since Kerberoasting is the entire reason we're deprecating RC4 in the first place. 25+ character random passwords rotated quarterly are the minimum defensible standard. Anything less and you're handing attackers the key.
Don't Forget The krbtgt Account
The krbtgt account is the KDC's master signing account. Its password hashes the keys used to encrypt every TGT in the domain. If krbtgt was never reset after AES-capable DCs were introduced, it may only have RC4 keys — and when the April 14 enforcement flipped, parts of your domain may have silently stopped issuing AES TGTs at all.
The Microsoft-recommended remediation is a double reset of the krbtgt password with full AD replication between resets. Use the Microsoft New-KrbtgtKeys.ps1 script — never reset krbtgt manually, because doing both resets faster than replication can propagate will invalidate every ticket in the domain and trigger a forest-wide re-authentication storm. That is, in technical terms, a very bad afternoon.
Enable Kerberos Event Logging When You Need More
By default, successful (and even many failed) Kerberos exchanges are silent. When you're deep in a Tier 2 case and need the protocol to actually tell you what it's doing, enable extended logging.
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v LogLevel /t REG_DWORD /d 1 /f
After the reboot, Kerberos errors land in the System event log with detailed payload — the target SPN, the error code, the client IP. Just remember to turn it off again when you're done (LogLevel = 0); on busy servers it gets noisy fast.
Frequently Asked Questions
Did the April 2026 Windows update really break RC4?
Not exactly — it flipped the default. Before April 14, 2026, domain controllers would implicitly fall back to RC4 when the msDS-SupportedEncryptionTypes attribute was null or zero. After April 14, the implicit fallback is gone: null or zero now means AES-only. Accounts with RC4 explicitly listed continue to work through at least July 2026.
How do I tell if a specific Kerberos failure is RC4-related?
Look for three signals in combination: (1) the failure started at or after April 14, 2026; (2) the error code is KDC_ERR_ETYPE_NOTSUPP (0x0E) or KRB_AP_ERR_MODIFIED (0x29); and (3) the target account has either a null or RC4-only msDS-SupportedEncryptionTypes. DC Event ID 31010 confirms the DC attempted to issue an RC4 ticket.
Can I roll back the April 2026 update if RC4 deprecation broke my environment?
You can roll individual DCs back to audit mode using the KrbRC4DefaultDisablementPhase registry value, which keeps the new audit events but disables the AES-only default. You can't disable auditing, and the rollback is only available through the July 2026 Phase 3 update — at which point there's no escape. Use the window to remediate, not to avoid remediating.
Why does klist purge fix so many Kerberos problems?
Windows aggressively caches TGTs and service tickets in the LSA. After any change that invalidates a cached ticket — password reset, group membership change, SPN re-registration, encryption type change — the client will happily keep using the stale ticket until it naturally expires (up to 10 hours) or a new service is accessed. klist purge forces a fresh round trip to the KDC with the current account state, which resolves the large class of "group change hasn't taken effect yet" tickets.
What's the difference between the PAC signing change and the RC4 change?
They're unrelated defenses. PAC signing (CVE-2022-37967, fully enforced since October 2023) prevents attackers from forging the privilege information inside a Kerberos ticket. RC4 deprecation (CVE-2026-20833, rolling out April–July 2026) prevents attackers from cracking the ticket encryption offline. You need both. An RC4-enforced domain with un-patched PAC-signing clients is still vulnerable to elevation-of-privilege attacks through forged PACs.
