Fix Kerberos and NTLM Authentication Failures from Duplicate SIDs After Windows Hardening

If Windows 11 24H2, Windows 11 25H2, or Windows Server 2025 systems suddenly start throwing authentication failures after patching, and the affected machines were cloned without Sysprep, stop chasing DNS, bad passwords, or random RDP bugs first. Microsoft now documents a security hardening change that blocks Kerberos and NTLM handshakes between hosts that share duplicate machine identity data.

This is not a cosmetic warning. It can break SMB access, RDP sessions, failover clustering, Privileged Access Management workflows, and any admin process that depends on normal domain authentication between cloned machines. The fastest useful evidence is usually LsaSrv Event ID 6167 on the target machine, paired with symptoms like repeated credential prompts or the message “There is a partial mismatch in the machine ID.”

The practical answer is blunt: if the machines were cloned in an unsupported way, the durable fix is to rebuild them with supported imaging methods. There is a temporary rollback path, but Microsoft is explicit that it reduces security and should only buy you time for remediation.

Quick Fix checklist

Use this order before you keep retesting passwords or opening firewall ports:

1. Confirm the affected systems are Windows 11 24H2, Windows 11 25H2, or Windows Server 2025.
2. Confirm they installed Windows updates released on or after August 29, 2025 (KB5064081) or September 9, 2025 (KB5065426).
3. Check the target machine’s System log for LsaSrv Event ID 6167.
4. Check whether the affected systems were cloned, duplicated, or templated without Sysprep.
5. Treat this as a duplicate SID / machine identity problem, not just a generic Kerberos problem.
6. Stop any current automation that is still cloning Windows images without Sysprep.
7. Plan a rebuild of affected machines using supported deployment methods.
8. If business impact is immediate, open a Microsoft support case for the temporary rollback path and document where you use it.

If step 4 is true and step 3 shows 6167, you are usually in the right branch already.

What changed and why this started after patching

Microsoft’s support guidance in KB5070568 and KB5068222 explains that newer Windows hardening ties Kerberos loopback and related authentication behavior more tightly to machine identity.

The key change is that Windows now uses a more persistent machine identity model across restarts. Microsoft says that with updates released on and after August 26, 2025, the machine identity includes both per-boot and cross-boot components. That helps block privilege escalation tricks that reused authentication artifacts across restarts.

For properly deployed machines, this is a security improvement. For unsupported clones, it exposes a problem that used to stay quiet.

Microsoft describes the hardening rollout like this:

• August 2025 non-security updates and September 2025 security updates introduced the stronger loopback protections.
• The protections apply even if you are not using the preview Administrator protection feature.
• Machines cloned without Sysprep can start failing Kerberos and NTLM authentication by design.

That is why these cases feel sudden. The image might have been wrong for months, but the hardening change is what made the environment stop tolerating it.

Symptoms and logs that point to this issue

Microsoft’s KB5070568 calls out several common symptoms. In the field, the pattern usually looks like this:

• users are repeatedly prompted for credentials
• valid credentials fail anyway
• shared folders fail over hostname or IP
• RDP sessions stop connecting
• PAM-launched remote sessions fail
• failover clustering throws access denied
• admins see odd on-screen messages like “Login failed/your credentials didn’t work” or “There is a partial mismatch in the machine ID”

The highest-value log check is on the target machine:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 6167,6168 } -MaxEvents 50 |
  Select-Object TimeCreated, Id, ProviderName, Message |
  Format-List

For the main failure condition, Microsoft says the System log contains Local Security Authority Server Service (lsasrv.dll) Event ID 6167 with message text similar to:

There is a partial mismatch in the machine ID. This indicates that the ticket has either been manipulated or it belongs to a different boot session.

Microsoft also says the Security log may contain the SEC_E_NO_CREDENTIALS error.

If you need a quick triage query for Security log text:

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Message -match 'SEC_E_NO_CREDENTIALS' } |
  Select-Object TimeCreated, Id, Message |
  Format-List

The important operational point is this: Event ID 6167 on a cloned machine is stronger evidence than a help desk description of “RDP is broken.”

Root cause: unsupported cloning, duplicate SIDs, and machine identity mismatch

Microsoft’s root-cause statement is direct. Duplicate SIDs can be created when performing unsupported cloning or duplication of a Windows installation without running Sysprep. Once the newer hardening is in place, those machines can no longer authenticate cleanly in scenarios where the stronger identity checks detect the mismatch.

This is the part many teams get wrong: the problem is not just “Kerberos got stricter.” The underlying issue is usually that the estate contains machines built from an image that never went through the supported generalization process.

Microsoft’s Windows IT Pro guidance goes further and says:

• stop any automation that clones devices without Sysprep
• rebuild all devices with duplicate SIDs from scratch
• it is not sufficient to unjoin devices and run Sysprep afterward

That last sentence matters. A lot of teams will try the cheapest possible fix first: remove from the domain, rename, rejoin, run a cleanup script, and hope the issue disappears. Microsoft is saying that is not the durable remediation path for this hardening problem.

What to check before you declare a rebuild project

You do not need to rebuild your whole estate because one machine had a bad password. You do need to rebuild the right systems if your evidence lines up.

