Kerberos RC4 enforcement triage: April 2026

Microsoft's April 14, 2026 cumulative update for Windows Server flipped domain controllers into AES-SHA1-only Kerberos mode by default. For environments that had already cleaned up legacy RC4 dependencies during the 2024–2025 warning phases, the patch installed quietly and nothing broke. For environments that hadn't — mostly mid-market shops with pre-2012 service accounts, line-of-business apps from vendors who haven't shipped an AES-capable build, and Linux/Samba integrations that nobody documented — the patch broke logins, looped DCs through reboot cycles, and produced a week of NETLOGON errors that read as "Kerberos is just broken" until someone correlated the event IDs to the RC4 retirement timeline.

This post is the triage runbook for the shops that got hit, and the warning for those that haven't yet. The April patch left a documented rollback configuration as an escape hatch. Microsoft's published timeline removes that rollback in or after July 2026. That subkey is the phase-gating knob, not the escape hatch — see the correction below. Environments still leaning on RC4 need to inventory those dependencies, set encryption attributes correctly, and coordinate vendor remediation for anything that can't move. The subkey removed in July 2026 is the phase knob, not the exception. Pairs with our AD Audit service.

Correction — August 2026: this post had the mechanism backwards

An earlier version of this post said the RC4 rollback disappears at the end of Q2 2026 (June 30). Two things were wrong with that, and the second is more important than the first.

The date was wrong. KB 5073381 (KB5073381) says "the Windows updates released in or after July 2026 will remove support for the registry subkey RC4DefaultDisablementPhase." July is Q3, and Microsoft names no specific day.

RC4DefaultDisablementPhase — what July actually removes

And the mechanism was wrong. RC4DefaultDisablementPhase is not the escape hatch. It is the phase-gating knob, and per the KB it takes three values:

• 0 — "No audit, no change"
• 1 — "Warning events will be logged on default RC4 usage. (Phase 1 default)"
• 2 — "Kerberos will start assuming RC4 is not enabled by default. (Phase 2 default)"

Setting it to 2 opts you into enforcement early. So the July removal is not a cliff — it is Microsoft deleting a switch that has no remaining purpose once enforcement is unconditional. Nothing you were relying on is taken away by it.

The configuration that keeps RC4 working is explicitly preserved

The actual way to keep an RC4-dependent service alive is explicit configuration — the msDS-SupportedEncryptionTypes bitmask on the service account, or DefaultDomainSupportedEncTypes domain-wide. On that, the KB is unambiguous: Microsoft will "log warning events for insecure configurations" and "will honor any configuration explicitly set by an administrator."

That is the opposite of a disappearing escape hatch. There is no date after which an explicitly configured RC4 exception stops being honoured, and this post should not have implied one.

What is actually true, and why the runbook below still matters

The real change landed on April 14, 2026 — Microsoft's own name for it is the Enforcement Phase — and it is a change of default: a DC in enforcement mode "will only assume support for Advanced Encryption Standard (AES) encryption type configurations if no explicit configuration is specified."

So the exposure was never a deadline. It is every service account that depends on RC4 without an explicit encryption-type configuration behind it — those broke in April, and they stay broken until someone inventories them and either sets AES or sets an explicit, logged, deliberate exception. The triage runbook below is still the work. What changes is the honest reason for doing it: not "a cliff is coming," but "you are relying on a default that already flipped, and every exception you keep is now a warning event in your DC logs."

One limit worth stating: Microsoft has not revised KB 5073381 since April 14, 2026, so its own article does not confirm the July removal shipped. Third-party coverage places it with the July 14, 2026 updates. We have not verified that at a Microsoft source and are not stating it as one.

What changed on April 14, 2026

The April 14 update is the second-to-last step of a multi-year Kerberos hardening campaign Microsoft began in November 2022 with KrbtgtFullPacSignature (CVE-2022-37967), expanded through 2024 with msDS-SupportedEncryptionTypes default changes, and is finishing in 2026 with full RC4 retirement. The Core Infrastructure and Security blog laid out the timeline in early 2025; the April 2026 update is the enforcement step.

