Active Directory Hardening: Navigating Kerberos RC4 Deprecation and the July 2026 Registry Override Removal

Status update (October 14, 2026): The final phase has reached its scheduled date. Microsoft scheduled removal of RC4DefaultDisablementPhase for Windows updates released in or after July 2026, and those updates shipped on July 14 (for example KB5099536 for Windows Server 2025). The AES default itself arrived on April 14; July only removed the rollback. Microsoft has not revised Microsoft's KB5073381 since April 14 and the July release notes do not mention Kerberos or RC4, so confirm on a patched domain controller that setting the value to 0 or 1 no longer restores RC4 defaults. What still works: July does not disable RC4 completely, only the ability to default to it. An explicitly set DefaultDomainSupportedEncTypes is not overridden (Event 205 keeps flagging it), and per-account msDS-SupportedEncryptionTypes values that include RC4 (such as 0x1C) still work. Hybrid readers: Microsoft Learn states that Microsoft Entra Domain Services permanently disabled RC4 in all regions starting the week of July 13, 2026. Dates and phases below match the KB.

Enterprise identity teams still migrating are working against a hardening change that has already taken effect. Microsoft's phased elimination of legacy RC4-HMAC in Kerberos began with audit events on January 13, 2026, defaulted Kerberos Key Distribution Centers (KDCs) to AES-SHA1 (0x18) on April 14, 2026, and was scheduled to lose its registry rollback with the July 2026 updates. Unmigrated service accounts face authentication failures.

1. Timeline and Deadline Context: Escape Hatch Removal

Microsoft's deprecation strategy for legacy Kerberos ciphers spans a three-phase rollout. Understanding the distinction between phases is vital: the operational break occurs when KDC defaults change, whereas the July milestone removes administrative rollback capability. Security teams face a similar hard cutover on the crypto side; see the FIPS 140-2 sunset migration guide to FIPS 140-3.

During Phase 1 (January 13, 2026), security updates introduced dedicated KDC audit logging without altering ticket issuance. Phase 2 (April 14, 2026) set the domain controller default supported encryption types (DefaultDomainSupportedEncTypes) to AES-SHA1 only (0x18) for accounts lacking explicit configuration in the msDS-SupportedEncryptionTypes attribute. This represented the primary operational breaking point for workloads expecting implicit RC4 fallback.

The temporary registry escape hatch located under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters allows administrators to set RC4DefaultDisablementPhase (REG_DWORD) to 0 or 1 to temporarily bypass enforcement during Phase 2. Microsoft scheduled removal of support for this key in the July 2026 updates; it has not confirmed the change since, so test on a patched domain controller. While explicitly set per-account overrides (configuring msDS-SupportedEncryptionTypes to include 0x4) remain technically readable at the protocol level, retaining explicit RC4 flags exposes identity environments to ongoing cryptographic risk.

2. Technical Threat Analysis: CVE-2026-20833

The security driver behind this removal is tracked as CVE-2026-20833, rated CVSS 5.5 Medium (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) under CWE-327 (Use of a Broken or Risky Cryptographic Algorithm). The flaw allows authenticated low-privileged users to request service tickets encrypted with legacy RC4-HMAC (etype 23 / 0x17) and execute offline password-cracking attacks (Kerberoasting).

Because RC4-HMAC derives keys directly from NTLM password hashes without modern key-derivation functions, attackers crack RC4 service tickets exponentially faster than AES-128 or AES-256 equivalents. NTLM carries a related coercion risk; see defending against NTLM coercion, CVE-2024-38200. CVE-2026-20833 resolves residual exposure stemming from historical domain configurations where msDS-SupportedEncryptionTypes remained unset (null or 0x0).

3. Log Auditing Playbook: Identifying Legacy Encryption Usage

Identifying affected accounts requires monitoring KDC operational events in the System log alongside Kerberos ticket requests in the Security log.

KDC Operational Audit Events (System Log)

Active Directory DCs log dedicated KDCSVC audit events (IDs 201–209) to surface RC4 dependencies:

Note: The absence of audit events does not guarantee non-Windows devices will authenticate post-enforcement; direct interop testing remains mandatory.

Security Log Ticket Auditing (Events 4768 and 4769)

Verify audit policy on domain controllers:

auditpol /get /subcategory:"Kerberos Service Ticket Operations"

Monitor Event 4768 (TGT Requests) and Event 4769 (Service Tickets) for TicketEncryptionType 0x17 (RC4-HMAC). Filter events using XPath:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
 *[System[(EventID=4768 or EventID=4769)]] and *[EventData[Data[@Name='TicketEncryptionType']='0x17']]
    </Select>
  </Query>
