Sign in Subscribe

Your patch pilot needs authentication checks

Microsoft's July Kerberos hardening is a good reason to test the work that depends on authentication after the patch installs.

Your patch pilot needs authentication checks

Microsoft's July Windows updates remove the temporary rollback from a Kerberos security change that started rolling out in January. The domain controller update can install cleanly, every pilot device can reboot, and authentication-dependent work can still break.

Microsoft's KB5073381 guidance for CVE-2026-20833 includes a warning I would put straight into the patch plan:

The absence of audit events does not guarantee that all non-Windows devices will successfully accept Kerberos authentication after the April update. Customers should validate non-Windows interoperability through testing before broadly enabling this behavior.

The warning refers to the April behavior. July removes the temporary rollback to audit mode. A green installation count cannot answer whether the work still functions.

What changes on domain controllers in July

RC4 is an old Kerberos encryption option. It remains in plenty of environments because of service accounts, applications, appliances, or devices that were configured years ago and never forced anyone to revisit the choice.

Microsoft began this rollout with the January 2026 Windows updates. Those updates added audit events for risky Kerberos behavior. The April updates changed the KDC's default assumption to AES when an account has no explicit encryption setting, while still allowing administrators to return to audit mode with the temporary RC4DefaultDisablementPhase registry value.

According to Microsoft KB5073381, the July 2026 Windows updates stop reading that rollback value. The Microsoft Directory Services team is also clear about an important detail: RC4 is not being removed from Windows. Explicit account or KDC configuration can still change the behavior. July removes the temporary rollback to the older default assumption.

A pilot needs more than domain controller install status and endpoint restarts. The domain controller logs can identify many risky dependencies, but Microsoft says a quiet log does not prove that every non-Windows client will work.

Test the task that depends on authentication

A useful pilot starts with the work people and systems need to complete. Pick examples that match your environment. That might include:

  • signing in from representative Windows, macOS, or Linux clients that use Active Directory;
  • opening an SMB file share with a normal user account;
  • printing or scanning through a device that authenticates to a domain service;
  • running a scheduled job or application under a service account;
  • accessing a NAS, backup appliance, lab system, or other non-Windows device joined to the domain;
  • using WinRM, remote administration, VPN, or another workflow that requests Kerberos tickets.

Choose only technology you actually run. Exercise the full path, including the client, service account, target service, and domain controller involved. If you have multiple DCs or sites, record which DC issued the ticket and repeat the important tests across each updated DC version and representative site before broad rollout.

I'd add a small table to the normal patch report:

Scenario Expected result Evidence Owner
Staff sign-in on a pilot device User signs in without delay and uses the expected authentication protocol Test record, ticket check, and relevant client/DC events Identity owner
File share access User opens and changes a test file Successful access plus ticket/event check Storage owner
Print or scan workflow Job completes using domain authentication Device log or completed test job Print owner
Service account task Scheduled task or application job completes Job result and ticket/event check Application owner
Non-Windows appliance Representative authentication succeeds Appliance log and DC event correlation Service owner

The exact columns matter less than the decision they support. Someone should be able to look at the pilot and say which authentication paths were exercised, what failed, who owns the fix, and whether production rollout should stop.

Use the logs, but do not stop there

Microsoft documents KDCSVC events 201 through 209 in the System log for this hardening. Its RC4 detection and remediation guide explains how to use Security events 4768 and 4769 to inspect ticket encryption and advertised encryption types. The available detail depends on the DC version and installed updates.

Those are useful sources for inventory and troubleshooting. They can point you toward accounts, services, and devices that need attention. You still need a working transaction from the client to the service.

If the logs identify a dependency, record the actual remediation path. That may mean resetting a service-account password so modern keys are generated, updating an application's Kerberos settings, installing device firmware, explicitly allowing RC4 through msDS-SupportedEncryptionTypes on the affected account as a temporary exception, or replacing something that cannot support the required encryption. Microsoft also documents KDC-level configuration, but that is a broader exception because it changes the assumed behavior for accounts without an explicit value. Give every explicit exception an owner and review date in the same report as the failure.

Define what each patch ring proves

Most patch workflows use some version of Alpha, Beta, and Production rings. If you use FileWave, its software update deployment guide documents that structure for Windows and Apple updates. Whatever your tool calls the rings, the promotion gates are the important part.

For this change, I would define the promotion gates this way:

  • Alpha proves the intended DC update is installed, pilot devices return to management with a current last check-in, and the most important authentication scenarios work through the updated KDCs.
  • Beta adds more hardware, network locations, user roles, less common services, and representative sites or DC versions.
  • Production starts only after failures have an owner, a remediation, or an approved exception.

A percentage alone cannot make that decision. If 100 pilot devices updated but nobody tested the old scan-to-folder workflow or the backup appliance's domain access, the pilot never covered those dependencies.

Before the July domain controller updates move through your rings, write down the authentication-dependent tasks that would create a real support incident if they failed. Put at least one representative test for each task into the pilot. Then keep those checks. The next certificate, identity, or protocol change will need them too.

Sources