The mode change

Before April 14, domain controllers offered Kerberos tickets in multiple encryption types and would issue an RC4-HMAC ticket when a requesting account's msDS-SupportedEncryptionTypes attribute included the RC4 bit (0x4) or was unset (which Windows historically treated as RC4-capable for backward compatibility). After April 14, the DC's default behavior is AES-SHA1-only: AES128-CTS-HMAC-SHA1-96 (etype 0x11) and AES256-CTS-HMAC-SHA1-96 (etype 0x12). RC4-HMAC (etype 0x17) and RC4-HMAC-EXP (etype 0x18) are no longer offered by default.

The explicit-configuration exception

Microsoft shipped the April patch with a deliberate registry-based escape hatch for environments that hadn't finished their remediation. The documented mechanism is the KDC's DefaultDomainSupportedEncTypes value (see Microsoft KB 5073381 for the canonical reference):

• Key: HKLM\SYSTEM\CurrentControlSet\Services\Kdc
• Value name: DefaultDomainSupportedEncTypes
• Type: REG_DWORD
• Effect: Controls the default supported encryption types the KDC applies when an account's msDS-SupportedEncryptionTypes attribute is unset. Set to a value that includes the RC4 bit (e.g., 0x1F = RC4 + AES128 + AES256 + the use-keys flags) to restore pre-April behavior for unset accounts. The April 2026 patch changes the default to 0x18 (AES128 + AES256, no RC4).

An earlier version of this post called this exception "intentionally temporary" and said it would stop working in or after July 2026. That was wrong. KB 5073381 says Microsoft will "log warning events for insecure configurations" and "will honor any configuration explicitly set by an administrator" — so this value keeps working, and keeps being honoured, with no published end date. What July removes is RC4DefaultDisablementPhase, a different value and a different purpose.

The related CVE

The April 2026 update also addresses CVE-2026-20833, a Kerberos elevation-of-privilege issue where RC4 ticket downgrade was reachable from non-domain-joined endpoints. The CVE remediation is bundled with the enforcement change — meaning environments rolling back via DefaultDomainSupportedEncTypes to restore application function are also rolling back the CVE protection. The rollback exists, but it is not free.

Who is exposed

Four profiles account for the bulk of the mid-market exposure. If any of these describe your environment, assume you have RC4 dependencies until the inventory proves otherwise.

A fifth profile: computer accounts of older Windows endpoints that were domain-joined years ago and never had msDS-SupportedEncryptionTypes refreshed. Quieter than service-account breakage, but the source of intermittent slow-logon scenarios and the "RDP-from-non-managed-jump-host fails silently" pattern below.

What broke

The failure modes from the April 14 patch fall into five buckets. The pattern is consistent enough across mid-market environments that if you're seeing any one of these post-April, assume RC4 enforcement is the cause until the event logs prove otherwise.

Server 2022 DC reboot loop

A small but real subset of Server 2022 DCs entered a reboot loop after the April update applied. The pattern: KDC service starts, attempts to load encryption-type configuration, fails to reconcile a stuck RC4-only krbtgt or trust key, panics, and the DC reboots. The mitigation is to boot to Directory Services Restore Mode, set DefaultDomainSupportedEncTypes to permit RC4 manually, reboot normally, and triage the underlying RC4 dependency. The loop itself is fixed once the rollback is in place. The remediation work happens after the DC is back online and stable.

KDC_ERR_ETYPE_NOTSUPP (0x80090342)

The signature error. Event ID 4 (Kerberos-Key-Distribution-Center) on the DC with description "the encryption type requested is not supported by the KDC." The Kerberos error code is KDC_ERR_ETYPE_NOTSUPP (the canonical name across all Microsoft references); klist surfaces it as status 0x80090342. This is the error a service account throws when it requests an RC4 ticket and the DC refuses to issue one. Search the System or Security event log on any DC for this error name and you have a list of every account that's tried and failed since the patch installed.

Service-account login failures

