I've been struggling for the past couple of days with SMB connections between two Windows 11 24H2 machines that replaced older systems. In our setup, we had two PCs in the manager's office that were set up for shared use, allowing a synthetic user to access each other's Desktop and Documents through shortcuts. This worked flawlessly on Windows 10. However, after upgrading to Windows 11, the PCs now get stuck in a credential loop when trying to connect to each other, even though they can connect to domain controllers and localhost without issue.
After setting up a lab to replicate the problem, I've confirmed that the machines are both in the same Organizational Unit (OU) and are configured with the default domain policies. Despite various troubleshooting steps like enabling computer account delegation, modifying Group Policy settings, disabling SMB signing, and verifying Kerberos tickets, I'm still hitting authentication failures. The event logs show Event 551 with a blank Username field, and I get Error 1326 when attempting to use the command with explicit credentials. It seems like some new security default might be causing this issue. Has anyone else encountered similar problems with Windows 11 24H2? I'm about to test with a Windows 10 client to see if the issue is specific to Windows 11 connections.
3 Answers
Can we break this down a bit? Just to clarify, are both machines domain-joined? Also, are they connected through wired connections or WiFi? And when you say synthetic user, is that like a generic account you're using? Are you trying to access the actual user account's desktop and home drive from the second computer or looking for a network share?
What version of SMB are these PCs running? It's crucial info for troubleshooting.
SMBv1 is disabled in the domain through GPO, but since it's a troubleshooting environment it shouldn’t affect this. It’s confirmed that both PCs are using SMBv2.
Are you trying to connect to the PCs by hostname or using a DNS alias? If it's the alias, you might have issues with SPN target name validation. Check the Group Policy setting for that. Also, look at the NTLM settings with the command 'Get-SMBClientConfiguration' to confirm NTLM isn't blocked. Turning on auditing for logons could help, too. When you check the logs, see if the connection attempts are being rejected for not being signed or encrypted.
I checked and NTLM is not blocked. The hardening level is at 0, but surprisingly, the auditing log isn't generating anything for my connection attempts, whether I use DNS or FQDN.
Yes, both machines are on the domain and are wired to the same subnet. It's a shared generic user account, and I'm mapping to the actual user paths on PC2's desktop and documents.