What the April 14, 2026 Windows Update Changed on Domain Controllers

The April 14, 2026 cumulative update changed Kerberos authentication behavior on patched Windows domain controllers.

Most early guidance described what broke. This post explains why, including a failure mode that produced no error code the application could act on and that continued in some environments even after rolling back to Phase 1.

If your team was diagnosing Kerberos failures, correlating event logs across domain controllers, and trying to work out why some applications stayed broken after the rollback, this is the technical explanation.

Microsoft described the change in three phases. Phase 1 (January 13, 2026) added audit events. Phase 2 (April 14, 2026) switched the default to AES. Phase 3 was scheduled for July 2026 and was to remove the rollback registry value.

What the April 14 Update Changed

The April 14, 2026 cumulative update implemented Phase 2 of CVE-2026-20833, as Microsoft announced on TechCommunity. The change was to the default behavior of the Key Distribution Center (KDC), the Kerberos service on each domain controller. That default is the set of encryption types the KDC assumes when no explicit override has been set. Before the April patch, the default permitted RC4 as a fallback. After it, the default was AES-only.

This is controlled by DefaultDomainSupportedEncTypes, which Microsoft Learn lists at HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC. In most environments this value was not explicitly set, and the KDC used its default based on the installed cumulative update. An explicitly set value can mask the true account-level encryption state and create a hidden domain-wide dependency. Microsoft Learn notes that changing it alters the behavior of all accounts that do not have their own value. Configuring the account through msDS-SupportedEncryptionTypes is more precise than a domain-wide override.

Before April 14, the KDC permitted RC4 as an implicit fallback for any account without explicit encryption type configuration. In Microsoft’s March 14, 2026 TechCommunity post: “RC4 will no longer be implicitly accepted by the KDC.” RC4 still exists as a cipher. The change was to the KDC’s default behavior when an account’s msDS-SupportedEncryptionTypes attribute is not explicitly set, which can describe many accounts in an enterprise environment.

Microsoft refers to this overall change as Kerberos RC4 hardening. Knowing what was hardened, and what was not, determined whether remediation targeted accounts, applications, or both.

Two Failure Modes, and Why One Was Hard to See

There were two different failure modes after April 14. They look similar on the surface but need different remediation, and treating them the same wastes effort while leaving environments partly broken.

Failure Mode A: Silent Ticket Substitution

This was the failure mode that was hardest to diagnose. It also continued after rolling back to Phase 1, which is why some environments stayed partly broken after the rollback.

Under RFC 4120, the Kerberos protocol specification, the KDC follows this rule: “the KDC SHOULD use the first valid strong etype for which an encryption key is available.” The KDC does not simply honor whatever the client requests. After April 14, when a client requested an RC4 Kerberos ticket for a service account that had AES key material in the KDC, the KDC did not reject the request. It issued an AES-encrypted ticket instead.

The client received an AES-protected ticket it did not expect, and the application rejected it. The application logged a generic authentication error with no Kerberos error code. Without an explicit failure signal, most applications have no mechanism to trigger a retry. Legacy systems, appliances, and embedded devices rarely do.

The domain controller logged KDCSVC Event 201, but it was easy to miss in a post-incident review. Microsoft classifies Event 201 as a Warning, not an Error. Engineers scanning event logs for authentication failures filtered for errors and never saw it. The DC logged ticket issuance as successful because from the KDC’s perspective it was. The failure happened on the client side, in a layer the DC cannot see. That is what made Mode A hard to spot at the infrastructure layer: the DC was healthy, the event log showed a warning that looked informational, and the application was broken for a reason the Kerberos error codes did not show.

Common sources of Mode A failures include legacy NAS devices and storage appliances with Kerberos authentication, older Java applications with default_tkt_enctypes = rc4-hmac set in krb5.ini, network printers using Kerberos, Linux and Unix systems with keytab files containing only RC4 key material, and RADIUS or 802.1X implementations with hardcoded RC4 negotiation.

Failure Mode B: Explicit KDC Rejection

Most documentation describes this failure mode, and it was the more straightforward one to diagnose.

When an account has no AES key material in the KDC credential store, meaning its password was never changed on a patched domain controller, the KDC cannot issue an AES ticket because the keys do not exist. In this case the KDC returns KDC_ERR_ETYPE_NOSUPP, a defined Kerberos protocol error code. A well-written Kerberos client can receive this error, update its encryption type list, and retry. Most legacy applications, appliances, and embedded systems do not implement this retry logic and fail permanently.

Microsoft’s documentation describes KDCSVC events 201 through 204 for RC4 warnings and enforcement blocks, including events that report a target service without AES keys. See Microsoft’s article for which event applies to which condition.

Mode B affected service accounts with passwords that were never changed on a domain controller running the November 2022 or later cumulative updates, regardless of how recently the account last authenticated. It also affected admin accounts configured with “password never expires” whose passwords predate patched DCs, and any account that looked active and healthy in AD but whose password was set before AES key generation was possible in the environment.