</QueryList>

4. Migration Walkthrough: Transitioning Accounts to AES

Upgrading Active Directory accounts requires updating attribute flags and generating AES key material.

Step 1: Discover At-Risk Service Accounts

Query Active Directory for SPN-bearing accounts lacking explicit AES configurations:

Get-ADUser -Filter 'servicePrincipalName -like "*"' -Properties msDS-SupportedEncryptionTypes, servicePrincipalName, PasswordLastSet |
 Where-Object { $_. "msDS-SupportedEncryptionTypes" -eq $null -or $_. "msDS-SupportedEncryptionTypes" -eq 0 -or ($_. "msDS-SupportedEncryptionTypes" -band 0x4) } |
 Select-Object sAMAccountName, PasswordLastSet, msDS-SupportedEncryptionTypes, servicePrincipalName

Step 2: Configure Supported Encryption Types

Set msDS-SupportedEncryptionTypes to support AES128 (0x8) and AES256 (0x10), combining to 0x18 (24 decimal):

Set-ADUser -Identity "svc-sql-prod" -KerberosEncryptionType AES128, AES256

Bitmask Reference:

• 0x4: RC4_HMAC_MD5 only (Vulnerable)
• 0x8: AES128_CTS_HMAC_SHA1_96
• 0x10: AES256_CTS_HMAC_SHA1_96
• 0x18: AES128 + AES256 (Production Target)
• 0x38: AES128 + AES256 + AES Session Keys

Step 3: Rekey Service Accounts (Mandatory Step)

Setting attribute 0x18 only modifies account metadata; it does not generate AES password hashes. Active Directory stores cryptographic keys generated at the time of password creation. If an account's password predates AES enablement, AD contains only legacy RC4 hashes. When the KDC demands AES for an account lacking AES keys, authentication fails immediately.

• Execute a controlled password reset on the service account to compute aes128-cts and aes256-cts keys.
• For accounts created prior to Windows Server 2008 functional levels, perform a double password reset to clear legacy key history.
• Rotate domain KRBTGT keys twice, allowing for replication latency.

Step 4: Configure Domain Baselines and GPO

Set KDC domain default supported encryption types via registry:

reg add "HKLM\System\CurrentControlSet\Services\KDC" /v "DefaultDomainSupportedEncTypes" /t REG_DWORD /d 0x18 /f

In Group Policy (Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options), set "Network security: Configure encryption types allowed for Kerberos" to permit AES128_HMAC_SHA1 and AES256_HMAC_SHA1, while unchecking RC4_HMAC_MD5.

5. Contingency Planning and Failure Modes

Disabling RC4 can trigger authentication issues across legacy workloads. Identity teams should prepare for common failure patterns. Hybrid identity setups carry a related exposure; see why Golden SAML still haunts hybrid identity via AD FS token-signing keys.

Silent NTLM Fallback and Key Mismatch

If msDS-SupportedEncryptionTypes is set to 0x18 without resetting the password, Kerberos ticket requests fail, causing applications (such as SQL Server or IIS) to silently fall back to NTLM authentication. This bypasses Kerberos delegation rules and breaks multi-tier authentication. Domain diagnostics reveal the missing key:

The account svc-sql did not have a suitable key for generating a Kerberos ticket
(missing key ID 9). The requested etypes were 18 17. The account's available etypes were 23.
Changing or resetting the password of svc-sql will generate a proper key.

Additional Failure Modes & Interoperability Checklist

• KRB_AP_ERR_MODIFIED Errors: Occur when application hosts receive tickets encrypted with ciphers disabled by local policy or when accounts retain null encryption attributes.
• Delegation Disruptions: Constrained and unconstrained delegation breaks if any service account in the delegation path lacks valid AES key material.
• Linux and Java Keytabs: Resetting a service account password invalidates existing keytab files (.keytab). Update Java/MIT krb5.conf settings to enforce aes256-cts-hmac-sha1-96 and aes128-cts-hmac-sha1-96, then regenerate and deploy new keytabs using adcli or ktutil.
• Legacy Systems: Legacy NAS arrays, embedded network appliances, and pre-Windows Server 2008 OS instances lacking AES support must be isolated or upgraded; Microsoft's July 2026 updates were scheduled to remove the registry rollback, so plan on AES.

Related reading

• Post-Quantum Migration Blueprint: Engineering Networks for NIST FIPS 203–205
• Critical SAML Signature Wrapping Flaw Exposes GitHub Enterprise Server to Unauthenticated Admin Takeover
• HashiCorp Vault Flaw (CVE-2024-7594) Allowed Root Host Takeover via Blank SSH Certificates