RC4 deprecation in Kerberos: prepare for July 2026 enforcement

Questo articolo è disponibile anche in lingua italiana, al seguente link – Dismissione di RC4 in Kerberos: prepararsi all’enforcement di luglio 2026 – WindowServer.it

Starting with the January 2026 cumulative updates, Microsoft has begun a phased deprecation of the RC4 (Rivest Cipher 4) cipher within the Kerberos authentication protocol. The path is structured in three stages and culminates in July 2026, when every rollback mechanism is removed and RC4 ceases to be an implicitly supported cipher on Domain Controllers. The change is rooted in CVE-2026-20833, a vulnerability that allows an authenticated attacker to exploit the cryptographic weakness of RC4 to conduct Kerberoasting attacks and compromise service account credentials.

The impact of this transition is far from negligible. Long-standing Active Directory environments often contain accounts, services, appliances, and third-party devices that depend — implicitly or explicitly — on the RC4 cipher. Domain-joined NAS units, legacy file servers, network printers, and industrial applications with outdated Kerberos stacks are all prime examples. This article analyzes in detail the operational scenarios an administrator must evaluate, with particular attention to the behavior of non-Windows domain-joined devices, and describes the workarounds available through Group Policy and targeted configurations.

Why RC4 is being deprecated

The RC4 cipher has historically been kept in Kerberos to ensure compatibility with legacy systems. Its cryptographic weakness, however, makes it vulnerable to offline brute-force attacks against the Ticket-Granting Service (TGS) tickets issued by the KDC. The Kerberoasting technique exploits exactly this weakness: an authenticated attacker requests service tickets encrypted with RC4 for accounts holding a Service Principal Name (SPN), then performs offline cracking to recover the service account password.

Microsoft has officially stated, in the Microsoft Learn technical documentation, that RC4 support as the assumed encryption type for Domain Controllers will be disabled by the end of the second quarter of 2026. The alternative — AES-SHA1 in its AES128 and AES256 variants — has been available in every Windows Server version since Windows Server 2008 and is today the reference standard.

The three phases of the deprecation

The deprecation process unfolds over a seven-month window, structured to give administrators time to identify residual dependencies before the final enforcement. The three phases are as follows:

• January 2026 — Audit phase. The cumulative updates introduce nine new event IDs (201 to 209) in the System Event Log of Domain Controllers, and enrich events 4768 and 4769 in the Security Log with additional information. No authentication flow is blocked at this stage: the goal is purely to provide visibility on existing RC4 dependencies. The registry key RC4DefaultDisablementPhase is also introduced, allowing administrators to anticipate enforcement manually by setting the value to 2
• April 2026 — Enforcement phase with rollback. The DefaultDomainSupportedEncTypes (DDSET) value used by the KDC changes its default to 0x18 (AES128 + AES256). Accounts without an explicit value in the msDS-SupportedEncryptionTypes attribute will stop receiving RC4 tickets implicitly. Rollback to audit mode remains technically possible through the registry key
• July 2026 — Final enforcement phase. The RC4DefaultDisablementPhase registry key is ignored by updated Domain Controllers, and audit mode is no longer available. RC4 will continue to function exclusively for accounts that explicitly declare it in the msDS-SupportedEncryptionTypes attribute. After this date, no implicit fallback mechanism remains

The msDS-SupportedEncryptionTypes attribute and the Kerberos bitmask

Understanding how the msDS-SupportedEncryptionTypes attribute works is the key to evaluating the exposure of any environment. It is a bitmask that declares, for each security principal (user, computer, service account, trust), which Kerberos encryption types are supported by the underlying system. If the attribute is null or set to zero, the KDC applies the default value defined by the DefaultDomainSupportedEncTypes registry key — and this is precisely the default that is changing with the 2026 updates.

The following table reports the most common bitmask values and their operational meaning relative to the ongoing enforcement:

An aspect that is often overlooked is that the presence of an explicit value does not automatically equate to enforcement compatibility. An account configured with 0x4 (RC4 only) is technically “populated”, but it will continue to fail authentication after April 2026, because it offers no negotiable AES cipher. The AD attribute declares what the KDC assumes is supported: if the underlying system — be it a NAS, a printer, or a custom service — does not implement AES, the attribute cannot grant a capability the device does not possess.