The most common visible failure: a service that ran fine on April 13 fails to start or fails to authenticate to AD on April 14 after the DC patches install. The service-account password is unchanged. The account isn't locked. The DC just won't issue it a ticket. Without correlation to the patch timeline, this reads as a service-account permissions issue or a "weird AD problem" and gets escalated as such.

Slow logon scenarios

Computers whose msDS-SupportedEncryptionTypes is unset or RC4-only experience extended logon delays as the client cycles through encryption-type negotiation, fails on RC4, and falls back to AES (if the computer account supports it) or fails entirely. A 30–90 second logon delay that didn't exist before April 14 is the symptom. The cause is usually a computer-account attribute mismatch, not a network or DC performance issue.

The apparent silent failures

The hardest pattern to diagnose: authentication that "doesn't work" with no obvious error message presented to the end user. Common cases:

• RDP from non-managed jump hosts — the jump host requests RC4, the DC refuses, RDP falls back to NTLM (where allowed) or fails (where not). User sees "credentials incorrect" with correct credentials.
• Certain SSO flows to on-prem apps — the app expects a Kerberos ticket with an RC4 service principal; AES ticket arrives; the app silently rejects it. User sees the app's generic "session expired" page.
• Print server authentication — older print drivers and print management tools that authenticate with RC4-only computer accounts. Print queues become unavailable to some users on some endpoints, not consistently.

The 3-hour triage runbook

Three hours of senior-engineer time, scriptable, run from a workstation with the AD PowerShell module and read access to all DC event logs. Produces the inventory you need to decide what to remediate before that removal.

1. Pull msDS-SupportedEncryptionTypes for every account in the forest. Query AD for users, computers, and gMSAs. The attribute is an integer bitmask: 0x4 = RC4-HMAC, 0x8 = AES128-CTS-HMAC-SHA1-96, 0x10 = AES256-CTS-HMAC-SHA1-96. The two values you want to see are 0x18 (AES128 + AES256, no RC4) or 0x1C (RC4 + AES128 + AES256, AES preferred with RC4 fallback). The values you do not want to see are 0x4 (RC4-only) or unset/null (which Windows historically interpreted as RC4-capable). Export to CSV.
2. Query DC event logs for RC4 ticket activity over the last 30 days. Pull Event ID 4768 (Kerberos AS-REQ / TGT issued) and 4769 (Kerberos TGS-REQ / service ticket issued) from every DC. Filter for tickets where the Ticket Encryption Type field is 0x17 (RC4-HMAC) or 0x18 (RC4-HMAC-EXP). The Account Name field on each matching event names the account that requested RC4. Aggregate by account, count by frequency.
3. Build the exposed-account list. The intersection of step 1 and step 2 — accounts whose msDS-SupportedEncryptionTypes is 0x4 or unset and which have actually requested RC4 tickets in the last 30 days — is your real exposure list. Accounts on step 1 but not step 2 are configured for RC4 but not currently using it; they're a configuration hygiene issue, not an outage risk. Accounts on step 2 but not step 1 mean the attribute is set correctly but something is still requesting RC4 — typically the application is hard-coded.
4. Set encryption types correctly for each exposed account. For service accounts where the vendor confirms AES support: set msDS-SupportedEncryptionTypes to 0x18 (AES128 + AES256, no RC4). For service accounts where the vendor has not shipped an AES-capable build but the account must continue to function past April: set to 0x1C (AES + RC4 fallback) and add the account to the exception register. For computer accounts, the default in current Windows is 0x1C; explicitly set it for any unset accounts to remove the ambiguity.
5. Decide rollback vs remediate, per account. Two paths. (a) Remediate now: set 0x18, test the app, accept the change. This is the right answer for ~80% of exposed accounts in most mid-market environments. (b) Rollback and schedule: set 0x1C on the account, configure DefaultDomainSupportedEncTypes on the KDCs to keep RC4 alive for unset accounts, and put the account on a schedule for vendor coordination before that removal. This is the right answer when the app vendor has a path to AES but hasn't shipped it yet.
6. Plan for the July 2026 removal. Anything still on 0x1C with no vendor AES path today is a service that will fail when Microsoft removes the RC4-permitting rollback configuration in July 2026. Make the business decision now: retire the app, swap the vendor, accept the outage, or escalate to the vendor in writing with a dated review on the exception. The exception is not the problem; the only surprise is whether the decision gets made before or after it.

