RC4 Deprecation in Active Directory: Timeline and Phases

Context

RC4-HMAC (RC4-HMAC-MD5) has been the default Kerberos encryption type in Windows since 2000. For decades it provided backward compatibility in heterogeneous environments, but it has also been central to some of the most widespread Active Directory attack techniques: Kerberoasting, AS-REP Roasting, and several pass-the-hash variants that exploit the cryptographic weakness of the RC4 stream cipher.

Microsoft began strengthening Kerberos in 2022 with KB5021131. For CVE-2026-20833, KB 5073381 defines a separate three-phase rollout from January through July 2026. This is not a single switch that makes RC4 impossible in every configuration: the default changes for accounts without explicit encryption settings, while explicit settings must be reviewed separately.

This RC4 guide for Active Directory and Kerberos explains how to migrate from RC4 to AES with minimal outage risk across enterprise services, NAS platforms, Linux systems, and SSO integrations.

Index

• When does Microsoft disable RC4 in Active Directory?
• RC4DefaultDisablementPhase: what is it and which values does it support?
• RC4 deprecation FAQ
  • Is RC4 deprecated?
  • What does the July 2026 phase mean?
  • Can RC4 changes affect MSOL_* or AZUREADSSOACC$?
• Why RC4 is a real problem, not just theory
• Phase 1: identify remaining RC4 usage
• Phase 2: remediate account encryption settings
• Phase 3: configure Group Policy
• Most common problematic cases
  • 1. Java applications using JGSS/JAAS
  • 2. SQL Server with Kerberos authentication and SPN
  • 3. Cross-forest trust
  • 4. Linux domain-joined servers
  • 5. Special accounts: MSOL_* and AZUREADSSOACC$
  • 6. Kemp LoadMaster and Kerberos Constrained Delegation (KCD)
  • 7. VMware vSphere and vCenter Server
  • 8. IBM systems (AIX, WebSphere, Cognos)
  • 9. Synology, QNAP, and NetApp NAS
    • 9.1 NetApp ONTAP focus and RC4 retirement
  • 10. MFP scanners, printers, and embedded appliances
  • 11. Linux with static keytabs and application services
• Operational path after the 2026 updates
• Final validation
• Final notes

When does Microsoft disable RC4 in Active Directory?

Short answer: the default change entered its enforcement phase with updates released on April 14, 2026; July updates removed the temporary rollback mechanism. This does not mean RC4 is prohibited for every explicitly configured account.

DC update date	Phase	What changes	What to do
January 13, 2026	Initial deployment	Adds KDCSVC audit events 201-209 and the temporary RC4DefaultDisablementPhase value.	Update DCs and monitor the System log; remediate findings before enabling enforcement.
April 14, 2026	Enforcement with manual rollback	For accounts without explicit msDS-SupportedEncryptionTypes, the KDC default becomes AES-SHA1 (DefaultDomainSupportedEncTypes = 0x18). The temporary value still allows rollback to Audit mode.	Review events, AES keys, and interoperability; handle explicit account or domain settings separately.
July 2026	Programmatic enforcement	Updates released in July remove support for RC4DefaultDisablementPhase and enable enforcement programmatically.	The value is no longer a rollback option on updated DCs; remediate dependencies and validate services.

These are update release dates, not calendar deadlines that apply without patches: check the installed cumulative update on every domain controller. Microsoft recommends enabling enforcement after reviewing KDCSVC events and mitigating dependencies. See Microsoft KB 5073381: RC4 Kerberos ticket issuance changes for the current details.

RC4DefaultDisablementPhase: what is it and which values does it support?

RC4DefaultDisablementPhase is a temporary value that controls the KDC transition. It was introduced with updates released on or after January 13, 2026; updates released in July 2026 remove support for it.

Registry path on a domain controller:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
Value: RC4DefaultDisablementPhase
Type: REG_DWORD

