Heya folks, Ned here again. We recently made SMB signing the default in Windows Insider and Windows Server Insider builds. In doing so, we were quickly reminded of a consequence from an old unsafe SMB behavior that some folks still use: guest authentication. Today I'll explain all this and give you the steps to both fix and workaround the issue.
If you're in a hurry, skip down to the fixes and workarounds section below.
Signing and guest authentication
SMB signing ensures every message contains a signature generated using session key and cipher suite. The client puts a hash of the entire message into the signature field of the SMB header. If anyone changes the message itself later on the wire, the hash won't match, and SMB knows that someone tampered with the data. It also confirms to sender and receiver that they are who they say they are, breaking relay attacks.
To sign a message, the key is derived from a secret both the user client and server share - the user's password. Without that password, the client and server can't sign the SMB traffic because they have no way to validate the sender. And what doesn't a guest logon have? A password. That makes guest authentication and SMB signing mutually exclusive. When we see that the client requires SMB signing, we don't allow even an attempt at guest authentication, we just fail the connection.
Insecure guest authentication fallback
Microsoft stopped enabling the built-in Guest account years ago - Windows 2000! - and stopped allowing guest logons by default (keep in mind that the built-in Guest user and guest-type access are two different things). Later, we started actively denying the built-in Guest account the ability to connect to Windows clients remotely using any protocol. Starting in Windows 10 and SMB2+, we the SMB team stopped SMB2+ guest access in general as well as a particular behavior called insecure guest fallback. Besides blocking anyone from intentionally using guest with SMB2+, we also prevent an old SMB1 behavior where if you sent along a non-existent user, the SMB2+ server could then ask you to logon as a guest silently. Again, Windows SMB2+ servers would not do this, but you can see how a malicious attacker would love for you to connect to their evil file server and start executing evil file code without even needing a password.
Fixes and workarounds
Now, remember at the top where I said we recently made SMB signing the default in Windows Insider Enterprise client builds? When you try to connect to third-party devices that use guest for "ease of use", you'll get one of these errors:
- You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.
- Error code: 0x80070035
The network path was not found.
Even if you follow our steps in Guest access in SMB2 and SMB3 is disabled to enable guest in SMB again, they won't work. Because we disable guest access when you require SMB signing and you will receive error
- "System error 3227320323 has occurred."
But there are options:
Fix
The Microsoft recommended fix is to stop accessing your third-party devices using guest credentials. Anyone - anyone - who can see that device can access all your data without any password or audit trail. Device makers configure guest access so they won't have to deal with their customers forgetting their passwords or require a more complex setup process. These are unsafe places to store your personal or professional life. Many of these devices do have the ability to configure a username and password - consult your vendor docs. Others might have the ability with a software upgrade. And others might just be unsafe - for those, you should replace them with a trustworthy product and move all your data off the old device, ensure you wipe its drives clean, then recycle it.
Workaround
If you cannot disable the use of guest for your third party, you must disable the requirement of SMB signing. Obviously, this means that now not only are you using guest access, but you're also preventing your client from guaranteeing signing to a trusted device. That's why this is just a workaround, and we don't recommend it.
You can disable the SMB signing requirement three ways:
Graphical (local group policy on one device)
- Open the Local Group Policy Editor (gpedit.msc) on your Windows device.
- In the console tree, select Computer Configuration > Windows Settings > Security Settings> Local Policies > Security Options.
- Double-click Microsoft network client: Digitally sign communications (always).
- Select Disabled > OK.
Command-line (PowerShell on one device)
- Open an administrator-elevated PowerShell console.
- Run
Set-SmbClientConfiguration -RequireSecuritySignature $false
Domain-based group policy (on IT-managed fleets)
- Locate the security policy applying this setting to your Windows devices (you can use GPRESULT /H on a client to generate a resultant set of policy report to show which group policy is requiring SMB signing.
- In GPMC.MSC, change the
- Computer Configuration > Policies > Windows Settings > Security Settings> Local Policies > Security Options.
- Set Microsoft network client: Digitally sign communications (always) to Disabled.
- Apply the updated policy to Windows devices needing guest access over SMB.
Final thoughts
Now, we can make this easier to understand and are doing so in a future Insiders release. We'll have a better error message and better description in the group policy, and I'll also update our various MS Learn documentation on signing and guest access. But I mostly hope everyone will stop using third party devices with guest access - they are dangerous.
Reminder: with SMB1, all bets are off. None of what I mentioned above will stop guest access or myriad other unsafe behaviors. If your SMB server device still requires SMB1, you should assume anyone can access its data; even with a strong password, even without guest, even with SMB signing enabled. If you're unsure if your device requires SMB1, review its documentation and the Still Needs SMB1 product clearinghouse.
Don't invite them in!
A scary vampire shadow on a staircase from the 1922 film Nosferatu
Until next time,
Ned Pyle
Microsoft
