KB ID 0001461
Problem
I recently did a migration for an engineering company, about a week later I got an email from them to say, “We have a new Windows 10 PC, and it can’t connect to the ‘N’ Drive?” I asked them to send me a screenshot, the error was;
You can’t connect to the file share because it’s not secure. This share requires the obsolete SMB1 protocol, which is unsafe and could expose your system to attack.
Your system requires SMB2 or higher. For more info on resolving this issue, see: https://go.microsoft.com/fwlink/?linkid=852747
Some Googling told me that windows 10 (build 1803) had removed SMB1, and like most people who see this for the first time, I got thePowerShell to turn it on, client was happy end of problem right?
Well yes and no, ‘SMB1 is Bad‘, very bad in fact, enabling SMB1 is a bit like removing the windows from your house because your too hot, yes it solves the problem, but now anyone who wants to jump into your house can do so, at any time of the day!
OK What’s Changed?
With Windows 10 (Build 1803) SMB1 has been completely disabled. If you try and connect to a device/share that’s using it you will see the same error my client did.
However if you have an earlier build of Windows 10, and you simply let it update, (Including the 1803 July Security update), that will continue to work.
I tried to replicate this on my test network, like the client I had a 2008 R2 file server, and connected to it from a new Windows 10 and an old(er) updated Windows 10 machine. Everything worked? In fact to replicate the clients error, I had to manually disable SMB2 and force SMB1? That’s strange I thought, so I checked the clients server;
As you will discover (below) the DWORD highlighted disables SMB2 and forces the server to use SMB1. Now the server does not ship like this, and I doubt very much anyone did this manually, so where did it come from? Well as an educated guess, the software that runs on this server needs SMB1. (They have some older Linux machines and machinery that logs are collected from).
Solution
As Microsoft says;
Warning: We do not recommend that you disable SMBv2 or SMBv3. Disable SMBv2 or SMBv3 only as a temporary troubleshooting measure. Do not leave SMBv2 or SMBv3 disabled.
So the steps I outline below, are so you can actually do some troubleshooting, to see what’s wrong. The third law of engineering states ‘Just because you can do something, does not necessarily mean you should‘ That being said, I appreciate we operate in the real world. If your line of business software needs SMB1 you cant shut down production while the vendor fixes their ‘poorly written, and relying on 30 year old protocol‘ code. Or, what you are connecting to might not be a Windows machine at all! It might be an appliance tha’ts old, with no firmware to update it to SMB2/3, and there’s no budget to replace it.
Windows 10 Enable SMB1
Use the following PowerShell;
Get-WindowsOptionalFeature -Online –FeatureName smb1protocol Enable-WindowsOptionalFeature -Online –FeatureName smb1protocol
Again this is a temporary fix! As soon as possible disable it again.
Disable-WindowsOptionalFeature -Online –FeatureName smb1protocol
Windows Server (Enabling/Disabling SMB1 & SMB2)
As with most things, SMB status is set in the registry (see above).
Enable or disable SMBv1 on the SMB server;
Registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry entry: SMB1
REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled
Default: 1 = Enabled (No registry key is created)
Enable or disable SMBv2 on the SMB server;
Registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry entry: SMB2
REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled
Default: 1 = Enabled (No registry key is created)
Note: You must restart the computer after you make these changes.
But things are much easier done with PowerShell, to see the settings;
Note: Above SMB1 is enabled SMB2 is Disabled.
WARNING: To test this properly, I’d suggest converting this server to a VM and testing on a copy, or cloning the server, (if it’s already virtualised), then you can try out some non-destructive testing, to make sure your applications still work. Ideally start by enabling SMB2 and disabling SMB1 to test.
Remember to reboot!
If your application still works great, ‘you didn’t need SMB1 anyway‘, sit back, light your pipe, and admire your handiwork!
If not, try with both Protocols enabled. (To be fair, security-wise this is just as bad as having SMB1 only, as all the ‘good bits’ in SMB2 can still be bypassed by using SMB1!) But at least (from a user perspective) your new Windows machines will connect via SMB2.
Remember to reboot!
Related Articles, References, Credits, or External Links
NA
