Heya folks, Ned here again. As part of a small series on esoteric SMB settings, today I’m going to explain how to control SMB client dialects in Windows 10 and Windows Server 2019.
Background
SMB Dialects are simply significant versions - just like dialects within human languages - that allow a client and server to agree on conversation behaviors. For example, the SMB 3.1.1 dialect came with Windows 10 and Windows Server 2016. These dialects allow assignment of various capabilities like encryption, signing algorithms, multichannel connections, etc. When the SMB client initially connects to a destination server, it negotiates the matched and required set of capabilities.
1. The SMB client says “I support all these dialects and capabilities”:
2. The SMB server responds, “Let’s use the highest one we both support, in this case SMB 3.1.1”
If you’re having trouble sleeping, I suggest reading our simple SMB2 NEGOTIATE spec.
Sheesh, our protocol docs...
Who cares?
There are times when you might want to require a minimum or maximum dialect, such as when using older networking equipment that might not understand later protocols. Or you might want to enforce the latest protocol for security reasons and not rely on servers to know what’s safest for clients.
Windows 1709 and later SMB dialect control
Starting in build 1709 (RS3) you get fine-grained control over protocol in the SMB client. When I say client, I mean a “computer acting as the SMB client”, not the Windows edition; this article applies equally to Windows Server.
There are two DWORD value names to create and modify values on:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
MinSMB2Dialect
MaxSMB2Dialect
The valid hex values are:
0x00000202
0x00000210
0x00000300
0x00000302
0x00000311
As you might have guessed, this is setting SMB 2.0.2, 2.1.0, 3.0.0, 3.0.2, and 3.1.1 dialects.
Important: SMB1 cannot be controlled here and you should have long since uninstalled it if Windows didn’t do it for you.
You set the MinSMB2Dialect to the lowest allowed dialect and the MaxSMB2Dialect to the highest allowed dialect. For example, this setting makes the client send only the SMB 3 family of traffic and prevents use of SMB 2.x:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
MinSMB2Dialect: 0x000000300
MaxSMB2Dialect: 0x000000311
They can also be equal – for instance, if you wanted to require just the absolute latest, most secure version of SMB, 3.1.1:
If you don’t set the MaxSMB2Dialect value, everything above the minimum will be negotiated; this is a good way to be future proof if we decided to make an “SMB 4” someday. These registry changes work on the fly for new connections, no reboot or service restart needed.
How it looks on the wire
Here I have forced only the SMB 3 dialect family. Notice now how instead of sending all the dialects in my negotiate request, I only send three now.
Here I have forced the SMB client to only use the SMB 2 family because I am using an outdated WAN appliance packet shaper that doesn’t support SMB 3. In this response packet, the server agreed to use SMB 2.1. Notice also how my capabilities have changed – I cannot use multichannel, persistent handles, directory leasing, or encryption anymore because SMB 2.1 doesn’t support those features.
You can use this dialect control to work with that WAN appliance temporarily until you update its firmware (and you’d better!)
Careful
If you mistype the values to ones that don’t exist, the SMB server will refuse the connection with error “Invalid Parameter”. Don’t do that.
If you set a minimum SMB dialect not supported by your servers, you won’t connect anymore, with error “not supported” and “network path not found”. Here I have forced my SMB client to only support SMB 3.1.1 then I connected to a Windows Server 2008 machine:
Don’t do that either.
Summary
I hope this clarified SMB’s dialect negotiation behaviors and maybe saved you come follicles someday. SMB is ubiquitous and isn’t just for Windows; both the Linux kernel and MacOS broadly used have built-in SMB clients. In the past 7 days alone, our Win10 telemetry observed 30 billion SMB connections. Understanding how it works is an extremely useful skill. I recommend simply running Wireshark or Message Analyzer and using SMB in your lab to understand what normal conversations look like. You can also read our complete robot-lawyer full on-the-wire specification if you enjoy pain.
Until next time,
Ned “parser” Pyle