Kerberos RC4 Deprecation: Find and Fix RC4 Dependencies Before Enforcement

Microsoft has stopped Active Directory domain controllers from quietly falling back to RC4 for Kerberos service tickets, and anything that still depends on RC4 without saying so will fail. The change is a Microsoft security hardening update and was rolled out in phases through 2026 under Microsoft support article KB 5073381. This guide is a dated migration runbook: what changed, how to read the new KDCSVC events and the 4768/4769 fields, how to fix accounts, keytabs and non-Windows clients, and how to roll back narrowly when something breaks. It is written for Active Directory administrators, identity engineers and the Linux and appliance owners who share a realm with them. For general Kerberos hardening, see the Kerberos Security Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The default is what changed, not RC4 itself. Accounts with no msDS-SupportedEncryptionTypes value used to inherit RC4; after enforcement they inherit AES-SHA1 only (0x18), while accounts explicitly configured for RC4 keep working.
• KDCSVC events 201 to 209 are your work list. Warnings 201, 202, 206 and 207 in the domain controller System log predict exactly which requests become errors 203, 204, 208 and 209 under enforcement.
• Most breakage is missing AES keys. Old service accounts whose passwords predate AES support, and keytabs exported with only RC4-HMAC-NT keys, are the usual causes; a password reset or keytab regeneration fixes them.
• The rollback switch has gone. RC4DefaultDisablementPhase was a temporary registry value that the July 2026 updates no longer read, so the only remaining exception is per-account (or domain-wide) explicit RC4 configuration.
• Treat every RC4 exception as a dated risk acceptance. RC4 keys are derived from the account's NT hash, so each exception keeps a Kerberoasting-friendly target alive and needs an owner and an end date.

What is changing and why

When a client asks the Key Distribution Center (KDC) for a service ticket, the KDC chooses the ticket encryption type from what the target account supports. That support is recorded in the account's msDS-SupportedEncryptionTypes attribute. Most user-based service accounts never had the attribute set, so the KDC applied a domain default, and historically that default included RC4-HMAC. Microsoft's KB 5073381 changes the default the KDC assumes for these accounts to AES-SHA1 only, so a blank attribute now means AES128 and AES256, not RC4.

Microsoft describes the change as a security update for Kerberos. The practical security reason is long known: an RC4-HMAC key is the account's unsalted NT hash, so a service ticket encrypted with RC4 is far cheaper to attack offline than an AES ticket. That is the core of Kerberoasting (MITRE ATT&CK T1558.003). See the MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide.

Useful msDS-SupportedEncryptionTypes values: 0x4 (4) RC4 only, 0x18 (24) AES128 and AES256, 0x1C (28) RC4 plus both AES types, 0x24 (36) RC4 with an AES256 session key, 0x38 (56) AES types plus AES session key enforcement.

Official timeline and current status

Dates below are as published in KB 5073381 and Microsoft's Core Infrastructure and Security blog posts, checked on 8 November 2026. The KB names the July phase by month only.

The KB applies to domain controllers running Windows Server 2012 and 2012 R2 (ESU), 2016, 2019, 2022, version 23H2 and 2025. Separately, Microsoft documents that Windows Server 2025 domain controllers do not issue RC4 TGTs at all. If your domain controllers have taken July 2026 or later updates, you are in the final phase now: the work is cleaning up exceptions, not preparing for a deadline. Microsoft revised these articles several times during 2026, so recheck the KB before relying on a specific behaviour.

Who and what is affected

• Service accounts with old passwords: accounts whose password was last set before the domain could generate AES keys hold only RC4 keys. Requests to them log event 202 (becoming 204) and fail under enforcement.
• Non-Windows services using keytabs: Linux web servers, Java applications, databases, NAS devices and printers that authenticate with a keytab exported using only RC4-HMAC-NT. Microsoft calls these the most likely to break.
• Clients that only advertise RC4: old embedded Kerberos stacks or hosts with a hard-coded RC4 policy. These raise 201 (blank attribute) or 206 (attribute set to AES only).
• Legacy GPOs: a "Configure encryption types allowed for Kerberos" policy that once restricted machines to RC4 is still enforced and causes AES/RC4 mismatches.
• External and forest trusts: Microsoft notes intra-forest trusts have used AES since the November 2022 updates, but external trusts and trusted forests must be confirmed to support AES.
• Very old systems: Windows XP and Server 2003 cannot read msDS-SupportedEncryptionTypes and have no supported path; Microsoft's guidance is to migrate them.

Many of the accounts in scope are non-human identities nobody owns any more. See the How to find service accounts with Domain Admin rights guide for the inventory side.

Finding affected systems and identities

KDCSVC events (System log, every domain controller)

Security events 4768 and 4769

Ticket requests on domain controllers show the encryption actually used. Filter for Ticket Encryption Type 0x17 (RC4-HMAC) and also read Session Encryption Type, Advertized Etypes (what the client offered) and Available Keys (what AD holds for the account). Windows Server 2016 gained these RC4 fields with the January 2025 cumulative update; on 2022 and earlier, DES and RC4 always appear in the supported list for compatibility, so do not treat that alone as a finding. A failed request with Failure Code 0xE (KDC_ERR_ETYPE_NOTSUPP) is the enforcement symptom.