DWORD value	Documented behavior
0	No audit, no change.
1	Logs warning events for default RC4 usage. Initial deployment phase default.
2	KDC starts assuming RC4 is not enabled by default. Enforcement behavior.

Microsoft marks a restart as required. Set this only when KDCSVC audit events show it is safe, and plan a controlled restart one domain controller at a time. With value 2, the KDC assumes RC4 is not enabled by default for accounts without explicit msDS-SupportedEncryptionTypes; it does not override explicit account configuration.

PowerShell example, valid only on DCs updated during the period when this value is supported and after audit triage:

# Run on the approved test DC; schedule the required restart
$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"
Set-ItemProperty -Path $regPath -Name "RC4DefaultDisablementPhase" -Value 2 -Type DWord
Get-ItemProperty -Path $regPath -Name "RC4DefaultDisablementPhase"

If you need to return to Audit mode before the July 2026 updates, set value 1 and restart the DC according to the change plan. On July 2026 updates or later, this temporary value is no longer read and cannot be used for rollback.

RC4 deprecation FAQ

Is RC4 deprecated?

Yes: Microsoft's 2026 rollout removes its default use for accounts without explicit encryption settings. It is not a universal ban, however: review explicit msDS-SupportedEncryptionTypes and DefaultDomainSupportedEncTypes settings separately; they can retain RC4 and therefore preserve CVE-2026-20833 risk.

What does the July 2026 phase mean?

Updates released from July remove the temporary RC4DefaultDisablementPhase value and enable enforcement programmatically. This does not mean every explicit RC4 configuration is ignored.

Can RC4 changes affect MSOL_* or AZUREADSSOACC$?

They can expose encryption dependencies or missing AES keys. Check msDS-SupportedEncryptionTypes, KDCSVC events, and the keys actually available; for Entra Connect and Seamless SSO, follow the dedicated section below rather than applying a value indiscriminately.

---

Why RC4 is a real problem, not just theory

Kerberoasting: an attacker with authenticated domain access can request a service ticket (TGS) for any registered SPN. If negotiated encryption is RC4-HMAC, the ticket can be brute-forced offline with tools such as Hashcat. With AES256, computational cost increases by orders of magnitude.

AS-REP Roasting: for accounts with Do not require Kerberos preauthentication enabled, an attacker can request AS-REP without prior authentication. If encryption type is RC4, response material is offline-crackable.

Downgrade attack: without KDC-side enforcement, a client can force RC4 negotiation even in AES-capable environments, reducing security level of the entire Kerberos session.

---

Phase 1: identify remaining RC4 usage

Before disabling anything, you need to know what still uses RC4 in your environment. Domain Controllers log Kerberos encryption types, and encryption type 0x17 maps exactly to RC4-HMAC.

Event ID 4768 (Kerberos Authentication Service Request - TGT) and Event ID 4769 (Kerberos Service Ticket Request - TGS) both include Ticket Encryption Type. Filtering for 0x17 on all DCs over 2-4 weeks gives a reliable map of residual RC4 usage.

# Collect Event ID 4769 entries with RC4 (0x17) from the last 30 days across all DCs
$startDate = (Get-Date).AddDays(-30)
$dcs = (Get-ADDomainController -Filter *).Name

foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{
        LogName   = "Security"
        Id        = 4769
        StartTime = $startDate
    } -ErrorAction SilentlyContinue |
    Where-Object {
        $_.Properties[6].Value -eq "0x17"
    } |
    Select-Object TimeCreated,
        @{ N="ServiceName";  E={ $_.Properties[0].Value } },
        @{ N="ClientName";   E={ $_.Properties[3].Value } },
        @{ N="EncryptType";  E={ $_.Properties[6].Value } },
        @{ N="DC";           E={ $dc } }
} | Sort-Object TimeCreated -Descending | Export-Csv rc4-usage.csv -NoTypeInformation -Encoding UTF8

From the resulting CSV, look for these patterns:

• Service accounts with SPNs (high-priority Kerberoasting candidates)
• Computer accounts where msDS-SupportedEncryptionTypes is 0 or missing
• Legacy applications/systems (printers, scanners, NAS, ERP, middleware) that appear repeatedly as ClientName

---

Phase 2: remediate account encryption settings

The msDS-SupportedEncryptionTypes attribute controls which algorithms an account can negotiate. The value is a bitmask:

Value	Meaning
0	No explicit value - KDC uses domain defaults (historically including RC4)
4	DES-CBC-MD5 only (never use)
8	RC4-HMAC only (must be removed)
16	AES128-CTS-HMAC-SHA1-96
24	AES128 + AES256
28	AES128 + AES256 + RC4 (temporary transition value)
31	DES-CBC-CRC + DES-CBC-MD5 + RC4 + AES128 + AES256 (common in obsolete environments)

For user and service accounts, final target value is 24 (AES only). During transition, 28 can avoid breaking RC4-only applications.

# Set msDS-SupportedEncryptionTypes to AES128+AES256 for all service accounts in an OU
$ouPath = "OU=ServiceAccounts,DC=contoso,DC=com"
Get-ADUser -SearchBase $ouPath -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.msDS-SupportedEncryptionTypes -ne 24 } |
    ForEach-Object {
        Set-ADUser $_ -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }
        Write-Output "Updated: $($_.SamAccountName)"
    }

For computer accounts (workstations and member servers):

# Check computers without AES enabled
Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object {
        $_.msDS-SupportedEncryptionTypes -eq $null -or
        $_.msDS-SupportedEncryptionTypes -lt 16
    } |
    Select-Object Name, msDS-SupportedEncryptionTypes |
    Export-Csv computers-no-aes.csv -NoTypeInformation -Encoding UTF8

Computer accounts in Active Directory can update msDS-SupportedEncryptionTypes automatically when netlogon runs (for example after reboot or machine password change, default every 30 days). However, this is not always immediate or fully predictable: value changes over time based on OS version, machine state, key refresh process, and even service startup identities.

Setting msDS-SupportedEncryptionTypes manually in AD before client reconnect is a good practice. It increases the probability that at next Kerberos negotiation, Domain Controller will issue AES-only behavior instead of RC4. This is especially useful during hardening and RC4 retirement.

Keep in mind the value may later be overwritten by the client. For this reason, monitor computer accounts over time: if msDS-SupportedEncryptionTypes returns to undesired algorithms or resets, analyze system behavior (OS version, domain join mode, provisioning/management tools) and apply targeted remediation.

Typical actions include coherent policy rollout, legacy system updates, and controlled computer account lifecycle management to keep AES-only posture stable.

---

Phase 3: configure Group Policy

The GPO Network security: Configure encryption types allowed for Kerberos (path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options) controls which algorithms client and server accept during Kerberos negotiation.

Recommended configuration for Domain Controllers during transition:

• AES128_HMAC_SHA1 enabled
• AES256_HMAC_SHA1 enabled
• Future encryption types enabled
• RC4_HMAC_MD5 disable only after account verification is complete

Recommended configuration for member workstations/servers:

Same settings as DCs, rolled out progressively by OU, starting from non-critical systems.

Warning: do not disable RC4 in GPO before fixing msDS-SupportedEncryptionTypes on all accounts. Correct order is: account settings -> DC GPO -> workstation/member server GPO.

---

Most common problematic cases

In most Active Directory environments, the real blocker for RC4 retirement is not Windows users or servers, but years of Kerberos integrations that were never revisited: Linux appliances, NAS devices, load balancers, VMware platforms, IBM systems, Java middleware, embedded devices, and third-party applications. Identifying them during assessment is often what makes or breaks a Kerberos hardening program.

1. Java applications using JGSS/JAAS

Many Java applications use Kerberos libraries that still prioritize RC4 in krb5.conf. After enforcement, they start returning KrbException: KDC has no support for encryption type. Fix by updating application krb5.conf:

[libdefaults]
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

