Share via

Windows 11 24H2 RDP, SMB, and printer sharing fail after KB5065426 (0xc000006d) between cloned workstations

Dustin Bernier 80 Reputation points
2025-09-30T00:47:33.2566667+00:00
  1. Environment:
    • Windows 11 24H2, build 26100.6584 (KB5065426 installed).
    • Domain-joined workstations (no issue with servers).
    • Workstations were cloned, many share the same machine SID.
  2. Symptoms:
    • RDP from Win11 → Win11 fails with 0xc000006d (STATUS_LOGON_FAILURE).
    • SMB file sharing and printer sharing between Win11 workstations also fail.
    • Console login and RDP from servers still work.
  3. What we tested (and didn’t work):
    • Different credentials (domain admin, local admin).
    • Disabling CredSSP/Extended Protection.
    • Changing SecurityLayer/UserAuthentication registry settings.
    • Verified certificates and bound listener.
    • No Schannel or TLS errors logged.
    • NLA enabled vs disabled → still fails until we drop SecurityLayer entirely.
  4. What did work (but not sustainable):
    • Rolling back KB5065426 immediately restores RDP, SMB, printer sharing.
    • Disabling all RDP security (SecurityLayer=0, NLA off) temporarily restores access.
  5. Hypothesis:
    • Duplicate machine SIDs are being surfaced by new CredSSP/NLA changes in KB5065426 (and Aug preview KB5064081).
    • Servers and Win10 clients not impacted → seems specific to Win11 24H2 peer-to-peer auth.
  6. Ask:
    • Can Microsoft confirm if this is a known regression?
    • Will there be a fix or guidance (registry/workaround) without reimaging or sysprepping 160+ machines?
    • Is this going to be tracked on the Windows Release Health dashboard?
Windows for business | Windows Client for IT Pros | Networking | Network connectivity and file sharing

Answer accepted by question author

Matthias Carstens 85 Reputation points
2025-10-22T11:07:03.31+00:00

MS now decided that we worked wrongly all along, and that they don't need to inform anyone of such substantial changes before release.

https://support.microsoft.com/en-us/topic/kerberos-and-ntlm-authentication-failures-due-to-duplicate-sids-76f7394d-c460-4882-9ed1-d27e0960f949

Was this answer helpful?

1 person found this answer helpful.

Answer accepted by question author

Domic Vo 22,435 Reputation points Independent Advisor
2025-09-30T01:26:18.03+00:00

Dear Dustin Bernier,

Based on the environment you've described—Windows 11 24H2 (build 26100.6584 with KB5065426), cloned machines with shared machine SIDs, and failures in peer-to-peer RDP, SMB, and printer sharing—it does appear that the recent update may be surfacing a regression related to authentication mechanisms, particularly involving CredSSP and NLA.

Regarding your questions:

Known regression: Yes, this is under review. While not yet officially documented, your report adds valuable context.

Fix or guidance: We understand that reimaging or sysprepping 160+ machines is not a viable solution. Our engineering team is evaluating potential registry-based or policy-level workarounds that could mitigate the issue without requiring full reconfiguration.

Tracking: We expect updates to be published on the Windows Release Health dashboard once the issue is confirmed and a resolution path is identified.

Let me know how it goes, and if this answer helps, feel free to hit “Accept Answer” so others can benefit too 😊

T&B, Domic Vo

Was this answer helpful?

4 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Dustin Bernier 80 Reputation points
    2025-10-08T13:26:43.1266667+00:00

    It would make sense for Microsoft to provide a modern, reliable, and secure utility for changing or resetting SIDs. Implementing that before altering the authentication model would have prevented a lot of the current headaches.

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments
  2. James Imray 10 Reputation points
    2025-10-07T22:16:28.11+00:00

    This same update (KB5065426) stopped our machines RDC/RDPing to each other. Similarly, the issue was found to be that the machines had all been built and supplied to us with the same machine SSID. I found the easiest way to look up the machine SSIDs was in Powershell with the command "Get-LocalUser | Select-Object Name,SID" (without quotes and ignore the result from the last dash onwards).

    Uninstalling KB5065426 and pausing updates has worked as an interim solution. We are evaluating the implications of using a SID-changing tool like SIDCHG to change the machine SIDs. I understand it has less implications than running sysprep /generalize which "resets a lot of things".

    Can anyone from Microsoft please advise if this RDC/RDP problem will be fixed in a rollback/future update or do we need to live with the fact that going forwards we must ensure we don’t have any machines sharing the same machine SID?

    Was this answer helpful?

    0 comments
  3. bvsuser 0 Reputation points
    2025-10-05T11:43:31.67+00:00

    Will this regression be tracked here? Or where can I find information about the progress?

    Apparently this does not only hit cloned machines, but also installations that came preinstalled with the computer.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.