Partager via

The Basics of SMB Signing (covering both SMB1 and SMB2)

  • Article

SMB Signing Overview

Server Message Block (SMB) is the file protocol most commonly used by Windows. SMB Signing is a feature through which communications using SMB can be digitally signed at the packet level. Digitally signing the packets enables the recipient of the packets to confirm their point of origination and their authenticity. This security mechanism in the SMB protocol helps avoid issues like tampering of packets and “man in the middle” attacks.

SMB signing is available in all currently supported versions of Windows, but it’s only enabled by default on Domain Controllers. This is recommended for Domain Controllers because SMB is the protocol used by clients to download Group Policy information. SMB signing provides a way to ensure that the client is receiving genuine Group Policy.

SMB signing was introduced in Windows 2000 (at the time it was also ported back to Microsoft Windows NT 4.0 and Microsoft Windows 98). With the introduction of SMB2 in Windows Vista and Windows Server 2008, signing was improved by using a new hashing algorithm (HMAC SHA-256 replaced the old MD5). At that time, the settings were updated to simplify configuration and interoperability (you can find details later in the post). Another important improvement in SMB2 signing is performance. In SMB1, enabling signing significantly decreases performance, especially when going across a WAN. If using SMB2 plus signing with a 1GbE network and a modern CPU, there is limited degradation in performance as compared to SMB1. If using a faster network (like 10GbE), the performance impact of signing will be greater.

SMB1 Signing Configuration and Defaults

There are two main ways to configure signing for SMB1 clients and SMB1 servers. The easier one is set a Group Policy to configure it. This is, for instance, how domain controllers are configured by default to require signing. The other way to do it is using registry settings.  On each side (SMB1 client and SMB1 server), SMB1 Signing can be set to be “Required”, “Enabled” or “Disabled”.

Here’s a summary of the SMB1 Client signing settings:

Setting Group Policy Setting Registry Keys
Required Digitally sign communications (always) – Enabled RequireSecuritySignature = 1
Enabled* Digitally sign communications (if server agrees) – Enabled EnableSecuritySignature = 1, RequireSecuritySignature = 0
Disabled Digitally sign communications (if server agrees) – Disabled EnableSecuritySignature = 0, RequireSecuritySignature = 0

Here’s a summary of SMB1 Server signing settings:

Setting Group Policy Setting Registry Keys
Required*** Digitally sign communications (always) – Enabled RequireSecuritySignature = 1
Enabled Digitally sign communications (if client agrees) – Enabled EnableSecuritySignature = 1, RequireSecuritySignature = 0
Disabled ** Digitally sign communications (if client agrees) – Disabled EnableSecuritySignature = 0, RequireSecuritySignature = 0

* The default setting for signing on SMB1 Clients is “Enabled”.
** The default setting for signing on SMB1 Servers is “Disabled”.
*** The default setting for signing on Domain Controllers (defined via Group Policy) is “Required”.

The Group Policy settings are found under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.
Client registry keys are stored under HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLanmanWorkStationParameters.
Server registry keys are stored under HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLanmanServerParameters.
All registry keys are of type DWORD.

SMB2 Signing Configuration and Defaults

SMB2 simplified this configuration by having only one setting: whether signing was required or not. This can be configured via Group Policy or registry setting, on SMB2 clients and SMB2 servers. On each side, signing can be set to be “Required” or “Not Required”.

Here’s a summary of the SMB2 client and SMB2 server signing settings:

Setting Group Policy Setting Registry Key
Required * Digitally sign communications (always) – Enabled RequireSecuritySignature = 1
Not Required ** Digitally sign communications (always) – Disabled RequireSecuritySignature = 0

* The default setting for signing on a Domain Controller (defined via Group Policy) is “Required”.
** The default setting for signing on SMB2 Servers and SMB Clients is “Not Required”.

The Group Policy setting is found under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.
Client registry key is stored under HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLanmanWorkStationParameters.
Server registry key is stored under HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLanmanServerParameters.
All registry keys are of type DWORD.

SMB Signing Effective Behavior

There is a negotiation done between the SMB client and the SMB server to decide whether signing will effectively be used.

Here’s a summary of the effective behavior for SMB2:

Server – Required Server – Not Required
Client – Required Signed Signed
Client – Not Required Signed* Not Signed**

Here’s a summary of the effective behavior for SMB1 in current versions of Windows:

Server – Required Server – Enabled Server – Disabled
Client – Required Signed Signed Signed
Client – Enabled Signed* Signed Not signed**
Client – Disabled Signed Not Signed Not Signed

* Default for Domain Controller SMB traffic.
** Default for all other SMB traffic.

Older SMB1 Signing Behavior

A common source of confusion around SMB1 signing is the fact that older versions of Windows had a different signing behavior. That behavior was changed in 2008 to match the behavior of Windows Server 2008 and Windows Vista as documented at https://support.microsoft.com/kb/950876. Here’s a summary of the effective behavior for early versions of Windows Server 2003 and Windows XP (or older):

