CVE-2026-20833: July Updates End Kerberos RC4 Rollback

Windows security updates released on July 14, 2026, move Active Directory domain controllers into the final enforcement phase of Microsoft’s Kerberos RC4 hardening for CVE-2026-20833. Once the July update is installed, domain controllers no longer honor the temporary RC4DefaultDisablementPhase rollback control, closing the audit-mode escape hatch that administrators could use during the staged deployment.
Microsoft detailed the change in support article KB5073381, originally published on January 13 and updated for July’s enforcement milestone. The immediate risk is operational: service accounts, appliances, keytabs, and legacy applications that depend on the KDC assuming RC4 support may begin experiencing Kerberos authentication failures after patched domain controllers restart.
This does not remove every administrator-configured use of RC4. Explicit encryption settings remain effective, but Microsoft warns that retaining them preserves exposure to the weakness the update is intended to address.

July Removes the Rollback, Not Every RC4 Configuration​

The deployment began with January 2026 updates that introduced KDC auditing and the temporary RC4DefaultDisablementPhase registry value. April 14 updates then changed the default DefaultDomainSupportedEncTypes behavior to AES-SHA1 only, represented by the bitmask 0x18, while still allowing administrators to return affected domain controllers to audit mode.
July’s security update completes that sequence. The KDC will stop reading RC4DefaultDisablementPhase, meaning administrators can no longer set the value back to 1 to restore the earlier warning-only behavior.
The affected temporary value is located under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
Before July, its documented settings were:

• A value of 0 produced no audit events and made no behavioral change.
• A value of 1 logged warnings when the KDC encountered default RC4 usage.
• A value of 2 made the KDC assume that RC4 was not supported by default.

The final phase effectively makes that last behavior permanent for configurations that do not explicitly declare their supported Kerberos encryption types. Removing the registry key or attempting to change its value after installing July’s update will not restore the previous assumption.
Microsoft will continue to honor an explicitly configured DefaultDomainSupportedEncTypes value. It will also continue to honor msDS-SupportedEncryptionTypes settings placed on individual service accounts, including settings that permit RC4.
That distinction matters. The July update removes implicit RC4 fallback and the temporary rollback mechanism; it does not prevent an administrator from deliberately configuring RC4 where compatibility requires it.

The Security Fix Targets Kerberoasting-Friendly Tickets​

CVE-2026-20833 is an information disclosure vulnerability in the Kerberos authentication protocol. According to Microsoft’s advisory, an attacker may be able to obtain service tickets using weak or legacy encryption such as RC4 and then conduct an offline attack against those tickets to recover a service account password.
This is closely associated with the attack technique commonly called Kerberoasting. An attacker who can request a ticket for a service principal can take that ticket away from the domain controller and repeatedly test password guesses without generating an authentication request for every attempt.
RC4-encrypted Kerberos tickets are particularly undesirable because the ticket key is derived directly from the account password and is comparatively efficient to attack with modern password-cracking hardware. AES does not make weak service-account passwords acceptable, but moving ticket issuance away from RC4 raises the cost of offline attacks and removes a long-standing compatibility default.
The practical change is therefore about what the Key Distribution Center assumes when Active Directory contains no explicit encryption configuration. Under final enforcement, an unspecified account is no longer treated as though RC4 is available by default.
Organizations that have already updated service accounts, regenerated keys and keytabs with AES support, and validated clients should see little visible change. Environments that treated the absence of an encryption setting as an informal RC4 compatibility policy are where failures are most likely.

---

Event IDs 201 Through 209 Show Where Authentication Breaks​

Domain controllers running Windows Server 2012 or later received nine new Kdcsvc events during the January deployment phase. Administrators should review the System event log on every domain controller rather than relying on a sample from a single site, since events can be generated only where the relevant ticket request is processed.
Event IDs 201, 202, 206, and 207 were warning signals during audit mode. Their enforcement counterparts indicate that the KDC has denied the requested cipher or could not issue a compatible ticket:

• Event ID 203 means the client advertised only insecure encryption types while the target service lacked an explicit msDS-SupportedEncryptionTypes value.
• Event ID 204 means the service account had only insecure keys and no explicit encryption setting.
• Event ID 208 means a client offered only RC4 even though the service or domain-controller policy was configured for AES-SHA1.
• Event ID 209 means the account was configured for AES-SHA1 but did not actually possess suitable AES keys.

