AES-Only Kerberos: Prepare for RC4 Decommission in Windows Server

Microsoft has begun the phased removal of RC4 from the Kerberos ticketing path in Windows Server, rolling out audit telemetry and controls in the January 13, 2026 updates and locking the timetable toward a full enforcement phase that will default to AES-only Kerberos encryption by July 2026.

Overview​

Microsoft’s security hardening addresses CVE-2026-20833: an information-disclosure weakness tied to the continued allowance of legacy RC4-based Kerberos service tickets. The vulnerability enables attackers who can request service tickets to obtain weakly encrypted tickets and perform offline attacks to recover service account secrets, potentially leading to lateral movement and escalated access in Active Directory environments. To mitigate that risk, Microsoft released a three-phase plan that begins with monitoring and ends with enforcement, giving administrators a window to discover and remediate RC4 dependencies across their estates.
This change is major for Windows Server environments: domain controllers from Windows Server 2008 through Windows Server 2025 are in scope for the updates that introduce the audit/phase controls and the shift of defaults toward AES-based encryption types. If you manage Active Directory, service accounts, or third-party devices that talk to AD (multifunction printers, NAS boxes, legacy appliances, custom or older apps), you need a plan now to avoid authentication outages starting April 2026 and irreversible enforcement in July 2026.

---

Background: why Microsoft is changing Kerberos defaults​

Kerberos negotiates encryption types (etypes) for service tickets. Historically, for compatibility reasons, some accounts and clients fell back to older ciphers like RC4-HMAC-MD5. While RC4 was once ubiquitous, its structural weaknesses have been well known for years and have already led to its removal from other protocols. In Kerberos, RC4’s continued presence — particularly where accounts do not explicitly declare a modern supported encryption set — allows an attacker with ticket-issue ability to ask for weakly encrypted service tickets and then run offline cryptanalysis to extract keys or passwords.
Microsoft’s approach is pragmatic: make safe defaults and provide detection and temporary opt-ins for compatibility while pushing environments to AES-only. The security trade-off is simple: leaving RC4 enabled by default preserves legacy compatibility but keeps a substantial attack surface open; moving to AES by default raises the bar for attackers while forcing administrators to remediate old clients.

---

What Microsoft changed in January 2026 (technical summary)​

• The January 13, 2026 updates introduce new Kerberos telemetry and audit events on domain controllers that surface when a client is requesting or receiving tickets with weak or legacy etypes such as RC4.
• A temporary registry control named RC4DefaultDisablementPhase was added to allow administrators to steer behavior on domain controllers during the rollout.
  • Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
  • Values:
  • 0 — No audit, no change.
  • 1 — Warning/audit (Initial Deployment default).
  • 2 — Assume RC4 is not enabled by default (simulate stricter behavior).
• The DefaultDomainSupportedEncTypes (DDSET) default will be changed during the rollout so domain controllers assume AES-SHA1 (AES128/AES256 family) for accounts that do not have an explicit encryption-type attribute set.
  • In April 2026 the default DDSET will be changed to 0x18 (AES-SHA1 only) for accounts without an explicit msDS-supportedEncryptionTypes value.
• Important audit events (KDCSVC Event IDs in the 201–209 family) were added; Event ID 205 is specifically used to indicate insecure DDSET configurations that may require action.
• The phasing schedule:
  • January 2026 — Initial Deployment (Audit) with telemetry and RC4DefaultDisablementPhase control.
  • April 2026 — Second Deployment: domain controllers will use AES-only defaults (DDSET=0x18) unless explicit exceptions exist; non-compliant clients may start failing.
  • July 2026 — Enforcement: audit-only controls and the temporary registry toggle are removed and RC4 fallback will no longer be permitted by default; only explicit per-account or per-KDC opt-in will allow RC4, and Microsoft expects most environments to be AES-only.

---

Who and what is affected​

• Domain controllers on Windows Server versions from Windows Server 2008 up through Windows Server 2025 are affected and will receive the telemetry and new behavior via Windows updates.
• Clients and devices that still only speak RC4 (or whose accounts default to RC4 because msDS-SupportedEncryptionTypes is unset) will be impacted. Typical examples:
  • Older multifunction printers and scanners.
  • Legacy NAS appliances and SMB-aware devices.
  • Out-of-support third-party applications or custom apps built against older libraries.
  • Vintage single-purpose servers or appliances that never received modern Kerberos configurations.
• Service accounts that have not had msDS-SupportedEncryptionTypes set to include AES will be treated by DDSET as if they supported older ciphers. Those accounts are the most likely to show up in audit logs.
• Environments that have manually set a local registry DDSET that includes RC4 will see audit warnings and should plan remediation; explicit per-account msDS settings can temporarily allow compatibility but are a maintenance risk.