2. SQL Server with Kerberos authentication and SPN

If SQL Server service account does not have AES enabled in msDS-SupportedEncryptionTypes, Kerberos connections silently fall back to NTLM. It is often invisible operationally but is a security regression. Verify with:

SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID

If result is not KERBEROS, issue is account/SPN related.

3. Cross-forest trust

Active Directory trusts across forests use trust accounts with their own encryption configuration. If remote forest is at lower functional/patch level, trust may keep using RC4 even after local enforcement. Verify:

Get-ADTrust -Filter * | Select-Object Name, TrustAttributes, TrustDirection

Trusts with UsesRC4Encryption flag require coordinated remediation on both forests.

4. Linux domain-joined servers

Linux servers joined via SSSD or Winbind/Samba handle Kerberos through local /etc/krb5.conf, independent from Windows GPO. After RC4 enforcement, Linux authentications may fail with errors like KDC has no support for encryption type or GSSAPI Error: Unspecified GSS failure, often with little DC-side visibility.

This is a dual problem:

1. Computer account in AD must have AES enabled in msDS-SupportedEncryptionTypes (24 or 28)
2. Linux /etc/krb5.conf must list AES as allowed encryption

For krb5.conf:

[libdefaults]
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

After changing msDS-SupportedEncryptionTypes on AD computer object, Linux keytab must be regenerated, otherwise keytab KVNO (Key Version Number) may mismatch AD and authentication still fails even with correct algorithm.

With SSSD and adcli:

# Regenerate keytab with updated AES keys on computer account
adcli update --computer-name=$(hostname -s) --verbose

# Validate resulting keytab
klist -ket /etc/krb5.keytab

With Winbind/Samba:

net ads keytab create -U Administrator
net ads keytab list

Final validation: run kinit with local service account and verify ticket encryption type is AES256 (etype: aes256-cts-hmac-sha1-96) and not RC4 (etype: arcfour-hmac).

5. Special accounts: MSOL_* and AZUREADSSOACC$

These two accounts are created automatically by Microsoft Entra Connect (formerly Azure AD Connect) and often remain outside normal service account inventories, so teams usually notice them only when authentication starts failing after RC4 enforcement.

MSOL_xxxxxxxxxxxxxxxx

This account is used by Entra Connect to connect to on-prem AD and execute synchronization operations (read objects, write attributes, password operations). It is created in CN=Users,DC=contoso,DC=com during AD connector setup, with a name in format MSOL_ + random hex string.

Because it is not in normal managed OUs, msDS-SupportedEncryptionTypes is often missing or set to 0. After enforcement, sync process starts seeing silent Kerberos failures and synchronization degrades or stalls.

Find it with:

Get-ADUser -Filter { SamAccountName -like "MSOL_*" } -Properties msDS-SupportedEncryptionTypes, PasswordNeverExpires, Description |
    Select-Object SamAccountName, msDS-SupportedEncryptionTypes, PasswordNeverExpires, Description

Remediation:

$msolAccount = Get-ADUser -Filter { SamAccountName -like "MSOL_*" }
Set-ADUser $msolAccount -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }

Operational test: after change, set new password in connector properties under Connect to Active Directory Forest, run full sync cycle from Entra Connect, and verify there are no AD connectivity errors in Synchronization Service Manager > Operations:

# Run on Entra Connect server
Start-ADSyncSyncCycle -PolicyType Initial

If sync completes with no AD connectivity errors, remediation succeeded.

AZUREADSSOACC$

Unlike MSOL_*, this is a computer account (not a user), created by Entra Connect when Seamless SSO is enabled. It typically resides in CN=Computers,DC=contoso,DC=com and is used to decrypt Kerberos tickets issued during Seamless SSO flow.

Because it is a computer account that never renews like a normal workstation (it does not run netlogon), msDS-SupportedEncryptionTypes remains at default and is not refreshed. After RC4 enforcement, Kerberos ticket decryption for SSO fails silently and users start seeing credential prompts in browsers/clients where authentication used to be transparent.

