Remove RC4 in Windows Kerberos with New Audit Fields and Remediation Tools

Microsoft is moving Windows authentication firmly away from the legacy RC4 cipher and adding concrete detection and remediation tooling so administrators can identify, isolate, and remediate RC4-dependent accounts and devices before the change becomes the default behavior in domain environments. The company has extended Kerberos auditing (Event IDs 4768 and 4769) to include new fields — msds-SupportedEncryptionTypes, Available Keys, Advertised Etypes, Ticket Encryption Type, and Session Encryption Type — and published PowerShell scripts and tooling to scan event logs and Active Directory for accounts or endpoints that lack AES keys or advertise only RC4. These capabilities make it possible to find authentication client devices that only support RC4, target services that only accept RC4, and accounts that don’t have AES-SHA1-derived keys (AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96) provisioned.

Background / Overview​

Kerberos is the primary authentication protocol for Active Directory domains. Historically, Windows environments allowed a range of Kerberos encryption types including older ciphers like RC4 (RC4-HMAC) for compatibility with legacy systems. Over the past several years, Microsoft and the security community have pushed to remove weak cryptography from core infrastructure, and RC4 has long been flagged as cryptographically broken for many uses. Microsoft’s recent guidance formalizes the next step: domain controllers (the KDC) will default to allowing only AES-SHA1 session keys — leaving RC4 available only when explicitly configured — to reduce the attack surface for credential-theft techniques such as Kerberoasting. The practical mechanics of Kerberos encryption selection are controlled by several factors:

• The client’s advertised encryption types (what the client says it can handle).
• The account’s msds-SupportedEncryptionTypes (the encryption suites an account is set to support in AD).
• What keys are actually available for an account in Active Directory (the derived keys created when passwords are set).
• The KDC’s policy or registry settings (for example, the DefaultDomainSupportedEncTypes registry key on domain controllers).

Understanding these interactions is essential for planning a safe migration to an AES-only default for Kerberos session keys.

---

What changed in Kerberos auditing (Event IDs 4768 and 4769)​

Microsoft has enhanced the Security Event Log on domain controllers to include the following new data points in the standard Kerberos events:

Key new fields​

