The Microsoft SMB1 file protocol is old, has vulnerabilities and deserves to die.

So we tried to remove it from our Windows 7 desktop fleet.  Like any good removal, we piloted it, and we found it broke connections to Samba file servers.

Will no one rid me of this turbulent piece of software?

So I left the Windows 7 desktop fleet alone.  We were getting ready to deploy Windows 10, and I thought “Here’s an opportunity for a clean slate”.

We started deploying Windows 10, and the calls started to roll in.

“Our network drives no longer work.”

This time, we were better prepared.  Instead of 100% of the desktop users getting the SMB1 protocol turned back on, we have only enabled it for the 5% of desktop users who actually need it.

Going though the backlog of things to log about, I found this from 2014.

Hello Bill,

The issue you are seeing is because your SAMBA File Servers are not part of our Active Directory Domain.

So the SAMBA shares folks are connecting to are not within the MSWINDOWS domain, there is no trust relationship between MSWINDOWS and your SAMBA workgroup/domains.  Microsoft Windows by default will always attempt to connect or reconnect with the logged-in users domain credentials (ie. MSWINDOWS) first, IF you do not supply your Samba domain\user credentials.

Lockout occurs from your end when a certain number of incorrect authentication attempts are detected.

So what you should do is map your SAMBA network drives as a different user from Windows explorer, explicitly specifying the Workgroup (“SAMBAPC\userid” in the case of shares to SAMBAPC) or domain (“SAMBADOMAIN\userid” for everything else) for the relevant user.

If this is done it generally avoids the issue.

Still true 4 years later.