Remediation requires changes both on AD object and Entra Connect side, where Kerberos keys are regenerated:

# Step 1: update msDS-SupportedEncryptionTypes on the computer object
$ssoAccount = Get-ADComputer -Identity "AZUREADSSOACC"
Set-ADComputer $ssoAccount -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }

Step 2: from Entra Connect, renew Kerberos secret for the SSO account. Open PowerShell on Entra Connect server with AzureADSSO module:

Import-Module "$env:ProgramFiles\Microsoft Azure Active Directory Connect\AzureADSSO.psd1"
New-AzureADSSOAuthenticationContext  # Global Admin authentication
Update-AzureADSSOForest -OnPremCredentials (Get-Credential)  # Domain Admin credentials

Functional test: from a browser on a domain-joined machine (without MFA on test account), open https://myapps.microsoft.com. If authentication completes with no credential prompt, Seamless SSO works. Alternatively, verify in Entra ID Sign-ins that authentication method is Seamless SSO and not Password Hash Sync or Password.

Deprecation note: Microsoft is progressively moving focus from Seamless SSO to Primary Refresh Token (PRT), which provides SSO through Entra ID-joined or Hybrid Entra ID-joined devices without requiring a dedicated Kerberos account in the domain. Even if Seamless SSO is still supported in existing environments, it is no longer the primary reference solution for new scenarios. In existing environments, plan migration toward Hybrid Join or Entra ID Join instead of long-term investment on AZUREADSSOACC$ maintenance. This method does not create that computer account because Kerberos is not used in that authentication stage.

6. Kemp LoadMaster and Kerberos Constrained Delegation (KCD)

Kemp LoadMaster deployments using KCD are among the most deceptive scenarios during RC4 retirement. Front-end access can appear healthy while back-end delegation still negotiates legacy crypto if delegation accounts, SPNs, or key material are not aligned to AES.

Minimum checklist:

• verify HTTP and backend SPNs associated with delegation identities
• verify delegated accounts are not RC4-only (msDS-SupportedEncryptionTypes = 8)
• run end-to-end delegation tests after moving to 24 (AES only)

7. VMware vSphere and vCenter Server

In vSphere environments, the common issue is mixed maturity: updated core components with legacy SSO/LDAP integrations still tied to historical Kerberos settings. After RC4 enforcement, symptoms often surface in admin logons, plugins, or automation workflows.

Practical checks:

• validate vCenter/PSC version and Kerberos AES compatibility
• validate AD connector keytab or stored credentials
• retest AD login and authorization workflows after remediation

8. IBM systems (AIX, WebSphere, Cognos)

IBM stacks in large enterprises often preserve long-lived Kerberos configurations. Remediation usually requires keytab/principal/application config review, not only AD-side attribute updates.

Common findings:

• legacy keytabs generated in RC4-first years
• service principals no longer aligned with current AD identity
• application Kerberos files still allowing legacy etypes

9. Synology, QNAP, and NetApp NAS

NAS devices are a frequent source of residual RC4 traffic because they remain in service for long periods with stable AD join but stale Kerberos configuration.

Recommended checks:

• validate AD join health and NAS computer account
• validate firmware/OS support for AES Kerberos
• confirm SMB access uses Kerberos AES and not NTLM fallback

9.1 NetApp ONTAP focus and RC4 retirement

Per official NetApp KB guidance, impact depends on ONTAP release, CIFS Kerberos configuration, and how the CIFS server was originally created and maintained. Older or long-lived configurations may require explicit AES alignment before Microsoft enforcement phases.

Official references:

• https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/What_is_the_impact_to_ONTAP_CIFS_SMB_when_Microsoft_disables_RC4_for_Kerberos
• https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/ONTAP_Guidance_for_Microsoft_Security_Update_KB5073381_CVE_2026_20833
• https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/ONTAP_Requirements_for_CIFS_Kerberos

