This blog post highlights a very specific detail of Microsoft’s implementation of SMB. It might help those, who try to get rid of SMB version 1 and support staff dealing with inaccessible file shares.
Summary for busy readers (tl;dr)
Windows 10 will offer SMB v1 when establishing a SMB session, even if SMB v1 is disabled. This allows the workstation (SMB client) to identify legacy systems which would only support SMB v1.
A server supporting only SMB v1 will elicit the message “System error 384” on the command line and a slightly misleading message in the Windows explorer.
Offering SMB v1 even if version 1 is disabled?
I know that SMB v1 is disabled on my workstation. Hence, I expect, that my workstation will not send out SMB v1 packets at any time. I was a bit puzzled when I sniffed an SMB session, since the workstation is still offering version 1 in the handshake:
A quick check in the registry showed, that I had followed all the steps described by Microsoft. One page worth a bookmark is “How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server” at https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and
Checking the configuration
Fearing that I did not properly follow the instructions I checked my configuration. Since SMB v1 is controlled by a registry entry the registry editor is the obvious way. One of the lesser known features of Windows is the “Service Controller”. This command line utility gives full control over drivers and services. It turns out, that SMB version 1 is really disabled:
C:\>sc query mrxsmb SERVICE_NAME: mrxsmb TYPE : 2 FILE_SYSTEM_DRIVER STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 C:\>sc query mrxsmb10 [SC] EnumQueryServicesStatus:OpenService FAILED 1060: The specified service does not exist as an installed service. C:\>sc query mrxsmb20 SERVICE_NAME: mrxsmb20 TYPE : 2 FILE_SYSTEM_DRIVER STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0
The Sysinternals Process Explorer (https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer) offers another way to check the configuration. When running with administrator privileges the Process Explorer can list the DLLs loaded in foreign processes. Pressing Ctrl-D will reveal all DLLs loaded in the selected process. “System” is a pseudo-process that represents the Windows kernel. Instead of DLLs we will see all loaded drivers. Guess what? MrxSmb10, which would handle SMB v1, is not present.
System Error 384
I was curious to find out, how my workstation would react to a legacy system. Here is the trace file:
The client offers SMB v1 in the negotiate protocol request. Not knowing about SMB 2 or later the server selects this dialect in the response in frame 21. The workstation repeats the negotiate protocol request and gets the same answer. At this point the client gives up and presents an error message.
On the command line we see a “System error 384”:
The Windows explorer unfortunately gives a somewhat misleading error message: