Kerberos RC4 April 2026 enforcement: mid-market triage runbook

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 by the end of Q2 2026 — now just weeks away. Mid-market environments still have time to inventory RC4 dependencies, set encryption attributes correctly, and coordinate vendor remediation for anything that can't move. After the Q2 cutoff, there is no rollback. Pairs with our AD Audit service.

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 rollback escape hatch

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).

The rollback is intentionally temporary. Microsoft has stated the RC4-permitting configuration will be removed from the KDC's honored configuration by the end of Q2 2026. After the Q2 cutoff, setting the value to permit RC4 has no effect; the DC refuses RC4 ticket issuance unconditionally.

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 the Q2 cutoff.

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 Q2 cliff list. 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 the Q2 cutoff. This is the right answer when the app vendor has a path to AES but hasn't shipped it yet.
6. Plan the Q2 2026 cliff. Anything still on 0x1C with no vendor AES path by mid-June is a service that will fail when Microsoft removes the RC4-permitting rollback configuration. Make the business decision now: retire the app, swap the vendor, accept the outage, or escalate to the vendor with the Q2 cutoff date in writing. The cliff is not a surprise; the only surprise is whether the decision gets made before or after it.

The Q2 2026 cliff

Microsoft's published timeline (see KB 5073381) removes the RC4-permitting rollback configuration from the KDC's honored behavior by the end of Q2 2026 — the late-June 2026 update cycle is the operative window. The implications, stated plainly:

• Setting DefaultDomainSupportedEncTypes to include RC4 after the cutoff has no effect. The KDC no longer honors the RC4-permitting code path; the configuration value persists but the behavior it used to enable is no longer reachable.
• Any account still configured for RC4-only encryption (msDS-SupportedEncryptionTypes = 0x4) will fail authentication on the first ticket request after the Q2 cutoff update applies. The error is KDC_ERR_ETYPE_NOTSUPP (klist status 0x80090342). The mitigation is to update the account's encryption types — which requires that the application can actually use AES.
• Any forest trust still carrying an RC4-only trust key will fail cross-forest authentication. The remediation is to rotate the trust key to an AES-capable type, which is an out-of-band operation requiring coordination with the trusted-forest administrator.
• Any computer account whose msDS-SupportedEncryptionTypes resolves to RC4-only will fail to receive new TGTs. Domain-joined endpoints with this configuration stop authenticating to AD.

The six weeks between mid-May and the Q2 cutoff are the remediation window. The work is not technically hard — setting an attribute, testing an application, coordinating with a vendor — but it is unforgiving on timeline. There is no eight-week extension available. The patch ships on the Patch Tuesday cadence and the rollback is gone the day it installs.

Common mistakes

Flipping the rollback globally and forgetting it

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 the Q2 cutoff 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 the Q2 cutoff 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 Q2 cliff list, 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 KB 5073381 — Managing Kerberos RC4 changes related to CVE-2026-20833
• 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. The April patch left a documented rollback (DefaultDomainSupportedEncTypes under HKLM\SYSTEM\CurrentControlSet\Services\Kdc, per KB 5073381) as a temporary escape hatch. Microsoft's published timeline removes that rollback by the end of Q2 2026. 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, plan the Q2 cliff) followed by 1–2 weeks of remediation execution. Fixed-fee $4K–$8K for the audit and plan. Six weeks remain before the rollback is gone.

If your environment is showing post-April-14 Kerberos symptoms or you want a senior engineer to scope the audit before the Q2 cliff, the project intake form takes about three minutes. Two-business-day response 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.