Microsoft has begun a staged hardening of Kerberos on Windows domain controllers: starting with security updates released on January 13, 2026, domain controllers will gain new telemetry and audit controls that identify weak Kerberos encryption usage, and Microsoft plans a phased default flip so Kerberos KDCs on Windows Server 2008 and later will prefer AES‑SHA1 enctypes while RC4 will be disabled by default unless explicitly allowed — with a second deployment in April 2026 and full enforcement scheduled by July 2026.
Background
Why this matters now
Kerberos encryption type selection determines how hard it is for an attacker to perform offline cracking of service account credentials extracted from Kerberos tickets. The long‑standing presence of RC4‑HMAC (often called RC4 in Windows documentation) has been a compatibility concession for many legacy clients and third‑party appliances, but RC4’s cryptanalytic weaknesses and the older NTLM/RC4 key derivation approach used in Windows significantly lower the cost of offline attacks such as Kerberoasting. The operational result is that service accounts with weak or rarely rotated passwords become high‑value, low‑effort targets. Microsoft explicitly frames the change as raising the bar for attackers by moving to AES‑based enctypes as the default for KDC session keys.What’s prompting the change
Microsoft tied the hardening to a Kerberosre vulnerability tracked as CVE‑2026‑20833, published January 13, 2026, where use of a broken or risky cryptographic algorithm in Windows Kerberos could allow an authorized attacker to disclose information locally. Microsoft’s fixes delivered both telemetry and a staged configuration path to stop issuing RC4 tickets by default, while giving administrators time and tooling to inventory and remediate remaining RC4 dependencies. Public reporting and security vendors echoed Microsoft’s timeline and rationale.Overview of the change: what Microsoft is changing, in plain terms
- Domain controllers running Windows Server 2008 and later will change KDC defaults so that the KDC issues AES‑SHA1 session keys (AES128/AES256 CTS‑HMAC‑SHA1‑96 family) for accounts that do not have an explicit msDS‑SupportedEncryptionTypes attribute, and RC4 will be disabled by default unless explicitly reenabled per‑account or per‑KDC.
- The update sequence is phased:
- January 13, 2026 — Initial deployment: updates begin shipping; added audit telemetry appears and a temporary registry control (RC4DefaultDisablementPhase) lets admins opt‑in earlier where safe.
- April 2026 — Second deployment: the default value for DefaultDomainSupportedEncTypes (DDSET) will change to AES‑SHA1 only (0x18) for accounts without explicit msDS settings.
- July 2026 — Enforcement: audit‑only controls and RC4DefaultDisablementPhase are removed and Enforcement mode will be enabled broadly. At that point, non‑compliant RC4 connections will be blocked unless an exception was explicitly configured.
- Microsoft ships enhanced Kerberos telemetry fields in Windows Security and System event logs (notably extended information on Event IDs such as 4768 and 4769, plus KDCSVC events) so admins can answer whether RC4 is in use because clients advertise it, accounts lack AES keys, or the KDC is configured to permit RC4. The vendor also relers (List‑AccountKeys.ps1, Get‑KerbEncryptionUsage.ps1) and guidance for staged remediation.
Technical specifics: how Kerberos behavior changes
DefaultDomainSupportedEncTypes (DDSET) and msDS‑SupportedEncryptionTypes
The KDC’s choice of ticket encryption is influenced by two things:- the domain controller’s DefaultDomainSupportedEncTypes (DDSET), a registry value that establishes the KDC’s default behavior, and
- the per‑account Active Directory attribute msDS‑SupportedEncryptionTypes, which explicitly advertises which enctypes are acceptable for a given account.
New audit and telemetry events
To make the transition manageable at enterprise scale, Microsoft enhanced logging:- Kerberos Security event entries (for example, Event IDs 4768 for TGT requests and 4769 for service tickets) will include msDS‑SupportedEncryptionTypes, Available Keys (what key material is present for the account), Advertised Etypes (what the client offered), and Ticket/Session Encryption Type (what was used). This makes it possible to pinpoint whether a compatibility problem is client‑side, account‑side, or a KDC default.
- The System event log will also surface KDCSVC events (IDs 201–209 and similar) to flag issues and record audit‑only warnings during the initialcan be used to build SIEM detections and automated remediation playbooks.
