A Windows 11 PC can reach a shared-folder host yet still reject the sign-in. If the affected computers came from the same cloned image, duplicate machine security identifiers deserve a place in the investigation.
Confirm the cause before changing the PC. Similar errors can come from credentials, permissions, name resolution or SMB security requirements. When duplicate SIDs are confirmed, plan a supported rebuild rather than treating an in-place SID-changing utility as a routine fix.
This guide is for IT administrators investigating existing Windows installations. It explains what to collect, how to narrow the fault and where a controlled recovery plan is needed.
Why a previously working share can fail
A machine SID is part of Windows' local security identity. Cloning an installation without the required preparation can copy that identity to another computer.
Microsoft's duplicate SID advisory, KB5070568, identifies authentication failures on Windows 11 24H2, Windows 11 25H2 and Windows Server 2025 after updates released on or after 29 August 2025. It includes the September 2025 cumulative update KB5065426.
The update can expose an earlier deployment problem. An upgrade alone does not prove duplicate SIDs caused the failure, and this issue is not limited to workgroups or to a particular sequence of two Windows upgrades.
1 Record the failure before changing anything
Write down the Windows edition, version and build on both ends, the affected share, the time of a failed attempt and whether another authorised PC can connect. Record the exact error instead of repeatedly trying different passwords.
Useful clues include repeated sign-in prompts, a password error despite verified credentials, inaccessible shares and a message about a partial machine-ID mismatch. Compare the failed attempt with the System log: Microsoft identifies Local Security Authority Server Service event 6167 as evidence associated with this protection.
Keep the original logs in the organisation's approved support system. Crop or redact screenshots before sharing them more widely, especially if they contain usernames, server names or file paths.
2 Separate connectivity from authentication
From the affected client, an administrator can test the intended host's SMB TCP port:
Test-NetConnection -ComputerName FILEHOST -Port 445FILEHOST is a fictional placeholder; replace it with the approved server name. Microsoft's Test-NetConnection reference explains the returned diagnostic fields.
TcpTestSucceeded being True establishes that this TCP connection succeeded. It does not validate the account, share permissions, file-system permissions or every part of SMB negotiation. A failed test needs network-path investigation before a SID remedy makes sense.
Next, confirm that the user is signing in with the intended account and has the required access to that particular share. Workgroup, Active Directory and Entra-joined environments use different identity arrangements; avoid assuming that a successful Windows desktop sign-in grants access elsewhere.
Also check the server's supported SMB configuration. Windows 11 24H2 Pro, Enterprise and Education require inbound and outbound SMB signing by default. A third-party device using guest access or lacking compatible signing can produce a separate failure. Microsoft's SMB signing guidance recommends enabling compatible signing on the server and cautions against disabling it as a workaround.
3 Compare the actual computer SIDs
Use the official Microsoft Sysinternals PsGetSid tool through your organisation's approved software process. Run it locally on each affected computer without supplying a user-account argument, then compare the computer SIDs in the output.
PsGetSid can return either a computer SID or an account SID, depending on the arguments. Make sure the two results describe the same kind of identity. A local account name such as Administrator can be renamed or localised, which makes name-based shortcuts less reliable.
Matching computer SIDs establish a duplicate identity. Combine that finding with the failure timing, affected Windows builds and event evidence before concluding it explains this particular connection failure. If the SIDs differ, continue the authentication and permissions investigation rather than changing identities speculatively.
Do not publish the output or collect a whole network's account inventory just to test two affected machines.
4 Plan a supported recovery
For confirmed duplicates, Microsoft's permanent resolution is to rebuild affected devices using supported installation or imaging methods so each has a unique SID. Its advisory also directs organisations needing temporary relief to Microsoft Support for business for a special Group Policy. That exception needs an administrator's assessment and an agreed return to the supported configuration.
Before rebuilding, agree the maintenance window and recovery owner. Inventory required applications, local data, licences, access dependencies and the approved process for retrieving recovery information. Confirm backups can actually restore the required work. Osmicro's safe backup restore checklist explains how to test a sample without overwriting live files.
Pilot the remediation on an appropriate affected workstation where possible. Do not assume that changing the client is always harmless, or that changing a shared host is acceptable simply because it also has a duplicate identity.
Avoid unapproved SID-changing tools, security-agent shutdowns, bulk credential deletion and update removal as generic remedies. They can create further recovery or security problems while obscuring the original fault. Microsoft also says running Sysprep after an improperly cloned image has already been deployed does not bring that installation back into supported compliance. See its disk duplication policy.
5 Verify the result with real work
After the approved rebuild and configuration, confirm the machine identity is unique and the intended management and security controls are healthy. Then repeat the original access test using the approved server name and the intended user account.
Open a non-sensitive sample file. If the user's role includes write access, create and edit a disposable test file in an agreed location. Check that existing users still have the access they should have, and that the original failure no longer produces matching errors during the test.
If access still fails, preserve the new error and return to diagnosis. A unique SID does not correct an unrelated permissions, credential or server-compatibility problem. Close or remove only a specifically identified stale connection or credential when the administrator has established the need and impact.
Prevent another cloned identity
For future image-based deployments, Microsoft requires generalising the reference installation before capture. Its Sysprep generalisation guide describes the preparation workflow. Keep that work on a controlled reference image rather than improvising on a user's established PC.
Record the image version, deployment method and post-build checks. If a duplicate is found, review other machines created from that same source through an authorised inventory process. Test a representative deployment before returning the image to normal use.
Osmicro's managed IT services can help align workstation deployment, recovery and ongoing support. The practical aim is to establish the cause, restore access through a supported method and stop the same identity being copied into the next build.