Old Server – Required Old Server – Enabled Old Server – Disabled
Old Client – Required Signed Signed Fails to connect
Old Client – Enabled Signed* Signed Not signed**
Old Client – Disabled Fails to connect Not Signed Not Signed

* Default for Domain Controller SMB1 traffic.
** Default for all other SMB1 traffic.

If you have an old SMB1 server or old SMB1 client, you should have it patched or updated to remove the possibility of failures to connect in a misconfigured environment.

Changing the SMB signing behavior

In general, it is recommended that you keep the default SMB signing settings. However, customers sometimes want to reconfigure SMB signing in specific situations. For instance, the customer could have the need to:

  • Increase SMB performance in Domain Controllers. It’s true that SMB signing will require additional processing for hash calculation, so you could increase a domain controller SMB performance by disabling the “Required” setting on Domain Controllers. However, we strongly discourage changing the default, since it will also expose your Group Policy to tampering and man-in-the-middle attacks.
  • Allow the use of WAN ‘optimization’ devices to speed up traffic SMB traffic between branch offices and head office by disabling the “Required” setting on Domain Controllers. Again, you’re trading performance for security. Although these devices could be legitimate, they essentially behave as a broker and would be in the position to relay obsolete group policy settings or even tampered ones (if compromised).
  • Increase the security for SMB clients or SMB servers that are not Domain Controllers. By enabling the “Required” setting on SMB clients or SMB server, you could force all SMB traffic to be signed. Signing all SMB traffic is not recommended because it will require additional processing (for hash calculation) and will decrease SMB performance.

If you decide that you must change the SMB signing settings, the recommendation is to use the “Digitally sign communications (always)” Group Policy setting. If you cannot do it via Group Policy, you could use the “RequireSecuritySignature” registry setting.

IMPORTANT: We no longer recommend using “Digitally sign communications (if client agrees)” or “Digitally sign communications (if server agrees)” Group Policy settings. We also no longer recommend using the “EnableSecuritySignature” registry settings. These options, which only affect the SMB1 behavior, can be effectively replaced by the “Digitally sign communications (always)” Group Policy setting or the “RequireSecuritySignature” registry setting.

References

Here are a few Knowledge Base articles (support) and TechNet articles that provide additional details on SMB signing. Please be careful interpreting these references, since some of them refer to the older SMB1 behavior.

 

P.S.: A quick note on SMB3

While there are changes in the crypto used in SMB3 for signing (SMB3 uses AES-CMAC for signing instead of HMAC SHA-256 in SMB2), the overall SMB2 behavior described in this blog also applies to SMB3.

 

P.P.S.: A note from Ned Pyle on 05/09/2017

Security is about security – either you want it or you don’t. Performance is irrelevant if security is paramount, and the penalty of app/transport protocols security is performance. Signing has been superseded by encryption in SMB 5 years ago, in case you are not fully up to speed on the options yet. Encryption performance in SMB 3.1.1 (Windows 10, Windows Server 2016) is actually much better than signing performance, and of course is much more secure.

You should review:

Comments

  • Anonymous
    January 01, 2003
    Everything here also applies to Windows 8. These features were first available in the Windows Server
  • Anonymous
    January 01, 2003
    Introduction The File Server team often talks to customers about file server migration and file server
  • Anonymous
    February 03, 2014
    Hi, I have been helping a customer with a tricky issue recently regarding slow network performance for
  • Anonymous
    April 30, 2015
    Pingback from SMB3 Networking Links for Windows Server 2012 R2 - Jose Barreto's Blog - Site Home - TechNet Blogs
  • Anonymous
    October 11, 2016
    What is the behavior in SMB1 if server keys are, Require=1 AND Enable=1 and the client server keys are, Require=0 and Enable =0?Signed or Fails to connect?
    • Anonymous
      December 31, 2016
      "If SMB signing is disabled at the client and enabled and required at the server, the client receives the "STATUS_ACCESS_DENIED" error message when it receives a response to a Tree Connect or Transact2 for DFS referrals."Source: https://support.microsoft.com/en-us/kb/887429
  • Anonymous
    January 17, 2017
    "Although these these devices could be" Repeated word.
    • Anonymous
      February 12, 2017
      Thanks for catching it. Fixed.
  • Anonymous
    September 26, 2017
    Enabling SMB2 signing on Windows Clusters appear to causes a brief drop in connection to Cluster Storage Volumes for passive nodes resulting in error c000020c. Anyone else seen this?I note that from KB 2008795:"When accessing a CSV volume from a passive (non-coordinator) node, the disk I/O to the owning (coordinator) node is routed through a 'preferred' network adapter and requires SMB be enabled on that network adapter"https://support.microsoft.com/en-gb/help/2008795/unable-to-access-clusterstorage-folder-on-a-passive-node-in-a-server-2