Understanding SMB2+ dialects and controlling them in later versions of Windows 10 and Windows Server

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

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

Understanding SMB2+ dialects and controlling them in later versions of Windows 10 and Windows Server

Hi Zenhawk219,

Yes, you can do SMB mandating for the SMB client with the purpose of achieving SMB 2.0 as the negotiated SMB version. Set the minimum and maximum to 2.0.2 (as 2.000 isn't supported here, although typically this doesn't matter, as 2.000 is only available in Windows Vista RTM):

• Minimum:
  • Hive: HKEY_LOCAL_MACHINE
  • Key: SYSTEM\\CurrentControlSet\\Services\\LanmanWorkstation\\Parameters
  • Named value: MinSMB2Dialect
  • Value type: REG_DWORD
  • Default: named value doesn't exist (= existing with the lowest value supported by the Windows instance in casu)
  • Remark: explicit minimum value = 0x00000202 => this is SMB 2.0.2, so you can't set it lower than SMB 2.0.2!
• Maximum:
  • Hive: HKEY_LOCAL_MACHINE
  • Key: SYSTEM\\CurrentControlSet\\Services\\LanmanWorkstation\\Parameters
  • Named value: MaxSMB2Dialect
  • Value type: REG_DWORD
  • Default: named value doesn't exist (= existing with the highest value supported by the Windows instance in casu)

Be aware that the SMB server should at least support 2.0.2, otherwise this won't work of course.

Grtz,

Pedro

Helo Team,

I am want to change the SMB Dialect in SMB Client is it possible to do so .?

Whenever I am mapping the drive it's getting Dialect 3.1.1 I want SMB 2.0 Dialect version let me know how I can get this .

Regards,

Faizan

Zenhawk: you can do SMB dialect mandating at the SMB client level since Windows 10 Version 1709 and Windows Server version 1709 (so including WS19). You can set a minimum and maximum SMB version number, for example 3.0.2-3.1.1. This way you can avoid SMB 3.0, although you also prohibit lower versions at the same time.

If your intention however is to do this mandating at the SMB server level (on Windows client and Windows Server), it's indeed not possible, just as Ned already said. However, if you can do mandating for every system that can access a certain SMB server, the mandating is de facto in place for the SMB server as well. For example, suppose you have an environment with a WS19 server, where the only set of systems able to access its SMB server are W10/WS Version 1709+ or W11 systems, then you could configure the mandating on these systems so that SMB 3.0 will never be used by the WS19 SMB server. But this is no hard configured SMB server way of course, so pay attention (e.g., if a new system without mandating set joins that set of systems, the situation can change of course, possibly introducing SMB 3.0 again!).

Zenhawk Do you mean you want the server to control the dialect, not the client? That's not currently possible. 

I want to restrict the SMB connection Dialect 3.0 in windows server 2019

Is there any specific workaround for this .?

Regards,
Faizan

PadrePedro 

1. Yes

2. No news. I have a work item for the future but we are recently down two devs and have a lot of other priorities to meet right now

Hi Ned,

Once again a great article!

2 questions:

1) I guess this SMB client dialect mandating is also supported from Windows Server version 1709 onwards (and not only from version 1809/WS19)? Just asking to be sure 🙂

2) Do you already have news about the SMB server dialect mandating nltest has requested (see the previous 2 comments)? I just want to keep the pressure high! 😄

Thank you!

Regards,

Padre Pedro

Just the client. It's a worthwhile feature to add though, I will noodle on this.

Hi Ned, cool article!

I have a query:

Is there a way to Control SMB Dialects that the SMB Server exhibits in the response to client's request?

eg. If I want to enforce SMB3.1.1 in my home network, is there a way to specify the SMB Dialect on the SMB Server without modifying the clients? 

SebastianF1200 That's RS1 and won't support this feature. You'd need RS3 (aka Window Server Version 1709, a semi-annual channel release) or Windows Server 2019 & later.

Sorry for long delay, I was on vacation 😕