SMB Sharing Fails on Windows 11 25H2

Question

In our business we have been using a mix of Windows 10 and 11 Pro for a while, with limited teething issues in the upgrade, however some recently upgraded servers (going straight to 25H2) are unable to access SMB shares between devices. This has been an issue in various departments working from various, direct upgrades, prepped images or clean installs. We're very confident that the cause of the issue is changes in how Windows 11 handles SMB shares, with no changes being made to security policies during this upgrade process.

When a share is accessed over the network the file explorer popup states the username or password is incorrect, no matter what is entered. When looking at the Event Logs if the password is correct, then the 4625 event has the details:

Status: 0xc000006d
FailureReason: %%2304
SubStatus: 0x0
TargetDomainName: -

When the password is deliberately incorrect the event logs show:

Status: 0xc000006d  
FailureReason: %%2313 (Unknown user name or bad password)
SubStatus: 0xc000006a
TargetDomainName: [name of server trying to access the share]

We've spent a fair amount of time investigating this issue and trying various security policies but with no luck. Is this an issue other people are seeing, is there a known fix that I've not been able to find?

Thanks

Answer 1

You’re right, this is a deeper issue that’s showing up on 25H2 systems and not just a simple signing mismatch. Based on what’s coming out from Microsoft and community reports, the root cause seems to be twofold: stricter SMB hardening and new SID validation introduced in recent cumulative updates like KB5065426. These updates enforce Extended Protection for Authentication and block NTLM fallback in more scenarios, especially when machines share identical or near-identical SIDs from cloned images. That explains why some systems work and others don’t, even with identical policies.

Two things worth testing: • Check if the affected machines were imaged without running Sysprep. Duplicate SIDs now break SMB and RDP authentication. If that’s the case, regenerating SIDs or re-imaging with Sysprep is the long-term fix. • If SID uniqueness isn’t the issue, try relaxing NTLM restrictions temporarily. In the registry under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, add or confirm NtlmMinClientSec and NtlmMinServerSec values (DWORD) set to 0x20000000 to allow NTLMv2 with 128-bit encryption. Also, check LanmanWorkstation for AllowInsecureGuestAuth if you need to test guest fallback.

Do you want me to give you the exact PowerShell commands and registry paths for these changes, plus a way to audit SID duplication across your fleet? Or should we focus on a workaround that doesn’t involve re-imaging?

Answer 2

I just found this. I haven't tried it yet and may be risky in a business setting but it may be promising: https://www.asus.com/support/faq/1054736/

Answer 3

Hi Sam,

Thanks for reaching out to the community. I can see how that would cause a real headache when everything worked fine before. The issue you’re seeing is tied to changes in Windows 11 25H2’s SMB authentication defaults.

Microsoft tightened security by disabling older protocols like NTLM fallback in some cases and enforcing stronger credential handling. That’s why even correct credentials fail and you see those 4625 events. First, check if the servers and clients are using the same SMB dialect and confirm that “Network security: LAN Manager authentication level” isn’t set to block NTLM completely.

Also, verify that the “Require SMB signing” policy isn’t mismatched between machines. If these look fine, try enabling “Allow insecure guest logons” temporarily to rule out policy conflicts.

Are these systems joined to a domain or using local accounts? And do you have any credential manager entries cached that might be interfering?

Let me know what you find.

Regards,

Rez