What July 2026 actually changed — less than this post once claimed

One thing, and it is narrow. Per KB 5073381, "the Windows updates released in or after July 2026 will remove support for the registry subkey RC4DefaultDisablementPhase." That subkey is the phase-gating knob described above — the one whose value 2 means "Kerberos will start assuming RC4 is not enabled by default." It let administrators opt into the new behaviour ahead of the schedule. Once the schedule has run, it has nothing left to gate, so Microsoft removed it.

If you never set it, its removal changes nothing for you. And critically: it is not the mechanism that keeps RC4 working. The KB is explicit that Microsoft will "log warning events for insecure configurations" and "will honor any configuration explicitly set by an administrator." Explicit encryption-type configuration survives.

The failure modes are real — they just belong to April, not July

Everything below broke when the April 14, 2026 default changed, for any principal relying on the old default rather than on an explicit setting. If you are still finding these, you are not approaching a deadline; you are working through a backlog that started in April:

• Any account configured for RC4-only encryption (msDS-SupportedEncryptionTypes = 0x4) fails authentication on its next ticket request. The error is KDC_ERR_ETYPE_NOTSUPP (klist status 0x80090342). The fix is to set AES on the account — which requires the application to actually support AES.
• Any forest trust still carrying an RC4-only trust key fails cross-forest authentication. Remediation is rotating the trust key to an AES-capable type, out-of-band, with the trusted-forest administrator.
• Any computer account whose msDS-SupportedEncryptionTypes resolves to RC4-only stops receiving new TGTs, so the endpoint stops authenticating to AD.
• Anything depending on the default being permissive — with no explicit configuration anywhere — is now assumed AES-only by the KDC. This is the category that surprised people, because nothing was ever configured, so nothing looked misconfigured.

The real risk is the opposite of a deadline

This post originally sold urgency: a cliff was coming, and you had weeks. That was wrong, and the truth is less comfortable. There is no date on which an explicit RC4 exception stops being honoured. So every exception someone set in April to stop an outage is still working today, and will keep working — silently, indefinitely, generating warning events nobody reads.

That is worse than a deadline, operationally. A deadline forces the work. A permanently honoured exception lets an estate carry RC4 dependencies for years while every dashboard reports green, because authentication succeeds. The thing to inventory is not "what will break." It is "what did we exempt, who approved it, and when does it get removed" — and if the answer to the last part is "nobody decided," that is the finding.

Common mistakes

Setting a global exception and forgetting it — now the main risk

The fastest way to "fix" the April outage is to push DefaultDomainSupportedEncTypes back to an RC4-permitting value (e.g., 0x1F) across every DC via GPO or a quick PowerShell loop, confirm the service-account failures stop, and move on. That works — until that update installs, the rollback stops being honored, and the same service accounts fail again. The rollback is a stopgap. Treat it as a stopgap. Pair every rollback flip with a ticket on the schedule to remediate the underlying account before that update installs.

Treating the AES-supported flag as proof of working AES authentication

msDS-SupportedEncryptionTypes is an attribute on the AD object. It tells the KDC what encryption types the account is configured to accept. It does not tell you whether the application running under that account is capable of decrypting an AES ticket. The attribute can be correctly set to 0x18 while the application library hard-codes RC4 in its Kerberos negotiation. Test the application end-to-end after changing the attribute. The attribute is necessary; it is not sufficient.

Not testing app vendors before the change

Some mid-market apps — particularly ERP suites from the 2010s, manufacturing execution systems, and certain niche line-of-business tools — were built against Kerberos libraries that don't negotiate AES correctly even when the AD account permits it. Before flipping a service account to 0x18 in production, test it in a non-production instance or schedule a maintenance window. The remediation that's right on paper is wrong in production when the vendor hasn't validated their app for AES-SHA1-only environments.

