← Field Guides
Active DirectoryEncryptionEntra IDHardeningKerberosLinuxLoad BalancerNetApp ONTAPNTLMSPNvSphere

RC4 Deprecation in Active Directory: from Audit Phase to Full Enforcement

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 started the formal deprecation path in November 2022 with KB5021131, introducing audit events to trace RC4 usage in Kerberos. From that point onward, each major update tightened behavior further, up to the enforcement phases across the January-July 2026 window.

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

Full timeline

Date KB / Update What changes
November 2022 KB5021131 Adds audit events (Event ID 14, 16, 27 on KDC) for RC4 usage in Kerberos AS Exchange
July 2023 KB5028166 RC4 disabled by default for AS Exchange; RC4 requests begin to fail when KDC supports AES
October 2024 Cumulative Update DefaultDomainSupportedEncTypes behavior updated; new domains no longer include RC4 by default
January 2026 Enforcement Phase 1 (Audit-only) RC4 removed from default negotiable KDC set for new TGT flows; new audit events introduced. Optional: set RC4DefaultDisablementPhase = 2 to test stricter behavior before April
April 2026 Enforcement Phase 2 (Default) Enforcement on by default; DefaultDomainSupportedEncTypes = 0x18 (AES-SHA1 only). Environments without proper AES support start seeing authentication failures
July 2026 Enforcement Phase 3 (Full) Full and permanent enforcement. RC4DefaultDisablementPhase is ignored. RC4-HMAC is no longer offered or accepted by updated KDCs

The key point is that January was not just a default change. It introduced active reject behavior for accounts whose msDS-SupportedEncryptionTypes attribute was missing or configured without AES.

Early strict-mode validation: RC4DefaultDisablementPhase

During Phase 1 (January 2026), Microsoft provides a mechanism to test stricter behavior ahead of April. This allows remediation validation before enforcement becomes operational.

Configuration to test stricter behavior (January-March 2026):

On each Domain Controller, create this registry value:

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

Apply with PowerShell:

# Run as domain admin on each DC
$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"
Set-ItemProperty -Path $regPath -Name "RC4DefaultDisablementPhase" -Value 2 -Type DWord

# Verify
Get-ItemProperty -Path $regPath -Name "RC4DefaultDisablementPhase"

# No reboot required; KDC rereads the value after a few seconds

With RC4DefaultDisablementPhase = 2, KDC behavior changes immediately, rejecting RC4 for accounts without explicit msDS-SupportedEncryptionTypes configuration. This allows you to test April behavior in a controlled environment.

Note: This key is meant for testing, not for permanently bypassing enforcement. Starting in July 2026, RC4DefaultDisablementPhase is ignored and strict behavior is mandatory.

Remove the test key (after validation is complete):

When validation is complete and you are confident all accounts are properly configured:

# Run as domain admin on each DC
$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"
Remove-ItemProperty -Path $regPath -Name "RC4DefaultDisablementPhase" -ErrorAction SilentlyContinue

Note: environments that have not yet installed January 2026 cumulative updates are not subject to automatic enforcement, but they remain exposed to RC4-related weaknesses described below.

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:

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 from January to July

In a seven-month hardening program, work distribution is typically:

January - Assessment and baseline

  • Deploy Event ID 4768/4769 collection on all DCs
  • Export RC4 profile CSV for the environment
  • Classify accounts by priority (service accounts with SPN > computer accounts > regular users)

February-March - Account remediation

  • Update msDS-SupportedEncryptionTypes for service account OUs
  • Regression tests on critical applications (SQL, Java, scanners)
  • Handle identified problematic cases
  • Start legacy system migration where possible (for example Windows Server 2003)

April-May - Enforcement operations

  • Phase 2 enforcement becomes active: DefaultDomainSupportedEncTypes = 0x18 (AES-SHA1 only) for accounts without explicit configuration
  • Continue AES-only GPO rollout on member servers by OU (starting from non-production)
  • Critical: by this stage, all critical accounts should already be migrated to AES. Remaining RC4-only accounts will cause authentication failures
  • Intensive log monitoring; Event ID 4769 with RC4 encryption type becomes a critical signal for non-migrated accounts
  • If an account is discovered as RC4-only: immediate remediation mandatory (password reset, set msDS-SupportedEncryptionTypes = 24)

June - Workstation completion and legacy cleanup

  • Extend GPO to workstations
  • Clean up cross-forest trust issues if present
  • Document temporarily excluded accounts (formal exceptions)

July - Validation and closure

  • Zero Event ID 4769 with encryption type 0x17 for 2 consecutive weeks
  • Review accounts with msDS-SupportedEncryptionTypes = 28 (transition state) and migrate to 24
  • Update onboarding runbook (new accounts must be created AES-ready)
  • Formal sign-off

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.

Appreciation

If this guide is useful, leave a like.

LinkedIn