Domain-joined NAS and non-Windows devices: five operational scenarios

Domain-joined NAS units represent one of the most delicate scenarios of the entire transition. These devices integrate a vendor-implemented Kerberos stack (Synology, QNAP, NetApp, Dell EMC, Buffalo, and others) with maturity and update levels that vary significantly between models and firmware versions. The situation is not binary: there are several scenarios, each with its own risk profile.

Scenario A — recent firmware with explicit msDS-SupportedEncryptionTypes attribute

This is the ideal scenario. During the domain join — or later, through a re-registration script — the NAS populates the msDS-SupportedEncryptionTypes attribute of its computer account with a value that includes AES-SHA1 (typically 0x18 or 0x1C). The NAS operating system natively supports AES128 and AES256, and the KDC issues AES tickets for SMB sessions, Kerberos NFS, and administrative access.

In this case, the July 2026 enforcement produces no impact. The attribute is explicit, the value includes AES, and the NAS can correctly process the tickets received. No corrective action is required.

Scenario B — recent firmware but unset attribute

Some NAS units, particularly those joined to a domain several years ago and never rejoined since, have a null or zero msDS-SupportedEncryptionTypes attribute. Under this condition, the KDC applies the value of DefaultDomainSupportedEncTypes. Until April 2026 this default included RC4; from that date the default becomes AES-only (0x18).

The post-enforcement behavior depends on the actual ability of the NAS to negotiate AES:

• If the NAS supports AES natively, authentication will continue to work because the client advertises its AES capability to the KDC through the Advertised Etypes field. The configuration nevertheless remains fragile: events 4769 with the error KDC_ERR_ETYPE_NOTSUPP (0xE) may appear in edge-case scenarios. Populating the attribute with 0x18 to make the configuration explicit is strongly recommended
• If the NAS does not support AES (old firmware, Kerberos stack based on outdated libraries), Kerberos authentication will fail completely after April 2026. Users will receive generic network errors when accessing SMB shares; WMI and PowerShell Remoting connections to the NAS will return error 0x80090342. The Domain Controller logs will show event 4769 with Failure Code: 0xE

Scenario C — legacy NAS with RC4-only support and unset attribute

This is the worst case and, unfortunately, far from rare in industrial environments or organizations with long hardware life cycles. The NAS implements a Kerberos stack that supports RC4 only, in some cases inherited from outdated Samba 3.x implementations or proprietary firmware never ported to the AES standard. The msDS-SupportedEncryptionTypes attribute is unset, and from April 2026 onwards the KDC will attempt to issue AES tickets.

The result is a complete breakage of Kerberos authentication toward the NAS. The mechanism is the following: the KDC, receiving no explicit declaration in the attribute and applying the new AES-only DDSET, issues a ticket encrypted with AES; the NAS, receiving a ticket it cannot decrypt, rejects the request and the SMB session breaks. From the user perspective, shares become unreachable; from the Domain Controller perspective, logs record ticket requests with no possibility of negotiating a common cipher.

In the absence of a firmware update introducing AES support (an option to verify with the vendor as the very first step), the only viable technical mitigation is to explicitly declare RC4 as a supported cipher for that single computer account, accepting the residual security risk.

Scenario D — RC4-only NAS with attribute populated as RC4

In this scenario, the msDS-SupportedEncryptionTypes attribute of the computer account was populated with 0x4 (RC4 only) during the join, consistently with the actual capabilities of the NAS. Contrary to what one might expect, this configuration survives the July 2026 enforcement: as clarified in the official Microsoft documentation, RC4 will continue to function for accounts that explicitly declare it.

This is, however, a configuration that represents both technical and security debt. Accounts with RC4 explicitly enabled remain a privileged target for Kerberoasting attacks, especially when associated with SPNs. Furthermore, Domain Controllers based on Windows Server 2025 no longer issue RC4 Ticket-Granting Tickets (TGTs): this means that, while the device may still authenticate inbound, it will not be able to authenticate further toward other services using Kerberos.

Scenario E — NAS that does not support the msDS-SupportedEncryptionTypes attribute