---

The risk: what CVE-2026-20833 enables in practice​

Microsoft’s advisory describes CVE-2026-20833 as an information-disclosure issue resulting from the use of a broken or risky cryptographic algorithm in Kerberos. The practical attack chain looks like:

1. Attacker obtains the ability to request service tickets (this may require network access and the ability to present a client principal).
2. Attacker forces the KDC to issue service tickets encrypted with RC4 for a target service account.
3. Attacker performs offline cryptanalysis on the captured RC4-protected ticket to recover the service account’s password-equivalent material.
4. With service-account credentials, attacker moves laterally or escalates privileges within an Active Directory domain.

Because the offline analysis happens outside the environment, detection without explicit audit telemetry is challenging. That is why Microsoft’s phased rollout emphasizes early detection and remediation.

---

How to prepare — a practical, prioritized checklist​

This rollout is time-bound: audit in January, enforcement default in April, and hard enforcement in July 2026. Follow this prioritized plan to reduce risk and avoid outages.

1. Patch all domain controllers now with updates released on or after January 13, 2026.
   • This installs the audit telemetry and exposes the RC4DefaultDisablementPhase toggle.
2. Monitor KDCSVC events in the System event log across all domain controllers for event IDs in the 201–209 family.
   • Pay special attention to Event ID 201 (warning) and Event ID 205 (insecure DDSET configuration).
3. Identify accounts and devices that rely on RC4.
   • Use Active Directory queries to detect accounts where msDS-SupportedEncryptionTypes does not include AES. Example PowerShell query:
     • Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18"
   • Search logs for clients that advertise RC4-only etypes in the KDCSVC audit entries.
4. Remediate service accounts and devices.
   • For managed Windows systems, ensure Group Policy "Network security: Configure encryption types allowed for Kerberos" includes AES128 and AES256 so computer accounts set the correct msDS attribute.
   • For service accounts, explicitly set msDS-SupportedEncryptionTypes to include AES values (bitmask). Use your normal account provisioning workflows or PowerShell to set the attribute.
5. Engage third-party vendors and replace or update devices that cannot support AES.
   • Document appliances and embedded systems that cannot be updated; work with vendors for firmware or configuration updates. If no fix is available, plan replacement or isolation.
6. Use RC4DefaultDisablementPhase to stage changeover in controlled groups.
   • The temporary registry toggle lets you emulate stricter behavior on a controlled set of DCs. Set RC4DefaultDisablementPhase=2 only after the audit logs are clean for those domains.
7. Before April 2026, move to Enforcement mode only when you are confident logs are clear and remediation is complete.
   • Remember: from April 2026 the default behavior will be AES-only for accounts without msDS settings; from July 2026 rollback options are removed.
8. Test comprehensively.
   • Test authentication workflows from shared services, printers, backup applications, cloud connectors, and any bespoke application that uses Kerberos or Service Principal Names (SPNs).

---

Detection recipes (operators’ toolbox)​

• Audit KDCSVC events:
  • Monitor the System event log on all DCs for KDCSVC warnings and errors (Event IDs 201–209). Event texts will show the client’s advertised etypes, the target service account’s msDS-SupportedEncryptionTypes, and the domain controller’s DefaultDomainSupportedEncTypes value.
• AD queries for weak or missing msDS values:
  • Use the PowerShell ActiveDirectory module to find accounts where AES is not present. Common approach: filter on bitmasks for AES flags (0x08 and 0x10 are AES128 and AES256 respectively; 0x18 covers both).
• Group Policy verification:
  • Ensure the GPO setting “Network security: Configure encryption types allowed for Kerberos” includes AES128 and AES256 and is applied to domain-joined computers so their msDS attributes are populated.
• Inventory third-party devices:
  • Make a list of networked devices that authenticate using Kerberos. Work with your CMDB or network inventory to identify items that might not support AES.

---

Remediation techniques​

• For Windows-managed machines:
  • Apply the appropriate security patch and ensure GPOs are configured to allow AES. The machine will then set msDS-SupportedEncryptionTypes on its computer account when the policy is applied.
• For service accounts:
  • Set the msDS-SupportedEncryptionTypes attribute explicitly to a value that includes AES. Use your provisioning automation to set this attribute at creation time.
  • When possible, rotate passwords for service accounts and ensure the krbtgt account has AES keys (rotate krbtgt if required as part of a broader Kerberos hardening checklist).
• For appliances and legacy devices:
  • Check vendor documentation for Kerberos/AES support. If updates are not available, plan replacement or network isolation to prevent domain authentication disruptions.
• For applications:
  • Rebuild or update libraries to use modern Kerberos implementations that support AES etypes. For homegrown apps, recompile or reconfigure to use supported crypto APIs.

---