Letting one stuck service account hold the forest at RC4

The temptation is to leave the KDC permitting RC4 forest-wide because one service account can't move to AES yet. That's a poor trade. The fix is to set msDS-SupportedEncryptionTypes to 0x1C on that single account, configure every other account for 0x18, and let the rollback serve its actual purpose: enabling the specific identified legacy accounts to continue functioning while the rest of the forest moves cleanly to AES. The April patch supports per-account RC4 permission. Use it. Don't punish the whole forest for one app.

What this costs

Pricing transparency, in the same frame as our other fixed-fee engagements:

• Kerberos RC4 audit and remediation plan (1 week scope) — fixed fee, $4K–$8K. Senior engineer only. Outputs: the exposed-account inventory from the triage runbook, the per-account remediation decision (0x18 now vs 0x1C with vendor coordination), the exception register, and the change-window plan. Read-only by default; remediation execution is a separately scheduled change.
• Remediation execution — scoped from audit findings. For environments with mostly well-documented service accounts and cooperative app vendors, this is typically another 1–2 weeks of work. For environments with significant legacy ERP/MES vendor coordination required, it can extend longer and may carry vendor-side costs outside our scope.
• Higher end of the range — 500+ seats, multi-forest trusts, significant Linux/Samba integration, or anticipated multi-party vendor coordination. Quoted on discovery output, not assumed up front.

Related reading

• The broader identity hygiene context: AD Tier-0 in 90 Days: Mid-Market Edition — Kerberos hygiene is a Tier-0-adjacent concern; the same audit phase often surfaces both.
• If your environment is GovCon-adjacent and the RC4 remediation is part of broader compliance work: GCC High before CMMC Phase 2.
• Service detail: Active Directory Audit.
• Service hub: Identity, Security & Compliance.

Sources and further reading

• Microsoft Learn — Kerberos RC4 encryption cipher key deprecation
• Microsoft Tech Community — Decoding the changes in RC4 with the 2026 Windows updates
• Microsoft Learn — Kerberos authentication overview
• Microsoft Learn — [MS-KILE] Kerberos Protocol Extensions
• Microsoft Learn — Kerberos authentication on Windows Server

The 30-second version

Microsoft's April 14, 2026 patch flipped domain controllers into AES-SHA1-only Kerberos mode by default and broke authentication for any account still configured for RC4-HMAC. Mid-market environments (50–1,500 seats) with pre-2012 service accounts, line-of-business apps from non-updated vendors, older forest trusts, or Linux/Samba integrations got hit hardest. An explicit exception is still available and still honoured indefinitely — msDS-SupportedEncryptionTypes on the account, or DefaultDomainSupportedEncTypes under HKLM\SYSTEM\CurrentControlSet\Services\Kdc, per KB 5073381. What the July 2026 updates remove is RC4DefaultDisablementPhase, the phase-gating knob that let you opt into enforcement early; that is not the exception, and its removal takes nothing away. The remediation is a 3-hour triage runbook (inventory msDS-SupportedEncryptionTypes, query 4768/4769 events for RC4 tickets, set the attribute to 0x18 or 0x1C per account, decide remediate-now vs vendor-coordination, build the exception register) followed by 1–2 weeks of remediation execution. Fixed-fee $4K–$8K for the audit and plan. There is no future deadline here — which is the risk: an exception set in April is honoured forever unless somebody decides to remove it.

If your environment is showing post-April-14 Kerberos symptoms or you want a senior engineer to scope the audit before it becomes permanent by default, the project intake form takes about three minutes. We'll come back with scope and a fixed-fee range.

Pro IT NW does senior-led identity work for mid-market and regulated organizations. Vendor-neutral. Labor-only. We don't resell Microsoft licensing, hardware tokens, or third-party identity tooling — we recommend the right configuration for your environment and you procure directly.