1. Confirm update timing

Check whether the failure started only after the hardening-capable updates landed.

Get-HotFix | Where-Object { $_.HotFixID -in 'KB5064081','KB5065426' } |
  Select-Object HotFixID, InstalledOn, Description

If the failing system is in the affected OS family and the issue appeared after these or later cumulative updates, that supports the case.

2. Confirm the build workflow

Ask one practical question: Was this machine cloned from a Windows image that skipped Sysprep?

This commonly shows up in environments that:

• duplicate VMs from a “golden” machine by copying disks directly
• clone kiosk or lab devices through old imaging shortcuts
• copy prejoined templates
• use a vendor or internal process that assumes post-clone domain join is enough

If the answer is “maybe,” treat that as a real lead, not a soft hint.

3. Check the target machine, not only the client

Because Microsoft says the auth target machine logs the key evidence, pull the System log from the server or destination device that rejected the authentication attempt.

That means:

• file server for SMB failures
• jump host or target workstation for RDP failures
• cluster node for failover issues
• management endpoint for remote admin failures

4. Separate this from ordinary Kerberos hygiene issues

Normal Kerberos issues still exist: time skew, DNS, SPN problems, line-of-sight to a DC, stale passwords, and replication delay. But if you have 6167 plus unsupported cloning, those usual suspects are probably noise, not root cause.

Repair workflow that actually matches Microsoft’s guidance

Step 1: Freeze the bad imaging process

Before you remediate endpoints, stop making more broken ones.

If any workflow is still copying Windows installations without Sysprep, disable it now. Otherwise you will rebuild a few machines while new duplicates keep arriving.

Step 2: Identify the affected population

Build a short list of systems that meet all three conditions:

1. supported affected OS
2. post-hardening authentication failures
3. evidence of clone-based deployment or 6167

This is the rebuild list, not the entire domain.

Step 3: Rebuild with supported deployment methods

Microsoft’s durable fix is to rebuild affected machines so they receive unique SIDs through a supported deployment path.

That usually means one of these patterns:

• rebuild from a properly generalized image
• redeploy through Autopilot or your standard provisioning stack
• recreate the VM from a Sysprep’d template
• use your imaging platform only after validating it generalizes Windows correctly

If you are using a custom image, the safe part is the generalization step, not the fact that the image is “gold.”

Step 4: Validate after rebuild

After redeployment, retry the exact workflow that failed earlier:

• SMB to the same file server
• RDP to the same target
• PAM launch path
• cluster operation
• admin tool workflow

Then recheck the target machine’s System log to confirm 6167 stopped appearing for the rebuilt host.

Step 5: Remove old clones from service

Microsoft’s guidance implies you should not keep the unsupported clones hanging around. Once the rebuilt systems are verified, retire the old ones so they do not reappear in future incidents.

Temporary rollback path and why it should stay temporary

This is the part that saves production but can create complacency.

Microsoft’s basic support article KB5070568 says IT admins can temporarily address the issue by installing and configuring a special Group Policy obtained through Microsoft Support for business. The newer Windows IT Pro guidance refines that further: the current workaround is a registry-based compatibility option that replaces the earlier KIR-based rollback settings.

Microsoft also says:

• you obtain this rollback path by opening an assisted support case
• the rollback is temporary
• the rollback remains available only until the end of 2027
• using it reduces the protections introduced by the hardening updates

The blog highlights one more important signal. If you use the temporary rollback and restart, the next blocked authentication attempt can be allowed, and the target machine logs LsaSrv Event ID 6168 as a warning.

That makes 6168 useful for governance:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 6168 } -MaxEvents 50 |
  Select-Object TimeCreated, MachineName, Message |
  Format-List

Do not treat the rollback as a fix. Microsoft explicitly warns that it allows a UAC bypass via Kerberos scenario that the hardening was designed to block. In plain terms, it buys you time but reopens risk.

Prevention: how to avoid seeing this again

The prevention plan is not fancy. It is mostly about discipline.

1. Always Sysprep Windows images before cloning or templating them.
2. Remove any workflow that copies a joined or previously booted Windows installation as a shortcut.
3. Validate VM templates and task sequences with one post-deploy authentication test before scaling them.
4. Add a check for LsaSrv 6167 to your escalation runbook for post-patch authentication failures.
5. Track any temporary rollback usage and force a rebuild plan behind it.
6. Plan to be out of rollback mode before end of 2027, because Microsoft already says the bridge expires.

If your environment still depends on unsupported clone behavior, this hardening change is the warning shot. Waiting for the next outage window is the expensive version of fixing it.

Conclusion

When Kerberos and NTLM start failing on Windows 11 24H2, Windows 11 25H2, or Windows Server 2025 after newer hardening updates, and the target machine logs LsaSrv Event ID 6167, the issue may be duplicate SIDs from unsupported cloning rather than a random authentication regression.

Microsoft’s guidance is consistent across the support articles and Windows IT Pro blog: rebuild affected systems with supported deployment methods, stop cloning without Sysprep, and use the rollback path only as a short-term bridge if production impact forces it. The faster you classify this as an imaging problem instead of a password problem, the less time your team will burn on the wrong fixes.