How to Find and Fix RC4 Kerberos Usage Before July 2026 EnforcementS

Microsoft’s July 2026 Windows security updates remove the temporary rollback option for its Kerberos RC4 hardening changes. Active Directory environments that still depend on RC4 for service-ticket issuance may experience authentication failures after updated domain controllers enter full enforcement.

The problem is that many administrators do not know whether their environment still uses RC4. A service account may permit RC4 without actively using it, while an older appliance may request RC4 even when its related Active Directory account supports AES.

This guide explains how security and server administrators can identify actual RC4 Kerberos activity, trace it back to affected accounts and devices, evaluate business risk, and remediate dependencies without creating an avoidable production outage.

What changes with Microsoft’s July 2026 updates?

The Kerberos changes address CVE-2026-20833, an information-disclosure vulnerability involving the issuance of service tickets protected with weak or legacy encryption types such as RC4.

An authenticated attacker can request Kerberos service tickets for accounts with registered Service Principal Names, obtain RC4-protected ticket material, and attempt to recover the service account password offline. This activity is commonly associated with Kerberoasting.

Microsoft divided the RC4 hardening rollout into phases:

Date	Deployment phase	Administrator impact
January 13, 2026	Initial deployment and auditing	Introduced additional KDC events and the temporary RC4DefaultDisablementPhase control.
April 14, 2026	Enforcement by default	KDCs began assuming AES-SHA1 support for accounts without an explicit msDS-SupportedEncryptionTypes value, while a manual rollback remained available.
July 2026	Full enforcement	Support for the temporary RC4DefaultDisablementPhase rollback mechanism is removed.

This change does not mean that Microsoft instantly removes every possible use of RC4. Accounts may still have RC4 explicitly enabled through msDS-SupportedEncryptionTypes. However, leaving RC4 enabled preserves a weaker authentication dependency and should not be considered the normal long-term solution.

Why RC4 remains a security concern

RC4 is retained primarily for compatibility with older systems. Compared with AES-protected tickets, RC4 service tickets are substantially more attractive targets for offline password-cracking attacks.

A Kerberoasting attack generally follows this pattern:

1. An authenticated attacker identifies an account with a registered Service Principal Name.
2. The attacker requests a Kerberos service ticket for that service.
3. The ticket is copied from memory or collected through tooling.
4. The attacker attempts to crack the service account password offline.
5. If successful, the attacker uses the recovered credentials according to the account’s permissions.

Moving ticket encryption from RC4 to AES does not eliminate every Kerberoasting risk. Service accounts still require strong passwords, limited privileges, controlled logon rights, and appropriate monitoring. AES does, however, remove dependence on the weaker RC4 algorithm and makes offline cracking materially harder.

How do you know whether Active Directory still uses RC4?

There is no single setting that provides a complete answer. A reliable RC4 assessment combines:

• KDCSVC events 201 through 209
• Kerberos Security events 4768 and 4769
• Service-account encryption attributes
• Available Kerberos keys
• Application and appliance testing
• Local ticket inspection
• Centralized log or SIEM analysis

The most important distinction is between configured capability and actual ticket use. An account attribute can show that RC4 is allowed, but Event ID 4769 provides evidence that an RC4 service ticket was actually issued.

Method 1: Review KDCSVC events 201 through 209

After installing Windows updates released on or after January 13, 2026, supported domain controllers can record additional Kerberos Key Distribution Center events in the System log.

On each writable domain controller:

1. Open Event Viewer.
2. Open Windows Logs → System.
3. Select Filter Current Log.
4. Filter by event source Kdcsvc.
5. Enter Event IDs 201-209.

These events help identify configurations that could prevent enforcement from being completed safely. Examples include clients that advertise only insecure encryption types, accounts that lack AES keys, and insecure domain-level defaults.

Event range	General meaning	Administrative action
201 / 203	Client-advertised encryption-type compatibility conditions	Identify the requesting device and verify that its operating system or Kerberos implementation supports AES.
202 / 204	Account does not have the required AES keys	Identify dependencies and plan a controlled password reset or account remediation.
205	Insecure DefaultDomainSupportedEncTypes configuration	Review the configured KDC encryption defaults before enforcement.
206–209	Related AES-SHA1-only compatibility and key conditions	Review the full event text and trace the affected account or client.

Method 2: Audit Kerberos events 4768 and 4769

Security events provide the strongest evidence of the encryption types being requested and issued in your environment:

• Event ID 4768: A Kerberos Ticket Granting Ticket was requested.
• Event ID 4769: A Kerberos service ticket was requested.

For RC4 service-ticket discovery, Event ID 4769 is particularly valuable because it identifies the target account, service, requesting client and ticket encryption type.

Review the following fields when available:

• Ticket Encryption Type
• Session Encryption Type
• Advertized Etypes
• MSDS-SupportedEncryptionTypes
• Available Keys
• Service Name
• Account Name
• Client Address

Microsoft documents the additional encryption details for newer supported Windows Server releases. Windows Server 2016 received the expanded information through its January 2025 cumulative update.

Kerberos ticket encryption values

Hex value	Encryption type	Interpretation
0x11	AES128-CTS-HMAC-SHA1-96	AES128 ticket
0x12	AES256-CTS-HMAC-SHA1-96	AES256 ticket
0x17	RC4-HMAC	RC4 ticket was issued
0x18	RC4-HMAC-EXP	Export-grade RC4 ticket was issued

A Ticket Encryption Type of 0x17 is direct evidence that RC4-HMAC was used for that ticket. Record the service, account, client address and timestamp, then determine which system owner is responsible for the dependency.

Method 3: Find RC4 service tickets with PowerShell

The following PowerShell script searches the local domain controller’s Security log for Event ID 4769 and extracts tickets using RC4-HMAC or RC4-HMAC-EXP.

$startTime = (Get-Date).AddDays(-7)
try {
    $events = Get-WinEvent -FilterHashtable @{
        LogName   = 'Security'
        Id        = 4769
        StartTime = $startTime
    } -ErrorAction Stop
}
catch {
    Write-Error "Unable to read Security event 4769. Run PowerShell with appropriate log-read permissions. $($_.Exception.Message)"
    return
}
$rc4Tickets = foreach ($event in $events) {
    try {
        $xml = [xml]$event.ToXml()
        $data = @{}
        foreach ($item in $xml.Event.EventData.Data) {
            if ($item.Name) {
                $data[$item.Name] = [string]$item.'#text'
            }
        }
        if ($data['TicketEncryptionType'] -in @('0x17', '0x18')) {
            [pscustomobject]@{
                TimeCreated          = $event.TimeCreated
                AccountName          = $data['TargetUserName']
                ServiceName          = $data['ServiceName']
                ClientAddress        = $data['IpAddress']
                ClientPort           = $data['IpPort']
                TicketEncryptionType = $data['TicketEncryptionType']
                Status               = $data['Status']
                DomainController     = $env:COMPUTERNAME
            }
        }
    }
    catch {
        Write-Warning "Unable to parse event record $($event.RecordId)."
    }
}
$rc4Tickets |
    Sort-Object TimeCreated -Descending |
    Format-Table -AutoSize

Run the script from an elevated PowerShell session with permission to read the Security log. Repeat it on every writable domain controller, or preferably collect the events centrally through Windows Event Forwarding, Microsoft Sentinel or another SIEM.

Method 4: Review msDS-SupportedEncryptionTypes

The msDS-SupportedEncryptionTypes attribute describes which Kerberos encryption types an account is configured to support. This can reveal questionable configurations, but it does not prove that a specific encryption type is actively being used.

Start with user-based service accounts that have one or more Service Principal Names:

Import-Module ActiveDirectory -ErrorAction Stop
Get-ADUser -LDAPFilter '(&(servicePrincipalName=*)(!(objectClass=computer)))' `
    -Properties servicePrincipalName, msDS-SupportedEncryptionTypes |
    Select-Object Name,
                  SamAccountName,
                  msDS-SupportedEncryptionTypes,
                  ServicePrincipalName |
    Sort-Object SamAccountName

To identify SPN-bearing user accounts whose configured bitmask explicitly includes RC4:

Get-ADUser -LDAPFilter '(&(servicePrincipalName=*)(!(objectClass=computer)))' `
    -Properties servicePrincipalName, msDS-SupportedEncryptionTypes |
    Where-Object {
        $null -ne $_.'msDS-SupportedEncryptionTypes' -and
        (($_.'msDS-SupportedEncryptionTypes' -band 0x4) -ne 0)
    } |
    Select-Object Name,
                  SamAccountName,
                  msDS-SupportedEncryptionTypes,
                  ServicePrincipalName |
    Sort-Object SamAccountName

Common encryption bitmask values

Value	Configured encryption support	Administrative meaning
0x4	RC4	RC4 is explicitly permitted.
0x8	AES128	AES128 is permitted.
0x10	AES256	AES256 is permitted.
0x18	AES128 and AES256	Common AES-only setting.
0x1C	RC4, AES128 and AES256	RC4 remains available alongside AES.
0x24	RC4 plus AES session-key support	Microsoft-documented compatibility fallback for certain non-Windows devices that cannot yet be fully remediated.

A value of 0x1C does not mean that every ticket uses RC4. It means the account permits RC4 and both AES types. Use Event ID 4769 to determine which encryption algorithm the KDC actually selected.

A blank attribute also does not automatically mean an account is RC4-only. The effective behavior depends on the domain-controller update level, account keys, client-advertised encryption types, domain defaults and the current rollout phase.

Method 5: Identify accounts without AES keys

An older service account may not have AES keys if its password has not been changed since before AES support was available to that account. Microsoft states that changing the account password can generate the missing AES keys.

Do not reset service account passwords without first identifying every dependency. A single traditional service account may be used by:

• Windows services
• IIS application pools
• SQL Server services
• Scheduled tasks
• SharePoint components
• Backup applications
• Monitoring platforms
• Middleware or integration services
• Linux or Java applications

A poorly coordinated password reset can create an outage unrelated to the encryption change itself. Build a dependency map, identify the application owner, schedule the change, update every stored credential securely, and validate authentication afterward.

Where supported, consider replacing traditional user-based service accounts with group Managed Service Accounts. A gMSA provides automatic password management and reduces the operational risks associated with long-lived static credentials.

Method 6: Inspect cached tickets with klist

The built-in klist command can help when testing a specific client, account or application:

klist

Review the encryption type associated with the service ticket you are investigating. An RC4-HMAC ticket is evidence of RC4 use for that cached ticket.

For controlled retesting, tickets can be purged and requested again after a configuration change. Do this carefully on production systems because purging tickets can temporarily disrupt active authentication sessions.

klist is useful for local troubleshooting, but it cannot replace domain-wide analysis. It only displays tickets available in the selected local logon session.

Method 7: Test legacy and non-Windows systems

Legacy and third-party Kerberos implementations are the most likely to behave differently from modern Windows clients.

Prioritize testing for:

• Older Java applications
• Linux and Unix Kerberos clients
• NAS and SMB storage appliances
• Multifunction printers and embedded devices
• Legacy IIS and .NET applications
• Older SharePoint or SQL Server integrations
• Identity and single sign-on appliances
• Backup and monitoring platforms
• Azure Files using on-premises Active Directory Domain Services authentication
• FSLogix environments using SMB-based profile storage
• Cross-forest trusts and non-Windows Kerberos realms

Do not assume that a currently supported device uses AES correctly. Confirm the vendor’s Kerberos requirements and test authentication against updated domain controllers.

Use Microsoft’s official RC4 audit scripts

Microsoft provides two PowerShell scripts for reviewing Kerberos encryption activity:

• List-AccountKeys.ps1 searches Kerberos events to identify the account keys available for ticket issuance.
• Get-KerbEncryptionUsage.ps1 identifies the encryption types observed in Kerberos activity and can be filtered to locate RC4 use.

The scripts are available from Microsoft’s official Kerberos-Crypto GitHub repository.

Before running downloaded administrative scripts:

• Confirm the repository owner is Microsoft.
• Review the script source before execution.
• Download or clone the repository through an approved administrative workstation.
• Validate file hashes where your change-control process requires it.
• Run with only the permissions required for the audit.
• Protect generated reports as sensitive infrastructure data.

What to do when you find RC4

The remediation depends on why the KDC selected RC4. Do not make a domain-wide change until you understand the account, client and application involved.

Scenario 1: The account does not have AES keys

• Identify every service and application using the account.
• Confirm the account owner and business criticality.
• Create a rollback and validation plan.
• Change the password to generate new account keys.
• Update securely stored credentials on every dependency.
• Purge and request new Kerberos tickets during testing.
• Verify Event ID 4769 now shows AES ticket encryption.

Scenario 2: The client does not advertise AES

• Identify the requesting host from the Kerberos event.
• Verify operating-system, firmware and Kerberos-library support.
• Review local and domain Group Policy encryption settings.
• Update the device or application.
• Contact the vendor when supported encryption behavior is unclear.
• Replace systems that cannot meet the organization’s authentication requirements.

Scenario 3: The account explicitly permits RC4

• Confirm through Event ID 4769 whether RC4 is actually being issued.
• Identify every client and service that depends on the account.
• Test AES authentication before changing the bitmask.
• Remove the RC4 bit only through a controlled change.
• Monitor for ticket failures, application errors and NTLM fallback.

Microsoft’s 0x24 compatibility fallback

Microsoft documents 0x24 as a compatibility option for certain non-Windows devices that cannot yet be fully remediated. This setting permits RC4 while enabling AES session-key support.

It should be treated as a temporary, documented exception, not a standard fix.

For any temporary RC4 exception:

• Use a long, randomly generated service-account password.
• Limit the account’s privileges and logon rights.
• Restrict which systems may use the account.
• Monitor Event ID 4769 for its service-ticket activity.
• Block interactive logon when it is not required.
• Create a replacement or upgrade deadline.
• Review the exception through the normal security-risk process.

Should administrators simply re-enable RC4?

No. Re-enabling RC4 may restore compatibility, but it preserves the weaker encryption dependency Microsoft is trying to remove.

A temporary exception may be necessary for a critical legacy service, but the default remediation path should be:

• Enable and validate AES support.
• Generate missing AES keys.
• Upgrade legacy software and firmware.
• Replace unsupported devices.
• Move services to managed identities or gMSAs where possible.
• Remove RC4 from account and domain configurations after testing.

Symptoms of an unresolved RC4 dependency

After enforcement, affected organizations may encounter:

• Windows services failing to start under service accounts
• Scheduled tasks failing authentication
• IIS application pools losing access to backend services
• SQL Server integrated-authentication failures
• SharePoint service or database connectivity errors
• NAS or SMB access failures
• FSLogix profile-mount failures
• Non-Windows devices failing to obtain Kerberos tickets
• Applications unexpectedly falling back to NTLM
• Kerberos errors following domain-controller patching

Do not assume every authentication failure after patching is related to RC4. Correlate the failure time with domain-controller Security logs, KDCSVC events, application logs and network activity before changing security settings.

Recommended deployment plan for server and security teams

Phase 1: Establish visibility

• Confirm all domain controllers have the required audit-capable updates.
• Verify Kerberos auditing and Security-log retention.
• Forward events 4768, 4769 and KDCSVC 201–209 to a central location.
• Run Microsoft’s official audit scripts.
• Collect at least one representative business cycle of authentication activity.

Phase 2: Classify dependencies

• Map each RC4 ticket to an account, client, service and owner.
• Separate missing-key issues from client-compatibility issues.
• Identify production criticality and outage impact.
• Prioritize privileged, internet-facing and high-value service accounts.
• Document vendor support status for affected systems.

Phase 3: Remediate and test

• Generate AES keys through controlled password changes where required.
• Upgrade or reconfigure affected clients.
• Test applications against updated domain controllers.
• Confirm new service tickets use 0x11 or 0x12.
• Monitor for authentication failures and NTLM fallback.

Phase 4: Enforce and monitor

• Complete domain-controller patching through controlled deployment rings.
• Monitor the help desk and application teams for authentication incidents.
• Review exceptions and remove temporary RC4 configurations.
• Continue auditing 4769 events after enforcement.
• Report unresolved dependencies to security and infrastructure leadership.

RC4 readiness checklist

• All writable domain controllers are inventoried.
• Kerberos Security-event auditing is enabled.
• KDCSVC events 201–209 are centrally collected.
• Events 4768 and 4769 are retained long enough for analysis.
• Tickets using 0x17 or 0x18 have been identified.
• SPN-bearing user accounts have been reviewed.
• Accounts without AES keys have been identified.
• Traditional service-account password dependencies are documented.
• Non-Windows devices have been tested.
• Cross-forest and external Kerberos trusts have been reviewed.
• Application owners have approved remediation testing.
• Temporary RC4 exceptions have owners and expiration dates.
• NTLM fallback is being monitored.
• Post-patch authentication validation is documented.

What should not be overstated?

• The July 2026 update does not disable Kerberos.
• An account that permits RC4 is not necessarily issuing RC4 tickets.
• A blank msDS-SupportedEncryptionTypes value does not automatically mean an account is misconfigured.
• The absence of KDCSVC events does not prove every third-party system is compatible.
• Changing a service-account password without dependency planning can cause an outage.
• Moving from RC4 to AES does not eliminate the need for strong service-account passwords.
• AES migration does not, by itself, eliminate every form of Kerberoasting or credential attack.
• 0x24 is a compatibility exception, not the recommended organization-wide setting.

Final assessment

Microsoft’s July 2026 Kerberos enforcement change removes a temporary compatibility path that may have allowed unresolved RC4 dependencies to remain hidden.

The safest approach is evidence-driven: identify actual RC4 service-ticket issuance through Event ID 4769, use KDCSVC events to locate compatibility problems, review account-key availability, test non-Windows systems, and remediate each dependency through normal change control.

Security teams should treat RC4 usage as an authentication weakness. Server teams should treat the transition as a production dependency project. Organizations that combine both perspectives are far less likely to trade a security improvement for an avoidable service outage.

Official Microsoft references

• Microsoft Support: How to manage Kerberos KDC usage of RC4 for CVE-2026-20833
• Microsoft Learn: Detect and remediate RC4 usage in Kerberos
• Microsoft Kerberos-Crypto scripts on GitHub
• Microsoft Learn: Kerberos authentication overview

Frequently asked questions

How can I tell whether Kerberos is actually using RC4?

Review Event ID 4769 on your domain controllers. A Ticket Encryption Type of 0x17 indicates RC4-HMAC, while 0x18 indicates RC4-HMAC-EXP. These events provide stronger evidence than account configuration alone.

Does msDS-SupportedEncryptionTypes prove that RC4 is being used?

No. The attribute shows which encryption types an account is configured to support. It does not prove which type the KDC selected for a particular ticket. Correlate the account setting with Event ID 4769.

What does Kerberos encryption type 0x17 mean?

0x17 represents RC4-HMAC. AES128 is 0x11, and AES256 is 0x12.

Will resetting a service-account password enable AES?

A controlled password change can generate missing AES keys for an older account. It will not correct a client or application that lacks AES support, and it can cause an outage if stored credentials are not updated everywhere the account is used.

Does the July 2026 update remove all RC4 support?

No. The update removes the temporary RC4DefaultDisablementPhase rollback mechanism and enforces the hardened default behavior. RC4 can still be explicitly configured for limited compatibility scenarios, although Microsoft recommends removing those dependencies.

What is msDS-SupportedEncryptionTypes value 0x24?

Microsoft documents 0x24 as a compatibility value that permits RC4 while supporting AES session keys for certain non-Windows systems that cannot yet be fully remediated. It should be temporary, narrowly scoped and documented as a security exception.