There is one further, more subtle scenario in which the NAS is technically domain-joined but its join process has never been able to write or update the msDS-SupportedEncryptionTypes attribute on its own computer account. This happens with very old Samba implementations, with appliances using a limited LDAP bind, or with devices that treat the join as pure authentication without managing the extended attributes of the computer account.

From the Active Directory perspective, the attribute is null and the behavior follows what is described in Scenario B or C, depending on the actual cryptographic capabilities of the device. The crucial difference is that the administrator cannot rely on the NAS to keep the attribute synchronized: it must be set manually from a Domain Controller via PowerShell or ADSI Edit, and verified periodically to ensure it is not overwritten to null at the next reboot or rejoin of the device.

Remediation strategy: a phased operational approach

The mitigation strategy must be built sequentially, leveraging the audit window introduced in January 2026 to identify dependencies and act before enforcement. The recommended operational order is described in the following sections.

Phase 1 — Environment audit

The first step is to install the January 2026 cumulative update (or later) on all Domain Controllers. This update enables audit events 201–209 and enriches events 4768 and 4769 in the Security Log with additional information. It is important to stress that installing the update does not introduce any block by itself: its sole purpose is to provide visibility.

Microsoft makes available, on the official microsoft/Kerberos-Crypto GitHub repository, two PowerShell scripts that are essential for the audit phase:

• List-AccountKeys.ps1 — queries the Security Event Log and lists the cryptographic keys available for the detected accounts. It identifies accounts that hold only RC4 keys and lack AES keys
• Get-KerbEncryptionUsage.ps1 — analyzes the actual cipher usage in ticket requests, with the option to filter by specific algorithm (for example -Encryption RC4) to isolate only the tickets issued with the deprecated cipher

For larger environments, it is advisable to centralize the analysis through a SIEM solution (Microsoft Sentinel, Splunk, Elastic) or via Windows Event Forwarding to a dedicated collector. The recommended minimum observation period is two to three weeks, in order to also intercept periodic workloads such as overnight backups, monthly scheduled jobs, and reconciliation processes.

Phase 2 — Service account and computer account inventory

In parallel with the dynamic audit, a static inventory of the msDS-SupportedEncryptionTypes attribute across all Active Directory accounts is required. The following PowerShell query identifies service accounts with an associated SPN, which represent the primary perimeter of the Kerberoasting risk:

Get-ADUser -Filter {ServicePrincipalName -like "*"} `
    -Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
  Select-Object SamAccountName, @{N="EncTypes";E={$_.'msDS-SupportedEncryptionTypes'}}

An equivalent query should be run on Get-ADComputer to identify computer accounts — including NAS units — without an explicit attribute value. The decimal value 28 corresponds to 0x1C (RC4 + AES128 + AES256): these accounts will function after July 2026, but they keep RC4 enabled and should be progressively moved to 0x18.

Phase 3 — Targeted remediation

Based on the audit results, the following corrective interventions apply, in order of priority:

• Reset passwords for service accounts lacking AES keys. Accounts created before AES support was introduced in Windows Server 2003, and never subjected to a password change since, do not hold the necessary AES keys. A simple password reset, executed on a modern Domain Controller, automatically generates the AES128 and AES256 keys
• Explicitly populate msDS-SupportedEncryptionTypes. For each account identified with a null attribute and actual AES support, set the value to 0x18. For computer accounts representing devices with mixed support (RC4 + AES), set 0x1C as a transitional measure, planning RC4 dismissal at the first available firmware update
• Update firmware on non-Windows devices. Contact NAS, printer, and appliance vendors to verify the availability of firmware introducing AES-SHA1 support. In most cases, leading manufacturers (Synology DSM 6.2+, QNAP QTS 4.3+, NetApp ONTAP 9.x) offer compatible versions
• Replace legacy devices that cannot be updated. For End-of-Life hardware that will not receive updates, replacement is the only sustainable path. Microsoft has activated a dedicated address, stillneedrc4@microsoft.com, to report specific cases of third-party devices without AES support

Phase 4 — Anticipating the enforcement

Once remediations are complete and no relevant audit events have been observed for at least two weeks, it is possible to anticipate enforcement manually without waiting for April 2026. The operation is performed by setting the following registry key on each Domain Controller and rebooting the machine:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Value: RC4DefaultDisablementPhase
Type:  REG_DWORD
Data:  2

The advantage of this approach is the ability to observe the consequences of enforcement in a controlled way, while preserving the rollback option by setting the value back to 1 (audit) and rebooting. After July 2026 this key is ignored and no longer provides any mitigation mechanism.

Group Policy workaround: Configure encryption types allowed for Kerberos

When acting on a single AD attribute is not sufficient — typically in environments with a heterogeneous fleet, or when applying a uniform encryption profile to an entire Organizational Unit — a dedicated Group Policy can be used. The GPO acts at the operating system level, influencing both clients and ticket requests toward the KDC.

The reference policy is located at the following path in the Group Policy Management Console:

Computer Configuration > Policies > Windows Settings > Security Settings >
Local Policies > Security Options >
Network security: Configure encryption types allowed for Kerberos

Two typical configurations apply. For an AES-only profile, intended for machines and OUs with fully modern components, only AES128_HMAC_SHA1 and AES256_HMAC_SHA1 are selected. For a transitional profile, preserving compatibility with legacy devices during the remediation phase, RC4_HMAC_MD5 is added to the two AES options.

A crucial aspect is the scoping of the GPO. Applying an AES-only policy indiscriminately to the entire domain can produce cascading impacts that are difficult to diagnose. The recommendation is to:

• Segregate the computer accounts of NAS units and legacy devices in a dedicated OU, applying a GPO that keeps RC4 among the allowed ciphers until the remediation plan is complete
• Apply the AES-only GPO as the default policy on modern servers and workstations, after first verifying its effectiveness on a limited pilot
• Actively monitor logs after application through the PowerShell scripts mentioned earlier, to catch authentication failures early

Domain Controller workaround: DefaultDomainSupportedEncTypes

When the heterogeneity of the environment prevents single-account configuration and the GPO risks being too invasive, it is possible to act on the KDC default value through the DefaultDomainSupportedEncTypes registry key under HKLM\SYSTEM\CurrentControlSet\services\KDC on each Domain Controller.

Setting this key to 0x1C (RC4 + AES128 + AES256) forces the KDC to assume RC4 support for every account without an explicit attribute, effectively neutralizing the default change introduced with the April 2026 update. This is a configuration to be used with extreme caution, since it globally reintroduces the Kerberoasting risk and should be considered only as a stopgap measure for limited time windows. It must also be noted that, once the July 2026 updates are installed, this configuration too will be progressively marginalized: event 205 in the System Log will continue to flag the configuration as insecure, and future updates may remove its recognition altogether.

Selective approach: per-account configuration

The most surgical and by far the preferable alternative consists of explicitly populating the msDS-SupportedEncryptionTypes attribute only on the accounts that actually need it. For a computer account representing an RC4-only NAS, the command is the following:

Set-ADComputer -Identity "NAS01" -Replace @{"msDS-SupportedEncryptionTypes"=28}

This approach is preferable because it isolates the risk at the single device, preserves the overall security posture of the domain, and allows precise traceability of the accounts that have received special treatment. It is good practice to document each exception in an internal register, recording the device, the technical justification, and the planned date for the exception to be retired.

Conclusions

The deprecation of RC4 in Kerberos represents a structural change to the Active Directory authentication protocol. Unlike other hardening releases, it does not merely modify default behaviors: it progressively removes the very ability to operate in insecure mode, culminating in July 2026 with the elimination of rollback mechanisms. Preparatory action is not optional, and the cost of inaction is paid in production authentication failures, often on services and devices whose original design rationale has long been forgotten.

The winning strategy is to fully exploit the audit window opened in January 2026, identify residual dependencies through the official Microsoft tools, remediate in order of priority, and anticipate enforcement on the segments of the environment that allow it. The case of NAS units and non-Windows domain-joined devices deserves particular attention: the combination of uncertain AES support and frequently unset AD attributes can turn an ordinary update into a production incident. Explicitly populating the msDS-SupportedEncryptionTypes attribute, together with a properly scoped GPO, is the most robust operational combination for crossing this transition without service interruption.

#DBS