Fix Kerberos Authentication Failures Before the July 2026 RC4 Enforcement Update

If your domain still has service accounts, appliances, Linux systems, NAS devices, print systems, or old line-of-business apps that silently rely on RC4, the July 2026 Windows security update is not the month to discover that dependency.

Microsoft has already published the sequence. Updates released on and after January 13, 2026 added audit events for the Kerberos changes tied to CVE-2026-20833. Updates released on and after April 14, 2026 changed the default DefaultDomainSupportedEncTypes behavior to AES-only assumptions for accounts without an explicit encryption type configuration. The July 2026 phase removes the rollback path and programmatically enables enforcement. If you wait until failed logons, broken SMB access, and WinRM authentication errors start landing in your queue, you are already late.

This is the admin workflow that matters: patch domain controllers, read the KDCSVC audit events, identify which accounts and devices still need RC4, move what you can to AES, and explicitly scope RC4 only where it still has to exist. Treat this as an authentication outage prevention exercise, not just a security bulletin.

Quick Fix checklist

Use this sequence before broad July patch rollout:

1. Patch all writable domain controllers with Windows updates released on or after January 13, 2026.
2. Review the System log on domain controllers for KDCSVC events 201 through 209, especially KDCSVC Event ID 205.
3. Audit Kerberos Security events 4768 and 4769 to find clients, service accounts, and target systems still using RC4.
4. Check the msDS-SupportedEncryptionTypes attribute on affected accounts and computer objects.
5. Reset passwords for old service accounts that should have AES keys but do not.
6. For systems that truly still require RC4, explicitly configure supported encryption types instead of letting them fall back to insecure defaults.
7. Validate non-Windows and third-party systems in a pilot OU before the July 2026 update reaches production domain controllers.
8. Move pilot domain controllers to enforcement only after the audit events are understood.

If you only do one thing today, do not skip step 3. The 4768 and 4769 data tells you which dependencies still exist instead of forcing you to guess.

What is changing and why admins are seeing this now

Microsoft’s support guidance for CVE-2026-20833 says the risk is tied to Kerberos service tickets being issued with weak or legacy encryption such as RC4. That matters because RC4-backed Kerberos tickets are easier to attack offline than AES-backed ones.

The timing matters just as much as the vulnerability:

• January 13, 2026 started the initial deployment phase with warning and audit behavior.
• April 14, 2026 changed the default KDC assumption for accounts without explicit encryption settings so DefaultDomainSupportedEncTypes moves to 0x18, which means AES128 + AES256.
• July 2026 removes the RC4DefaultDisablementPhase rollback path and programmatically enables enforcement.

Microsoft also states something many teams miss: installing the January 2026 update by itself does not fully mitigate the vulnerability on Active Directory domain controllers. The support article says you must manually enable enforcement if you want the protection before the July phase forces it.

That is why some teams are confused right now. They patched domain controllers, saw no outage, and assumed they were done. In reality, they only entered the warning window.

Root cause: where Kerberos RC4 dependencies usually hide

In most environments, RC4 dependencies are not obvious until you stop allowing fallback behavior.

The common causes are:

1. Old service accounts never got modern keys

Microsoft’s Kerberos guidance explains that accounts created before AES support or accounts that never had passwords reset can still behave like RC4-only accounts. You might see a service account that looks healthy in AD, but it only has the wrong key material for the systems actually using it.

This is common with:

• IIS app pool identities that were created years ago
• SQL or middleware service accounts no one wants to touch
• scheduled task accounts
• legacy Java or Linux-integrated services
• NAS or appliance integrations that joined the domain a long time ago

2. msDS-SupportedEncryptionTypes is undefined and the KDC falls back to defaults

Microsoft’s RC4 remediation article is clear that when msDS-SupportedEncryptionTypes is not defined, the KDC falls back to the assumed default behavior. Before the 2026 changes, that fallback often kept RC4 alive longer than admins realized. After the change, that fallback becomes much less forgiving.

3. Third-party or non-Windows devices do not fully support AES

