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
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.
The deployment began with January 2026 updates that introduced KDC auditing and the temporary
July’s security update completes that sequence. The KDC will stop reading
The affected temporary value is located under:
Before July, its documented settings were:
Microsoft will continue to honor an explicitly configured
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.
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, 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:
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.
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
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.
Microsoft documents
The broad fallback—setting
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.
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\ParametersBefore July, its documented settings were:
- A value of
0produced no audit events and made no behavioral change. - A value of
1logged warnings when the KDC encountered default RC4 usage. - A value of
2made the KDC assume that RC4 was not supported by default.
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 newKdcsvc 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-SupportedEncryptionTypesvalue. - 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.
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’smsDS-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
- 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-20833support.microsoft.com - 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 keyslearn.microsoft.com
