Kerberos RC4 Removal: Find and Fix RC4 Accounts (2026)

Short answer: Under KB5073381 (CVE-2026-20833), Windows domain controllers stopped assuming RC4 for accounts without an explicit encryption setting: audit started with the January 13, 2026 updates, enforcement became the default on April 14, 2026, and the July 2026 updates removed the RC4DefaultDisablementPhase rollback. To find what still uses RC4, look for KDCSVC events 201-209 in the DCs’ System log and Security event 4769 with ticket encryption type 0x17, then give service accounts AES keys (password reset) and an explicit msDS-SupportedEncryptionTypes. Allow RC4 only per account, for devices that truly cannot do AES.

Applies to Domain controllers with KB5073381 updates; tested on Windows Server 2025 DC and Windows 11 Pro

We ran these commands on 6 October 2026 on a Windows Server 2025 Standard domain controller (build 26100.33438, September 2026 update, Windows PowerShell 5.1) and a Windows 11 Pro member PC in our lab domain contoso.com. Where the lab result differed from the documentation, the page says so.

What changed in 2026: the RC4 timeline

RC4-encrypted service tickets are what makes Kerberoasting cheap: an attacker requests a ticket for a service account and cracks it offline. Microsoft had already made AES the default for accounts without a setting in November 2022 (KB5021131), but DCs still issued RC4 tickets by default when the service account had no msDS-SupportedEncryptionTypes value and RC4 was what the client asked for or all the account had. KB5073381 closes that gap in three phases:

Date	Phase	What happens on DCs
January 13, 2026	Initial deployment (audit)	KDCSVC warning events 201, 202, 205, 206, 207 logged in the System log. New registry value RC4DefaultDisablementPhase: 1 = warn (default), 2 = enforce early.
April 14, 2026	Enforcement with manual rollback	Default DefaultDomainSupportedEncTypes becomes AES-SHA1 only (0x18) for accounts without an explicit setting. Blocked requests log error events 203, 204, 208, 209. You could still set the phase value back to 1.
July 2026	Enforcement	The RC4DefaultDisablementPhase value is no longer read. No rollback; only explicit per-account or domain-wide settings re-enable RC4.

As of October 2026, any DC with July 2026 or later updates is in enforcement. Two related facts are worth knowing:

• Explicit settings are still honoured. If a service account has msDS-SupportedEncryptionTypes that includes RC4, or a DC has DefaultDomainSupportedEncTypes set in the registry, the KDC follows it. Event 205 is logged at KDC start if that domain-wide value includes anything other than AES-SHA1; it never becomes an error.
• Windows Server 2025 domain controllers do not issue RC4 ticket-granting tickets at all, regardless of these settings, according to Microsoft’s RC4 detection article.

The registry value lived at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters (REG_DWORD, restart required). If your change notes still mention it as a fallback, update them: it no longer does anything after the July updates.

Step 1: read the KDCSVC events on every DC

These events name the account, the service and the client IP, so they are the fastest way to a fix list. Run from an admin workstation with RSAT:

$dcs = (Get-ADDomainController -Filter *).HostName
foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{
        LogName      = 'System'
        ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
        Id           = 201..209
        StartTime    = (Get-Date).AddDays(-7)
    } -ErrorAction SilentlyContinue |
    Select-Object @{n='DC';e={$dc}}, TimeCreated, Id, LevelDisplayName,
                  @{n='Detail';e={($_.Message -split "`n")[0]}}
}

Use the full provider name. Event Viewer shows the source as “Kdcsvc”, but -ProviderName 'Kdcsvc' fails on Windows Server 2025 with “There is not an event provider … that matches Kdcsvc” (and combined with -ComputerName only with “The parameter is incorrect”). On our lab DC with the September 2026 update the provider defines events 201 to 205 in the System log; 206 to 209 were not in its manifest yet. A clean lab returned no events, which is the expected result.

What each pair means (warning before enforcement / error after):