Microsoft specifically warns that the absence of audit events does not guarantee all non-Windows devices will succeed after enforcement. That warning matters for:

• Linux systems using older Kerberos configurations
• SMB-capable storage devices
• print management appliances
• old SSO integrations
• vendor software with undocumented Kerberos assumptions

4. Domain controllers have an insecure explicit override

If you explicitly configured DefaultDomainSupportedEncTypes to allow RC4, Microsoft says the environment will keep working functionally, but KDCSVC Event ID 205 is logged because the setting is insecure. In other words, you can suppress the immediate outage but still remain on a bad configuration.

Logs and where to check first

Do not start with random packet captures. Start with the evidence Microsoft designed for this rollout.

System log on domain controllers

Check the System log for KDCSVC events after the January 2026 or later update is installed.

Microsoft’s support article tells admins to monitor KDCSVC events 201 through 209. Those events exist to tell you whether enforcement is likely to break current authentication paths.

The highest-value event to call out in escalation notes is usually:

• KDCSVC Event ID 205: indicates the domain controller has an explicit DefaultDomainSupportedEncTypes configuration that still allows insecure RC4 usage.

Security log on domain controllers

Microsoft’s RC4 audit guidance says to review Security Event IDs 4768 and 4769.

• 4768 shows requested Kerberos authentication tickets.
• 4769 shows requested Kerberos service tickets.

In those events, pay attention to these fields:

• MSDS-SupportedEncryptionTypes
• Available Keys
• Advertized Etypes
• Session Encryption Type

That combination tells you whether the client, the target account, or both are still tied to RC4.

AD object attributes

If an affected system or service shows RC4 behavior, inspect the AD object directly. Microsoft provides a straightforward PowerShell method for this.

$accountName = "CONTOSO-SVC-APP01"
$parameters = @{
    Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
    Properties = "msDS-SupportedEncryptionTypes"
}

Get-ADObject @parameters |
  Format-List DistinguishedName, msDS-SupportedEncryptionTypes, Name, ObjectClass

A value of 24 means 0x18, which is AES128 + AES256. A value of 28 means 0x1C, which still includes RC4 together with AES.

Practical remediation workflow

Step 1: Patch domain controllers and collect baseline evidence

Start with all domain controllers that will receive the July 2026 update path. If some DCs are still missing the January or April changes, your logs will be inconsistent and your testing will be misleading.

Then collect:

• KDCSVC events from the System log
• Kerberos 4768 and 4769 events from the Security log
• a list of service accounts and computer objects with explicit or missing msDS-SupportedEncryptionTypes

If you skip this baseline, you end up debating whether the outage is a network issue, bad credentials, or time skew when it is really just an RC4 dependency.

Step 2: Find what is actually RC4-dependent

Use the Security log to identify which systems still advertise or accept RC4.

A practical collection command on a domain controller looks like this:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4768,4769 } -MaxEvents 500 |
  Select-Object TimeCreated, Id, MachineName, Message |
  Export-Csv 'C:\Temp\kerberos-4768-4769.csv' -NoTypeInformation

From there, review the event messages for:

• Advertized Etypes showing RC4 support only or primarily
• Session Encryption Type values that keep landing on RC4
• repeated references to the same service account or target computer

If you have SIEM coverage for Security logs, this step is even better there. But even a CSV export from one pilot DC can expose the obvious offenders fast.

Step 3: Fix service accounts that should already support AES

If the dependency is an old Windows service account, the cleanest fix is often to reset the password and let the account generate modern keys.

Do this carefully because password resets can break app pools, scheduled tasks, services, and SPN-tied apps if the downstream secret is not updated.

Use this decision rule:

• If the workload is expected to support AES, reset the password and retest.
• If the workload is third-party and undocumented, test before changing production.
• If the workload truly requires RC4 today, scope RC4 intentionally instead of relying on fallback defaults.

Step 4: Define encryption types explicitly where needed

Microsoft’s guidance gives two main branches:

1. Define msDS-SupportedEncryptionTypes explicitly on the account or computer object.
2. Adjust the domain controller-side assumption only when you fully understand the blast radius.

For the domain controller setting, Microsoft documents this AES-only value:

Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC
Value name: DefaultDomainSupportedEncTypes
Type: REG_DWORD
Value data: 0x18

That 0x18 setting allows AES128_HMAC_SHA1 and AES256_HMAC_SHA1.

If you need a small number of services to continue using RC4 after April or July, Microsoft’s support article says to explicitly include RC4 in the msDS-SupportedEncryptionTypes bitmask for those services. That is the important operational point: RC4 should become an exception you can name, not a default behavior you forgot existed.

Step 5: Pilot enforcement before broad rollout

Microsoft documents RC4DefaultDisablementPhase as the switch used during the transition window. During the initial deployment phase, admins can move toward enforcement by setting that value to 2 after audit events indicate it is safe.

Do not apply that first on every domain controller.

Use a pilot pattern:

1. Select a limited set of domain controllers.
2. Test the business-critical apps that use Kerberos: SMB shares, SQL, IIS, WinRM, scheduled tasks, Linux-integrated apps, and vendor appliances.
3. Recheck KDCSVC and 4768/4769 events.
4. Only then widen scope.

What failure symptoms look like in the field

Microsoft’s RC4 remediation article calls out two patterns admins are likely to see when RC4 is disabled and the target still depends on it.

SMB access failures

Access to an SMB share can fail with a generic network-style authentication error when the target only supports RC4.

That means file share breakages after July patching may not look like a domain controller issue at first. The file server team may log it as a permissions or network problem when it is really an encryption-type mismatch.

PowerShell remoting and WMI failures

Microsoft also documents WinRM and WMI remoting failures such as:

New-PSSession : [server.contoso.com] Connecting to remote server failed with errorcode 0x80090342 while using Kerberos authentication.

That is an easy trap for admins. They chase SPNs, trusts, local firewall, or WinRM listeners when the actual issue is the target account or machine still relying on RC4.

Caveats that matter before July rollout

First, do not assume no audit events means no risk. Microsoft’s support article explicitly says non-Windows interoperability still needs real testing.

Second, do not mass-edit msDS-SupportedEncryptionTypes on every object without understanding the environment. Some values are processed differently across Windows Server versions, and Microsoft notes that displayed values can differ from raw AD attributes.

Third, Windows Server 2025 changes the way RC4 appears in some Kerberos scenarios. Microsoft also notes that starting with Windows Server 2025, domain controllers do not issue RC4 Ticket Granting Tickets. That can confuse troubleshooting if you compare behavior across mixed DC versions.

Fourth, be careful with vendor-owned integrations. If a storage array, print appliance, or Linux service still cannot use AES, you need a documented exception path and a retirement plan. Do not leave it as tribal knowledge.

Prevention and rollout plan

A sane rollout plan for enterprise admins looks like this:

1. Update all domain controllers.
2. Collect KDCSVC and Kerberos Security log evidence for at least several business cycles.
3. Identify the repeat offenders.
4. Reset passwords or reconfigure encryption support for workloads that should be on AES.
5. Document every workload that still needs RC4.
6. Pilot enforcement on a small DC set.
7. Validate SMB, WinRM, scheduled tasks, service startups, Linux-integrated apps, and vendor appliances.
8. Finish remediation before the July 2026 update removes the easy rollback path.

That is less exciting than a one-line registry fix, but it is the approach least likely to create a Monday-morning outage.

Conclusion

The July 2026 Kerberos RC4 hardening change is not just another patch note. It is a deadline for every environment that still depends on legacy encryption defaults. The safest way through it is to use the evidence Microsoft already provides: KDCSVC events 201 through 209, Security events 4768 and 4769, the msDS-SupportedEncryptionTypes attribute, and a controlled enforcement pilot.

If you are already seeing KDCSVC Event ID 205, treat it as a warning that your current Kerberos defaults are still too loose. Fix the dependency now, before the July 2026 enforcement phase turns that warning into broken authentication.