The Critical Distinction

The table below shows why getting this wrong wastes remediation effort. Mode A and Mode B look similar in a help desk ticket but require different fixes.

The last row of the table matters most. If a team rolled back to Phase 1 after April and applications were still broken, that was Mode A. The rollback resolved Mode B by allowing RC4 again for accounts with no AES keys. It did not touch Mode A, because Mode A affects accounts that already have AES keys, and the KDC behaved as designed. The fix belonged to the application, not the account.

What Rolling Back to Phase 1 Restored

Some organizations rolled back from April enforcement by setting RC4DefaultDisablementPhase = 1 at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. In KB5073381, value 1 means warning events are logged on default RC4 usage. The KDC permits RC4 but generates KDCSVC warning events. This was the supported rollback mechanism, but it did not return the environment to its pre-April state.

The rollback restored RC4 ticket issuance for accounts with no AES key material, so Mode B accounts were no longer rejected and could authenticate again. KDCSVC warning events continued to accumulate, which is useful audit evidence.

It did not restore implicit RC4 acceptance for accounts that already had AES keys. Those accounts still received AES tickets under the KDC’s default. Mode A failures, where applications receive AES tickets they cannot decrypt, continued regardless of the Phase 1 rollback state. The pre-April default behavior did not come back.

Our reading of the sources is that Phase 1 lets the KDC issue RC4 tickets to accounts that have no AES keys. It does not change which encryption type the KDC chooses for an account that has both, and RFC 4120 points the KDC to a strong type when it holds a key for one. We have not found a Microsoft statement that spells this out, so treat it as our reading.

What the July 2026 Phase Was Scheduled to Change

Microsoft’s documentation described a third phase for July 2026: “The Windows updates released in or after July 2026 will remove support for the registry subkey RC4DefaultDisablementPhase.” Microsoft scheduled that phase for the July 14, 2026 updates. This post reports the schedule as Microsoft published it and does not cover what shipped afterward. Check Microsoft’s current documentation for the final state.

Microsoft’s AskDS engineering blog described the July phase this way: “On installing the July 2026 Windows Cumulative Updates, the behavior will be identical to April 2026, however you will no longer roll back to audit mode.” The scheduled change was the removal of the RC4DefaultDisablementPhase rollback, so that setting it to 1 would no longer return domain controllers to Phase 1. Microsoft’s March 14, 2026 post said that after July, RC4 functions only if explicitly configured per account through msDS-SupportedEncryptionTypes.

Explicitly configuring RC4 per account stayed technically possible. For non-Windows devices that cannot support AES-SHA1, Microsoft’s guidance was to configure the affected service account’s msDS-SupportedEncryptionTypes to include RC4 and, as a last resort, to set DefaultDomainSupportedEncTypes to include RC4 with AES-SHA1 session keys. Microsoft noted that this configuration is insecure and recommended migrating to systems that support AES-SHA1 Kerberos ticket encryption. Where RC4 is still configured, document the dependency and the reason, because an assessor may ask about it.

How AES Keys Get Generated

This confused many teams.

Microsoft AskDS says: “During a password change, new keys are generated automatically with all the available Kerberos Encryption Types.” This confirms password change as the AES key generation trigger. Microsoft does not explicitly state that interactive logon generates AES keys. The AskDS documentation describes password change as the mechanism, with no equivalent statement for logon events.

An account that authenticates daily, shows a recent last-logon date, and appears healthy in Active Directory can have no AES key material at all if its password was never changed on a patched domain controller. That is why service accounts could fail in April. They authenticated every day via RC4, the environment looked fine, and the April update exposed a gap that had built up over years.

What This Meant for IT Leadership

If you were responsible for IT infrastructure, security, or compliance in an organization with Active Directory, the April 14 update gave you four jobs.

The first was separating Mode A from Mode B failures by correlating KDCSVC event data across every DC against application failure events. The second was confirming AES key presence from KDC event evidence rather than inferring it from AD attributes, which show configuration intent but not what the KDC will do. The third was mapping service account dependencies before rotating any passwords, because rotating a service account without knowing what depends on it breaks the application. The fourth was recording per-account findings and methodology, because compliance reviewers and insurers may ask for that record.

Sources

• Microsoft: Managing Kerberos KDC usage of RC4 (CVE-2026-20833, KB5073381)
• Microsoft TechCommunity: Phase 2 of Kerberos RC4 hardening begins with the April 2026 Windows security update
• Microsoft TechCommunity: Kerberos and the End of RC4 (March 14, 2026)
• Microsoft AskDS: What is going on with RC4 in Kerberos
• Microsoft Learn: Detect and Remediate RC4 Usage in Kerberos
• RFC 4120: The Kerberos Network Authentication Service (V5)