Event ID 205 is different. It warns that DefaultDomainSupportedEncTypes has been explicitly configured to permit something other than AES-SHA1. Microsoft says this event remains a warning rather than becoming an error because Windows will not override the administrator’s explicit policy.
That makes Event ID 205 easy to misread. It does not necessarily identify a failed authentication request, but it does identify a domain-wide configuration that continues to allow insecure behavior. Microsoft logs it when the KDC service starts so administrators know that the explicit policy has bypassed the safer default.
The absence of these events is not proof that every application is ready. Microsoft cautions that some non-Windows systems may accept ticket issuance from the KDC but fail later when presented with an AES-encrypted service ticket, leaving the application or appliance log as the only obvious evidence.

Keytabs and Old Service Accounts Are the Likely Fault Lines​

Kerberos keytabs are a prominent compatibility risk. A Linux service, network appliance, Java application, or storage system may have a keytab containing only an RC4 key even though its corresponding Active Directory account is capable of generating AES keys.
After the new default takes effect, the KDC may issue an AES ticket that the service cannot decrypt. From the user’s perspective, this can resemble a bad password, an unreachable service, repeated authentication prompts, or an application-specific authorization failure rather than a Windows Update problem.
Administrators should verify both sides of the transaction. It is not enough for a client to advertise AES or for msDS-SupportedEncryptionTypes to contain the right bits; the service account must possess AES keys, and the application must have access to matching keys.
Password history can also matter. Service accounts created before AES support was available, or accounts whose passwords have not been changed for many years, may lack usable AES keys. Resetting or rotating the account password can generate the required keys, but that operation must be coordinated with every service using the credentials.
Azure Files customers using identity-based SMB access should also confirm that their storage accounts and AzFilesHybrid configuration support AES-256 Kerberos encryption. Microsoft’s Azure documentation identifies the July Windows Server change as a compatibility deadline for configurations that still depend on the older RC4 default.

Compatibility Overrides Now Carry an Explicit Security Cost​

Microsoft’s preferred remediation is to update or replace the affected client, appliance, or application and move its service account and keytab to AES. Where that is temporarily impossible, administrators can explicitly configure the individual service account’s msDS-SupportedEncryptionTypes attribute to include RC4 rather than weakening every account in the domain.
Microsoft documents 0x24 as a compatibility setting that allows RC4 ticket encryption with AES session keys. This is still an insecure exception, but its scope is narrower than changing DefaultDomainSupportedEncTypes across all relevant KDCs.
The broad fallback—setting DefaultDomainSupportedEncTypes to include RC4—leaves all accounts relying on that default exposed to CVE-2026-20833. Event ID 205 will continue flagging that decision after enforcement begins.
Administrators applying July’s updates should therefore treat authentication failures as migration work, not as a reason to restore RC4 domain-wide. Inventory the event IDs, map each request to its service account and client address, regenerate AES-capable keys, and test non-Windows services before the updated domain controllers enter production.
The July 14 update turns Microsoft’s six-month warning period into a durable KDC default. Any RC4 dependency that survives now must be explicitly configured, visibly logged, and consciously accepted rather than inherited from Kerberos compatibility behavior.

---

References​

1. Primary source: Microsoft - Message Center
   Published: 2026-07-14 10:00 PT
   
   

   How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 | Microsoft Support

   How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833

   support.microsoft.com
2. Official source: learn.microsoft.com
   
   

   Preventing Kerberos change password that use RC4 secret keys | Microsoft Learn

   Learn more about: Preventing Kerberos change password that uses RC4 secret keys

   learn.microsoft.com

 

[ChatGPT]

Windows domain administrators installing July 2026 updates must treat the change as an inventory deadline, not another Kerberos registry adjustment. Microsoft KB5073381 says those updates stop honoring RC4DefaultDisablementPhase, removing the temporary rollback path that allowed domain controllers to return to audit behavior.
The immediate task is to build a ticket-backed service-account inventory from KDCSVC events 201 through 209, Security events 4768 and 4769, Active Directory attributes, service principal names, and application-owner validation. Do not approve the July deployment solely because an LDAP search finds few accounts explicitly configured for RC4: the accounts most likely to be missed are those silently inheriting defaults because msDS-SupportedEncryptionTypes is not set.
A defensible workflow is:

1. Confirm that every relevant Windows Server 2012 or later domain controller has an update released on or after January 13, 2026.
2. Collect KDCSVC events 201 through 209 from each domain controller’s Event Viewer > Windows Logs > System log.
3. Collect Security events 4768 and 4769 from supported domain controllers for the same observation period.
4. Correlate each ticket request with its service account, SPN, msDS-SupportedEncryptionTypes value, client address, application, and owner.
5. Test non-Windows clients, appliances, and keytab-based services even when the audit logs remain quiet.
6. Record whether each dependency will be migrated, explicitly excepted, replaced, or retired before July updates are approved.

That register—not the registry rollback—is now the control that determines whether enforcement becomes routine maintenance or an authentication incident.

Start With Tickets, Then Enrich the Directory Record​

Microsoft’s KB5073381, originally published January 13, 2026, documents a staged Kerberos hardening process associated with CVE-2026-20833. After January 13 updates, Windows Server 2012 and later domain controllers can log KDCSVC audit events 201 through 209 in the System log, and Microsoft tells administrators to monitor and remediate those events before enabling enforcement.
Those events should become the first feed into the inventory because they represent activity observed by the Key Distribution Center. A directory-only scan can identify accounts, SPNs, and encryption attributes, but it cannot by itself prove which services are requesting tickets, which clients are reaching them, or whether an obscure integration still runs during a monthly or quarterly process.
Security events 4768 and 4769 provide the second feed. On supported domain controllers, they expose ticket-encryption and msDS-SupportedEncryptionTypes context, allowing administrators to connect an authentication transaction to the identity involved instead of producing a static spreadsheet of every account that happens to have an SPN.
For each affected transaction, the working record should contain at least:

• The service account and its distinguished identity in Active Directory.
• Every SPN assigned to that identity.
• The current msDS-SupportedEncryptionTypes state, including whether the attribute is absent.
• The ticket-encryption evidence captured by events 4768 or 4769.
• The KDCSVC event ID, domain controller, time, and originating client.
• The application, server, appliance, scheduled task, or integration using the identity.
• A named technical owner and a business owner.
• The planned remediation, test result, exception decision, and expiration date.

This structure prevents a common failure mode: closing a Kerberos finding after changing an account attribute without proving that the application behind the SPN can actually consume the resulting ticket.

Unset Encryption Attributes Are the Real July Exposure​

The April 14, 2026 enforcement phase changed DefaultDomainSupportedEncTypes to AES-SHA1 only, represented by 0x18, for accounts that do not have an explicit msDS-SupportedEncryptionTypes attribute. That means an empty attribute is not neutral metadata. It delegates the decision to the domain-controller default, and that default has already changed under the April enforcement phase.
This is why “find every account configured for RC4” is the wrong inventory question. Administrators also need to find service identities with SPNs whose encryption attribute is absent, then determine what their active clients and applications actually support.
An account may look clean in Active Directory precisely because it has no explicit legacy setting. Its dependency may instead reside in an old application configuration, a non-Windows Kerberos implementation, a stored keytab, or a service whose password and keys have not been handled under a documented migration process.
WindowsForum has tracked the broader move from RC4 defaults to AES-SHA1 throughout Microsoft’s staged rollout. The sharper operational consequence in July is that inherited behavior can no longer be managed safely as an undocumented assumption. Every service identity needs either evidence of AES interoperability or a recorded exception with an owner.

---

Turn Events 201 Through 209 Into Work Items​

KDCSVC events should not remain isolated warnings in individual domain-controller logs. Each occurrence needs to enter the same triage queue used for application changes and security exceptions.
Events 201 through 209 contain the evidence Microsoft expects administrators to use before enforcement. The triage process should preserve the complete event, identify the account and service fields it reports, connect those fields to SPNs in Active Directory, and then use the client information to locate the requesting workload.
The event number alone is not the final diagnosis. The useful distinction is whether the evidence points to a client-side capability problem, a service identity lacking suitable encryption configuration or keys, an explicit domain-level policy choice, or a request that enforcement is already denying.
That distinction determines ownership:

• Client-side dependencies belong with the endpoint, appliance, operating-system, or application team responsible for the requesting host.
• Service-account findings belong with the team operating the application represented by the SPN.
• Domain-wide encryption configuration belongs with the Active Directory platform owner and security authority.
• Enforcement denials require incident-style handling because they represent observed authentication impact rather than future exposure.

Events 4768 and 4769 then provide corroboration. Use them to establish whether the affected identity is receiving tickets, what encryption context is visible, and whether the problem repeats across clients or domain controllers. Repeated requests should still map to one managed dependency, not hundreds of disconnected event records.
The result should be a one-row-per-dependency inventory with attached event evidence. Counting events is useful for prioritization, but counting affected services is what makes remediation governable.

Remediation Must Match the Identity and Workload​

Managed service accounts, conventional service accounts, keytab-backed services, and appliances should not be placed into a single “legacy Kerberos” bucket. They may share an SPN and ticket path, but their owners, credential lifecycles, and testing requirements differ.
For a gMSA or another Windows-managed service identity, verify the account’s encryption state, identify every service using it, and test ticket acquisition and application authentication under the enforced default. Do not close the record merely because the identity is modern; the application consuming its tickets remains part of the dependency.
For a conventional service account, document its SPNs and all hosts using the credential before any password or key-related remediation. A password reset performed without application-owner coordination can replace one Kerberos risk with an immediate service outage.
Keytab-based services require deliberate end-to-end testing. Microsoft explicitly warns that the absence of audit events does not prove non-Windows interoperability, so a quiet System log cannot certify a Linux service, Java application, network appliance, or other third-party Kerberos client.
For appliances and vendor-controlled products, the inventory should record the model or product, current software release, vendor position, test result, and replacement or upgrade decision. If AES support cannot be demonstrated, the exception must name the precise account and workload rather than preserving RC4 broadly for the domain.
Exceptions are migration records, not permanent compatibility settings. Each one should state why RC4 remains necessary, which identity requires it, who accepted the risk, and when the dependency will be retested or removed.

AD DS and Entra Domain Services Have Different Control Planes​

Traditional Active Directory Domain Services and Microsoft Entra Domain Services must not be handled as though they expose the same rollback mechanism. In administrator-managed AD DS, KB5073381 describes the temporary RC4DefaultDisablementPhase registry control on domain controllers. Updates released in or after July 2026 remove support for that subkey.
Microsoft Entra Domain Services is a managed domain with settings exposed through its managed-service controls rather than direct administration of Microsoft-operated domain controllers. Microsoft’s Entra documentation describes its own dependency testing and recovery process, but those portal settings should not be copied into an AD DS runbook or mistaken for an on-premises registry equivalent.
Organizations running both need two change records, two evidence paths, and two rollback analyses. The shared objective is AES-capable Kerberos, but the operational authority and available controls differ.

---

July Removes the Excuse to Postpone Ownership​

The decisive date is not when an organization first sees an RC4 warning. April 14, 2026 already changed the default to 0x18 for accounts without an explicit encryption attribute. The July 2026 updates remove support for RC4DefaultDisablementPhase, ending the temporary mechanism for returning domain controllers to audit behavior.
Before approving those updates, change advisory boards should require an inventory with no unassigned service identities, no unexplained SPNs tied to active ticket traffic, and no non-Windows dependency considered safe solely because KDCSVC remained silent.
Some exceptions may remain. What cannot remain is ambiguity about which application owns them, which account exposes them, and what evidence supports the decision. Once rollback disappears, service-account ownership becomes the practical Kerberos control—and the quality of that inventory will determine whether the next authentication failure can be traced in minutes or only after a prolonged outage.

---

References​

1. Primary source: learn.microsoft.com
   
   

   RC4 deprecation advance dependency test in Microsoft Entra Domain Services - Microsoft Entra ID | Microsoft Learn

   Learn what the RC4 deprecation advance dependency test is, when it runs, and how to prepare for and recover from it in Microsoft Entra Domain Services.

   learn.microsoft.com
2. Independent coverage: support.microsoft.com
   
   

   How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 | Microsoft Support

   How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833

   support.microsoft.com
3. Primary source: WindowsForum
   
   

   CVE-2026-20833: July Updates End Kerberos RC4 Rollback | Windows Forum

   Windows security updates released on July 14, 2026, move Active Directory domain controllers into the final enforcement phase of Microsoft’s Kerberos RC4...

   windowsforum.com