Operational risks and trade-offs​

• Immediate operational risk is authentication outages: devices that cannot do AES will begin to fail when enforcement becomes default in April and will be blocked by July 2026 without the possibility of rolling back.
• Administrative burden: scanning, inventorying, and remediating thousands of service accounts and endpoints can require significant time and coordination with multiple teams and vendors.
• Temporary compatibility allowances (per-account or per-KDC RC4 opt-ins) are available, but they increase ongoing risk and administrative complexity. These should be treated as temporary exceptions only.
• False negatives/positives in detection: auditing telemetry may be verbose; ensure that your collection and SIEM rules can differentiate transient test traffic from persistent dependencies.

---

Testing and staged deployment recommendations​

1. Create a staging OU and a test domain (or isolated lab) that mirrors production AD. Apply the January 2026 updates and set the RC4DefaultDisablementPhase to 2 to emulate April behavior.
2. Run authentication tests for every major application, printer fleet, backup system, and NAS device. Validate ticket issuance and service access.
3. Use targeted enforcement: apply stricter settings to a small set of domain controllers first, monitor audit events, then expand gradually.
4. Maintain a runbook for rollback: know which registry keys to change, how to revert per-account msDS attributes, and how to reconfigure GPOs if an unexpected business-critical outage occurs during testing.
5. Communicate widely: inform application owners, vendors, and service provider teams of the timetable and the need to validate Kerberos AES support.

---

Vendor and third‑party device engagement​

• Prioritize contacts: start with devices that are critical to business continuity (backup servers, SANs/NAS, authentication gateways, MFPs used for legal/regulatory scanning).
• Ask vendors these specific questions:
  • Does the device support AES128/AES256 Kerberos etypes?
  • Is a firmware upgrade or configuration change required to enable AES?
  • If it cannot be upgraded, what is the vendor’s recommended migration or isolation path?
• If a vendor cannot supply updates, plan replacement before April 2026; temporary per-account workarounds are fragile and should not be relied on long-term.

---

Governance: how to manage exceptions safely​

• If you must allow RC4 for a specific service, document the decision and limit scope:
  • Enable RC4 only on the specific service account by setting msDS-SupportedEncryptionTypes explicitly for that account.
  • Restrict network paths to that service via firewall rules and isolate the host in a segmented VLAN.
  • Create a clear sunset date for every exception and track remediation progress.
• Avoid domain-wide DDSET modifications that re-enable RC4 globally; per-account exceptions are safer and auditable.

---

Operational playbooks: automating detection and remediation​

• Automate AD scans for msDS-SupportedEncryptionTypes:
  • Regularly run a scheduled PowerShell job that queries AD for accounts lacking AES in their msDS-SupportedEncryptionTypes attribute and exports a prioritized remediation list.
• Integrate KDCSVC audit events into your SIEM:
  • Flag recurring client IPs or service principal names that surface in Event IDs 201–209 and attach those to tickets assigned to app owners.
• Use configuration management tools (SCCM, Intune, Ansible, etc.) to push Kerberos GPOs and monitor machine compliance.

---

Final assessment: benefits and remaining challenges​

Strengths of Microsoft’s approach:

• Moves the ecosystem to modern, stronger encryption as a default, significantly reducing an actionable attack surface.
• Provides audit telemetry and a temporary toggle so organizations can discover and remediate issues before mandatory enforcement.
• Keeps an opt-in escape hatch for critical legacy systems, while strongly steering admins to modernize.

Risks and pain points:

• The timetable is strict and operationally impactful: April 2026 introduces defaults that will cause failures, and July 2026 removes rollback options.
• Organizations with large fleets of unmanaged or vendor-dependent devices face a potentially costly remediation or replacement program.
• Complexity in Active Directory — msDS attributes, DDSET, and registry quirks across OS versions — may cause surprises; robust testing is essential.

---

Conclusion: what every Windows Server and Active Directory admin should do this week​

• Patch every domain controller with updates released on or after January 13, 2026 immediately to receive audit telemetry.
• Scan your environment for accounts and devices that do not support AES and prioritize remediation based on business impact.
• Use the RC4DefaultDisablementPhase registry toggle in a controlled way to simulate stricter enforcement in test domains before wider rollouts.
• Engage vendors and application owners now — April enforcement will start breaking legacy authentication, and July removes rollback entirely.
• Treat per-account RC4 allowances as temporary, documented exceptions while you migrate systems to AES-capable stacks.

This Kerberos hardening is a long-overdue step for Active Directory security. The benefits for domain security are substantial, but the operational work to achieve AES-only Kerberos at scale can be non-trivial. Start triage and testing now — the enforcement clock is already ticking.

---

Source: Research Snipers Microsoft prepares RC4 shutdown with Windows update – Research Snipers