• msds-SupportedEncryptionTypes — the encryption algorithms the account advertises as supported (stored in Active Directory). This appears for both the requestor and target/service account. Absence of AES-SHA1 in this value is a red flag for an account likely to fall back to RC4.
• Available Keys — lists the actual derived keys present for the account in AD. A normal, modern account should show both RC4 (the MD4/NTLM-derived key) and AES128/256-SHA96 keys. If AES keys are missing (but RC4 exists), the account will need a password reset to generate AES keys.
• Advertised Etypes — what the Kerberos client sent in its AS-REQ or TGS-REQ indicating which etypes it supports. Use this to find clients that only advertise RC4.
• Ticket Encryption Type — the encryption type the KDC used for the issued TGT/TGS ticket. (Note: in some corner cases the ticket etype and the session key etype differ.
• Session Encryption Type — the etype used for the session key returned in a specific ticket request. This is the critical value to filter: when the session key is RC4, the client/service compatibility is still hinging on the legacy cipher.

These fields were added to make the encryption negotiation visible in audit logs, enabling targeted remediation: you can now identify whether you have a client-only problem (client advertises only RC4), a service-only problem (target supports only RC4), or an account-preparedness problem (no AES keys available).

---

Why this matters: compatibility, risk, and the mid-2026 timing​

Microsoft’s blog post explains that by mid-2026 the company will update domain controller defaults so the Kerberos KDC will only allow AES-SHA1 session keys by default; RC4 will be disabled by default and used only if a domain admin explicitly configures accounts or the KDC to allow it. If administrators do not address remaining RC4 usage before the default changes land, authentication relying on RC4 may stop working. This introduces a hard deadline for remediation planning. Security implications:

• RC4 lacks modern cryptographic protections and has been a practical enabler of Kerberoasting-style attacks and other credential-theft techniques.
• Leaving RC4 enabled prolongs the attack surface; removing RC4 by default reduces reliance on NTLM-derived keys and forces environments to adopt stronger AES-based encryption.
• Operational implications: If accounts, devices, or third-party appliances still depend on RC4, disabling it without remediation will cause authentication failures — potentially for critical services. That’s why Microsoft provided detailed detection tools and guidance in tandem with the policy change.

---

How to detect RC4 usage in your environment​

Microsoft ships detection tooling and example scripts and advises using centralized collection (Event Forwarding, SIEM, Microsoft Sentinel). The blog and Kerberos tooling repo include two PowerShell scripts that query the enhanced Kerberos events:

• List-AccountKeys.ps1 — enumerates the Available Keys field from the event logs and shows whether accounts have AES keys. Example output lists account names with keys like {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}. This immediately identifies accounts that lack AES keys and therefore must be remediated before RC4 is removed.
• Get-KerbEncryptionUsage.ps1 — summarizes the encryption types used for recent Kerberos operations, showing Ticket and SessionKey values (e.g., AES256-SHA96). It accepts filters (for instance, -Encryption RC4) to find specific problematic uses. Use these scripts in conjunction with Windows Event Forwarding, a SIEM, or Microsoft Sentinel rule sets to create alerts for RC4 session keys.

Additional tooling:

• The Kerberos-Crypto GitHub project contains a helpful EType calculator and other resources to reason about how client ETypes, server account msds-SET, KDC defaults, and the target account combine to produce the resulting Ticket and Session etypes. Use the etype-calculator to model tricky configurations before rolling changes.

Operational checklist to find RC4 dependents:

• Query Event ID 4768 and 4769 for Advertised Etypes, Available Keys, and Session Encryption Type; filter for entries showing RC4 in either Advertised Etypes or Session Encryption Type.
• Run List-AccountKeys.ps1 to build a list of accounts missing AES keys.
• Use ADUC (Advanced Features) or Get-ADObject to inspect msds-SupportedEncryptionTypes values for accounts with SPNs or services.

---

Step-by-step remediation guidance​

The following ordered steps reflect Microsoft’s recommended path to eliminate RC4 dependency while minimizing outage risk.

• Inventory and detect
• Collect 4768/4769 events from all domain controllers and centralize them in a SIEM or via Event Forwarding.
• Run Get-KerbEncryptionUsage.ps1 to identify which requests used RC4 for the session key and which accounts or devices advertise only RC4.
• Repair account keys
• For accounts that show Available Keys containing RC4 but not AES keys, reset the account password (or rotate the password for managed accounts). Password resets generate derived AES keys (AES128/AES256) in AD. Verify after reset that AES keys appear in Available Keys.
• Update msds-SupportedEncryptionTypes where necessary
• If an account’s msds-SupportedEncryptionTypes does not include AES bits, update the attribute either via ADUC (Attribute Editor) or PowerShell (Get-ADObject / Set-ADObject) to include AES128-SHA96 and AES256-SHA96, then restart the device or service to ensure the new msds-SET is written and used. Be deliberate: changing msds-SET is potentially disruptive if you have true legacy dependencies.
• Set domain defaults and KDC configuration intentionally
• Review the DefaultDomainSupportedEncTypes registry key on domain controllers and understand the KDC’s allowed encryption types. Microsoft’s KB5021131 documents how updates after November 8, 2022 introduced this registry key and explains default behaviors; validate your DefaultDomainSupportedEncTypes setting and consider setting a domain-wide default that includes AES128/256 but excludes RC4 once you’re confident no legacy clients remain.
• Harden via Group Policy and baselines
• Apply Microsoft’s security baselines or use Windows Admin Center to audit the policy Network security: Configure encryption types allowed for Kerberos. The security baseline values that exclude RC4 are published with Windows Server 2025 guidance; verify compliance using the Security Baseline report in WAC.
• Test carefully before enforcement
• Use pilot OUs and test domains. Enforce AES-only on a subset of domain controllers or accounts first, monitor authentication behavior, and only then widen the enforcement. If third-party appliances are in the environment, test them thoroughly. Any service outage risk must be mitigated by rollback plans and scheduled change windows.
• Communicate and coordinate with vendors
• Some non-Windows devices and older appliances may not support AES-SHA1 etypes. Microsoft asks vendors to report compatibility issues (they provided an address to report devices that still need RC4). For appliances or embedded systems, coordinate vendor upgrades or replacements in advance of the default change.
• Automate and monitor ongoing compliance
• Create SIEM alerts for Event 4768/4769 where Session Encryption Type = RC4 or where msds-SupportedEncryptionTypes lacks AES bits. Schedule periodic scans via the provided PowerShell scripts and the Kerberos-Crypto tooling.

---

Common gotchas and risks​

• Available Keys will often still show RC4 even after everything else moves to AES. That’s because Active Directory retains the MD4 (NTLM-derived) credential for NTLM compatibility; even in AES-only ticketing scenarios the NTLM hash may remain in AD. Microsoft engineers and community experts have explained that the presence of the RC4-derived key in AD doesn’t necessarily mean RC4 is in use, but it does indicate legacy credentials are present and may be used in fallback scenarios. Administrators should expect the RC4 entry in Available Keys until the ecosystem moves away from NTLM entirely.
• Non-Windows clients and keytabs: SSH forwarders, Unix/Linux Kerberos clients, macOS tools, and third-party keytab files may advertise or request RC4 session keys by default. These clients often need configuration changes (e.g., /etc/krb5.conf) or re-keying of keytab files to prefer AES etypes. Without this, authentication into Windows resources could fail when the KDC stops selecting RC4 session keys. Community examples show macOS ssh agent behavior producing RC4 session keys until krb5.conf is updated.
• Domain functional level and password rotation history: accounts in domains with a low domain functional level (pre-2008) or accounts that never had a password rotation since AES was supported may not have AES keys. Ensure your environment’s domain functional level and password rotation processes are compatible with generating AES-derived keys. Resetting passwords is the typical fix for accounts missing AES keys.
• Misconfigured DefaultDomainSupportedEncTypes can accidentally block AES or retain RC4; the November 2022 Kerberos updates introduced behaviors administrators need to review. Don’t change the registry key without testing and understanding the implications across multi-domain forests.
• Unverifiable third-party claims: if a vendor asserts their device can support AES but provides no documentation or firmware to demonstrate it, treat their claim as unverified until tested. Administrators should insist on evidence (configuration options, firmware releases, or vendor KB articles) before relying on such claims for migration decisions.

---

Monitoring, testing, and validation — practical examples​

• Use Event Forwarding to route 4768/4769 to your SIEM. Create queries that search for:
• Session Encryption Type = RC4
• Advertised Etypes contains RC4 only
• Available Keys missing AES128-SHA96 and AES256-SHA96
• Example PowerShell workflow:
• Run List-AccountKeys.ps1 across your DC event logs to produce a CSV of accounts missing AES keys.
• For each account listed, schedule an account password reset (for machine accounts, rebooting the machine after the reset forces the update into AD).
• Re-run List-AccountKeys.ps1 to confirm AES keys now exist.
• Use the Kerberos EType calculator to model tricky cases where msds-SET is blank or multiple interacting defaults could produce unexpected ticket/session encryption choices. This helps avoid surprises in mixed OS or mixed-vendor environments.

---

Cross-checking Microsoft’s recommendations and prior changes​

This migration builds on earlier Kerberos protocol changes and guidance:

• The November 2022 Kerberos update added the DefaultDomainSupportedEncTypes registry key and changed how KDCs treat undefined msds-SupportedEncryptionTypes; KB5021131 explains how to manage these changes and why environments may have seen authentication differences after those updates. Administrators should read that KB and test registry settings before broad enforcement.
• Microsoft’s Active Directory hardening and Kerberos guidance (community posts and the Core Infrastructure & Security blog) provide deeper explanations of msds-SupportedEncryptionTypes bit flags, strategies to enforce AES, and long-running community feedback about corner cases where Ticket EType and Session Key EType diverge. These community posts are valuable companion material when designing a migration plan.

Cross-referencing Microsoft Learn’s event documentation (4768 and 4769) with the Windows Server blog ensures the event-field definitions and remediation suggestions align with the operational scripts published on the Kerberos-Crypto GitHub repo and with the KB guidance on DefaultDomainSupportedEncTypes. Use both the official docs and community analyses to validate your plan.

---

Recommended timeline and priorities for admins​

• Immediate (0–3 months)
• Deploy the detection scripts and collect baseline telemetry (4768/4769) to discover RC4 usage and accounts lacking AES keys.
• Prioritize high-value service accounts (SPNs) and domain-joined servers for remediation.
• Short-term (3–9 months)
• Reset passwords for accounts missing AES keys, update msds-SupportedEncryptionTypes as needed, and coordinate vendor fixes for appliances or embedded devices that do not support AES.
• Implement Group Policy baselines and use Windows Admin Center to audit compliance.
• Mid-term (9–18 months, before mid-2026)
• Run extended pilots enforcing AES-only in non-production OUs and validate all business-critical workflows.
• Create rollback playbooks for unplanned outages.
• Deadline (by mid-2026)
• Ensure there are no remaining RC4-only clients or service accounts before KDC defaults are changed; remove or explicitly approve any remaining RC4 exceptions only as short-term stopgaps.

Note: the exact “mid-2026” enforcement plan and rollout timeline come from Microsoft’s public Windows Server blog; treat it as the operational deadline for planning, and validate any changes against Windows Server release notes and Microsoft’s security guidance closer to the date.

---

Final assessment: strengths, limitations, and residual risks​

Strengths

• Visibility: The addition of msds-SupportedEncryptionTypes, Available Keys, and Session Encryption Type to 4768/4769 is a major operational win. For the first time, teams can precisely identify which accounts and devices are blocking an AES-only Kerberos posture directly from audit logs.
• Actionability: Microsoft published PowerShell scripts and tooling to interrogate logs and AD, giving administrators an operational path to remediate — from account resets to policy changes and WAC-based compliance checks.
• Policy-driven path: Introducing a default change (and giving advance notice) creates a clear window for organizations to modernize authentication without surprise outages.

Limitations and risks

• Legacy device compatibility: Third-party appliances, embedded systems, and older OSes may not support AES session keys and can be difficult to upgrade. Vendor coordination is required; in many environments this will be the main blocker. Vendor claims must be validated.
• Operational complexity: msds-SupportedEncryptionTypes behavior interacts with domain functional level, registry defaults (DefaultDomainSupportedEncTypes), and KDC configuration. Mistakes in these settings can lead to unexpected authentication failures. KB5021131 and community guidance must be consulted when changing defaults.
• Residual NTLM/RC4 artifacts: AD will likely continue to store RC4/NTLM-derived credentials for some time, so presence of RC4 in “Available Keys” isn’t an automatic indicator that RC4 is being used — it’s an indicator that legacy credentials exist. However, until NTLM fallback is fully eliminated, those artifacts represent residual attack surface.

Cautionary note: any statements about exact vendor support timelines or firmware updates are outside the scope of Microsoft’s guidance and must be verified directly with vendors. Where the community or vendors offer remediation scripts or third-party tools, treat those as supplemental and test thoroughly.

---

Conclusion​

The changes Microsoft published — adding rich Kerberos auditing fields and publishing remediation scripts — are a decisive and welcome step for administrators tasked with removing weak cryptography from the authentication stack. The new fields in Events 4768 and 4769 (msds-SupportedEncryptionTypes, Available Keys, Advertised Etypes, Ticket Encryption Type, and Session Encryption Type) give security teams concrete telemetry to find RC4-dependent clients, services, and accounts. Microsoft’s published scripts, the Kerberos-Crypto tooling, and guidance on registry and Group Policy settings provide an actionable remediation path that should be followed well ahead of the mid-2026 default-change deadline to avoid authentication disruption. Plan a staged rollout: inventory with the new logs and scripts, rotate account passwords where needed to create AES keys, update msds-SupportedEncryptionTypes carefully, validate non-Windows client configurations, and enforce AES-only settings in a controlled way. This is an operationally manageable but strategically significant move away from RC4 toward a stronger Kerberos posture for Active Directory environments.

---

Source: Microsoft Beyond RC4 for Windows authentication