Operational ONTAP checklist:

• verify ONTAP release and CIFS Kerberos prerequisites documented by NetApp
• verify CIFS computer account in AD has AES-aligned encryption settings
• validate SMB authentication from domain-joined clients after changes
• if failures appear, follow NetApp KB remediation (rejoin/credential refresh/Kerberos config update)

AD-side NAS account check:

Get-ADComputer NAS01 -Properties msDS-SupportedEncryptionTypes,KerberosEncryptionType |
Select-Object Name,msDS-SupportedEncryptionTypes,KerberosEncryptionType

10. MFP scanners, printers, and embedded appliances

Many RC4 remediation programs stall on devices considered peripheral. In practice, MFP scanners, enterprise printers, and OT appliances often run older Kerberos/SMB stacks and become early fallback/failure points.

Pragmatic approach:

• identify devices authenticating against AD-backed shares
• classify supported vs unsupported firmware
• keep temporary exceptions only with explicit owner and removal timeline

11. Linux with static keytabs and application services

Even with AES-ready AD computer objects, Linux hosts can continue to fail or negotiate legacy behavior if local keytabs and Kerberos config were never regenerated after remediation.

Recommended practice:

• update krb5.conf etypes
• regenerate keytab
• validate kinit/klist and verify AES etype

---

Operational path after the 2026 updates

The January, April, and July 2026 dates are past milestones. To verify the current state, use this sequence across all domain controllers and the services that rely on them:

1. Inventory DC patch levels. Confirm that every DC has current cumulative updates; the calendar date alone does not enable protection on an unpatched DC.
2. Review KDCSVC events 201-209 in the System log and Security events 4768/4769. Event 205 flags an insecure explicit DefaultDomainSupportedEncTypes configuration; events 201-209 identify requests or policy conditions to investigate using Microsoft's event descriptions.
3. Classify accounts and dependencies. Find accounts without msDS-SupportedEncryptionTypes, accounts without AES keys, and clients/keytabs that do not negotiate AES-SHA1. Include MSOL_*, AZUREADSSOACC$, trusts, NAS, and non-Windows services.
4. Remediate and test real tickets. Configure AES only after verifying AES keys are available; test applications and relevant keytabs. If RC4 is essential, document the explicit exception, scope, owner, and removal plan; do not treat it as secure remediation.
5. Validate after each rollout. Compare events before and after, and verify ticket encryption types. On July 2026 updates or later, RC4DefaultDisablementPhase is no longer a rollback mechanism; agree on service-specific recovery procedures in advance.

The goal is to remove unintended RC4 usage and insecure implicit configurations. Do not use “zero Event 4769 RC4” as a target without separating approved explicit RC4 exceptions from fallbacks or dependencies that must be fixed.

---

Final validation

Two queries to verify completeness.

No account with RC4 enabled as sole algorithm:

Get-ADObject -Filter {
    (ObjectClass -eq "user" -or ObjectClass -eq "computer") -and
    msDS-SupportedEncryptionTypes -eq 8
} -Properties SamAccountName, msDS-SupportedEncryptionTypes |
Select-Object SamAccountName, msDS-SupportedEncryptionTypes

Residual RC4 monitoring over the last 7 days:

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4769
    StartTime = (Get-Date).AddDays(-7)
} |
Where-Object { $_.Properties[6].Value -eq "0x17" } |
Measure-Object | Select-Object Count

Expected result is Count: 0. If there are still hits, ClientName in the event identifies the exact source.

---

Final notes

RC4 retirement is one of those hardening operations that has real impact on environment security posture, but it requires precise phased management to avoid service interruptions. The main risk is not technical but operational: skipping assessment and applying GPO before fixing account settings leads to authentication failures that are hard to trace, especially on legacy applications that do not clearly log Kerberos algorithm behavior.

If you are starting this journey or are blocked midway through enforcement due to unexpected incidents, contact me: often a few hours of focused log analysis is enough to unblock situations that appear much more complex than they are.