Events	Cause	Usual fix
201 / 203	The client only offers RC4, and the service has no msDS-SupportedEncryptionTypes	Fix or replace the client (old OS, appliance, Java/MIT Kerberos config)
202 / 204	The service account has no AES keys and no msDS-SupportedEncryptionTypes	Reset the service account password, then set AES explicitly
206 / 208	The service is set to AES only, but the client only offers RC4	Fix the client; or allow RC4 on that one service account
207 / 209	The service is set to AES only, but has no AES keys	Reset the service account password
205	The DC has an explicit DefaultDomainSupportedEncTypes that includes RC4 or DES	Review; remove or tighten once nothing depends on it

Microsoft’s own note: the absence of KDCSVC events does not prove every non-Windows device will accept AES tickets. Keytab-based Linux and appliance services can fail on the service side, not at the KDC.

Step 2: find RC4 tickets in Security event 4769

Event 4769 (a Kerberos service ticket was requested) records the encryption type of every service ticket the DC issues. RC4 shows as 0x17 in TicketEncryptionType. The DCs must audit Kerberos Service Ticket Operations (success) for this event to exist; see our Active Directory audit policy guide.

$xpath = "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]"
$rows = foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    Get-WinEvent -ComputerName $dc -LogName Security -FilterXPath $xpath -MaxEvents 500 -ErrorAction SilentlyContinue |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        [pscustomobject]@{
            DC        = $dc
            Time      = $_.TimeCreated
            Client    = $d['TargetUserName']
            Service   = $d['ServiceName']
            ClientIP  = $d['IpAddress']
            Advertised = $d['ClientAdvertizedEncryptionTypes']
        }
    }
}
$rows | Sort-Object Service | Export-Csv .\rc4-tickets.csv -NoTypeInformation

To see a positive result we set a test service account to RC4 only (0x4) and requested a ticket for its SPN from a member PC. The DC issued an RC4 ticket (klist showed RSADSI RC4-HMAC(NT)) and logged event 4769 with TicketEncryptionType 0x17, which this query found. Our Kerberos RC4 audit script does the same across all DCs.

Group the CSV by Service and ClientIP: each line is one dependency to fix. The newer 4769 fields (ServiceAvailableKeys, ClientAdvertizedEncryptionTypes) tell you whether the problem is the account (no AES keys) or the client (only offers RC4). Microsoft added these fields to Windows Server 2019 and later, and to Server 2016 with the January 2025 update.

If you prefer a ready tool, Microsoft publishes Get-KerbEncryptionUsage.ps1 (run with -Encryption RC4) and List-AccountKeys.ps1 in its Kerberos-Crypto GitHub repository; both read the same events.

Step 3: audit service accounts and their encryption settings

Service tickets are issued for accounts that have a service principal name (SPN). List user accounts with SPNs, their configured encryption types and when their password was last set:

Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet,
        @{n='EncTypes';e={ if ($null -eq $_.'msDS-SupportedEncryptionTypes') { 'not set' } else { '0x{0:X}' -f $_.'msDS-SupportedEncryptionTypes' } }},
        @{n='SPNs';e={ $_.ServicePrincipalName -join '; ' }} |
    Sort-Object PasswordLastSet | Format-Table -AutoSize

How to read msDS-SupportedEncryptionTypes (hex):

Value	Meaning
not set (0)	KDC uses the domain default; after enforcement that is AES-SHA1 only
0x4	RC4 only: will break or stay weak
0x18 (24)	AES128 + AES256: the target for most accounts
0x1C (28)	RC4 + AES128 + AES256
0x24 (36)	RC4 tickets with AES session keys: Microsoft’s suggested exception value for a service that cannot accept AES tickets

Accounts with very old PasswordLastSet dates are the usual suspects for missing AES keys. Microsoft’s rule: an account whose password was never changed since AES support arrived has no AES keys, and changing the password creates them.

Step 4: fix accounts, clients and keytabs

Service account has no AES keys

Resetting a service account password breaks every service, scheduled task and app pool that uses it until you update the stored password. Find all uses first (SPNs, services, IIS app pools, scheduled tasks), plan a window, and update them in the same change. Better still, move the service to a gMSA, which rotates its own password and always has AES keys.

# 1. Set the account to AES only
Set-ADUser svc_sql -Replace @{ 'msDS-SupportedEncryptionTypes' = 0x18 }