1. Collect centrally: forward System (KDCSVC) and Security (4768, 4769) logs from all domain controllers to your SIEM or Windows Event Forwarding; a single DC sees only its share of requests.
2. Run Microsoft's scripts: Get-KerbEncryptionUsage.ps1 -Encryption RC4 summarises RC4 usage by client and service; List-AccountKeys.ps1 lists the keys held for accounts seen in the logs, exposing those with no AES keys. Both are in Microsoft's Kerberos-Crypto repository on GitHub.
3. Query attributes: list accounts with a servicePrincipalName and read msDS-SupportedEncryptionTypes and pwdLastSet. Values of 4 or 28 show explicit RC4; very old pwdLastSet dates suggest missing AES keys.
4. Audit keytabs off-domain: on Linux hosts, list keytab entries with klist -e -k (MIT) and look for arcfour-hmac or rc4-hmac only. Search configuration management for krb5.conf files that set permitted_enctypes or default_tkt_enctypes to RC4, or allow_weak_crypto = true.
5. Build the register: one row per service with account, SPN, owner, host, etype seen, fix and target date.

Migration options

• Keytab regeneration: always pass /crypto to ktpass, because its defaults reflect old MIT behaviour. Map the principal with /mapuser, use /ptype KRB5_NT_PRINCIPAL, and match the case of /princ to the account's userPrincipalName. Distribute the new keytab through your secrets tooling rather than email or shared folders, then confirm with klist -e -k on the host.
• MIT and Heimdal clients: MIT krb5 lists arcfour-hmac as deprecated and, from release 1.21, does not issue RC4 session keys unless allow_rc4 is set. Remove legacy permitted_enctypes overrides rather than adding RC4 back.
• Better than a reset: where the application supports it, convert the account to a gMSA so passwords and AES keys rotate automatically. See the How to convert AD service accounts to gMSA guide.

Testing and rollback

1. Clear warnings first: work the 201, 202, 206 and 207 list until it is empty for at least one full business cycle, including month-end batch jobs.
2. Pilot per account: set msDS-SupportedEncryptionTypes to 24 on a few remediated service accounts and test with klist purge followed by klist get <SPN> from a real client; confirm 4769 shows 0x12.
3. Know the failure signatures: SMB shares return a network error, WinRM and New-PSSession return 0x80090342, and klist get reports "The encryption type requested is not supported by the KDC".
4. Roll back narrowly: under the final phase, re-enable RC4 only on the failing account (0x1C, or 0x24 where a very old client needs it), restart the affected service and log a dated exception. Avoid changing DefaultDomainSupportedEncTypes; if you must, set the same value on every domain controller.
5. Re-test after password changes: any password reset changes the kvno, so update keytabs in the same change window.

Risks of doing nothing

• Outages you cannot quickly reverse: the temporary registry switch is gone, so unprepared services fail until accounts or keytabs are fixed.
• Bad exceptions under pressure: teams in an outage tend to set a domain-wide RC4 default, reopening the weakness for every account.
• Kerberoasting exposure: any account still issuing RC4 tickets is a cheaper offline cracking target, and service accounts often hold broad privileges (T1558.003; AS-REP roasting is T1558.004).
• Audit findings: explicit RC4 configuration conflicts with cryptographic protection requirements such as NIST SP 800-53 SC-13.

Metrics to track: RC4 (0x17) ticket requests per day across all DCs, trending to zero; count of KDCSVC warning and error events; number of SPN accounts without AES keys; number of open RC4 exceptions and their age; percentage of keytabs re-exported with AES only.

Practitioner checklist

• Confirm every domain controller has January 2026 or later updates and record which update level each runs.
• Forward KDCSVC 201 to 209 and Security 4768/4769 events from all DCs to one place.
• Run Get-KerbEncryptionUsage.ps1 and List-AccountKeys.ps1 and build an RC4 register with owners.
• Reset passwords on service accounts lacking AES keys, then re-export any linked keytabs with /crypto AES256-SHA1.
• Remove RC4-only Group Policy and krb5.conf overrides; check allow_weak_crypto and permitted_enctypes.
• Set msDS-SupportedEncryptionTypes to 24 (or 56 where tested) on remediated SPN accounts.
• Confirm external trusts and trusted forests support AES before relying on AES-only behaviour.
• Keep RC4 only as per-account exceptions with an owner, a reason and an expiry date, reviewed monthly.
• Move suitable service accounts to gMSA so AES keys rotate automatically.

Standards and references

• Microsoft Support: KB 5073381, managing Kerberos KDC usage of RC4 for service account ticket issuance
• Microsoft Learn: Detect and remediate RC4 usage in Kerberos
• Microsoft Tech Community: What changed in RC4 with the January 2026 Windows update
• Microsoft Tech Community: How to manage RC4 hardening, definitive guide
• Microsoft Learn: ktpass command reference
• MIT Kerberos: Encryption types
• MITRE ATT&CK: Kerberoasting
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Kerberos Security Guide · Group Managed Service Accounts (gMSA) Guide · MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide · Active Directory and Entra ID Hardening Guide