# 2. Reset the password so AES keys are generated (then update the service with the new password)
Set-ADAccountPassword svc_sql -Reset -NewPassword (Read-Host -AsSecureString 'New password')

In Active Directory Users and Computers the same encryption setting is on the account’s Account tab: tick This account supports Kerberos AES 128 bit encryption and This account supports Kerberos AES 256 bit encryption. For moving services to managed accounts, see gMSA on Windows Server 2025.

Linux or appliance service uses a keytab

A keytab exported with only RC4 keys fails once the KDC issues AES tickets. Re-export it with AES keys after the account has them:

ktpass /princ HTTP/web01.contoso.local@CONTOSO.LOCAL /mapuser svc_web /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /pass * /out web01.keytab

Copy the new keytab to the server, update the service and test. Also check the client’s Kerberos config (for example krb5.conf permitted enctypes) still allows AES.

A device genuinely cannot do AES

Ask the vendor for an update first. If there is none, allow RC4 on that one service account, not domain-wide. Microsoft suggests 0x24 (RC4 with AES session keys):

Set-ADUser svc_legacyscanner -Replace @{ 'msDS-SupportedEncryptionTypes' = 0x24 }

The domain-wide fallback is the DefaultDomainSupportedEncTypes REG_DWORD under HKLM\System\CurrentControlSet\services\KDC on every DC. Microsoft calls including RC4 there a last resort, because it leaves every account without an explicit setting exposed to CVE-2026-20833. Track any exception with an owner and an end date. Microsoft also asks vendors and customers with unsupported devices to email stillneedrc4@microsoft.com.

Check that it worked

1. Rerun the 4769 query: the services you fixed should no longer appear with 0x17.
2. Rerun the KDCSVC query: no new 203, 204, 208 or 209 errors for those accounts.
3. From a client, request a ticket for the service and look at the encryption type: klist purge, then klist get MSSQLSvc/sql01.contoso.local:1433 and klist. The ticket should show an AES-256 (or AES-128) encryption type.
4. Test the application end to end, including any scheduled jobs that run under the service account.

Common problems after enforcement

• klist failed with 0xc00002fd/-1073741059: The encryption type requested is not supported by the KDC. The matching 4769 failure has status 0xE (KDC_ERR_ETYPE_NOTSUPP). The service or client cannot use AES: apply the fixes above.
• WinRM / New-PSSession fails with error 0x80090342. Same cause; Microsoft shows this when the target computer account is set to RC4 only.
• SMB share access fails with a network error to a server whose computer account is RC4 only. Check the computer object’s msDS-SupportedEncryptionTypes and any GPO setting “Network security: Configure encryption types allowed for Kerberos” that removed AES.
• Linux/Samba/Java service fails but the DC logs nothing. The KDC issued an AES ticket and the service could not decrypt it with its RC4-only keytab. Re-export the keytab.
• NTLM fallback hides the problem. Some apps silently fall back to NTLM when Kerberos fails. If you are also restricting NTLM, fix RC4 first.

Official documentation: KB5073381: Kerberos KDC usage of RC4 (CVE-2026-20833) · Detect and remediate RC4 usage in Kerberos · Event 4769 · Kerberos-Crypto scripts (Microsoft GitHub)

Related: Disable NTLM Active Directory-Wide: 5 Safe Audit and Block Steps · Active Directory Audit Policy: DC Settings and 35 Key Event IDs · Group Managed Service Accounts (gMSA): Complete Windows Server 2025 Guide · Get-ADUser PowerShell Examples: 25 Queries for Active Directory · SMB Signing Group Policy: Secure Setup and 3 Ways to Disable SMBv1

See also: Reset krbtgt Password Safely: Two Resets, Replication and RODCs · Kerberos RC4 Audit Script: Find RC4 Accounts and Tickets · BadSuccessor dMSA on Server 2025: Audit OU Rights and Patch

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

Domain controllers with KB5073381 updates; tested on Windows Server 2025 DC and Windows 11 Pro

Last full review

6 Oct 2026

Next review

4 Apr 2027

Sources

support.microsoft.com/en-us/topic/1ebcda33-720a-4da8-93c1-b0496e1910dc
learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos
learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769
github.com/microsoft/Kerberos-Crypto