How do I enable SMB2 signing?

Windows NT 4.0 Service Pack 3 provides an updated version of the Server Message Block (SMB) authentication protocol, also known as the Common Internet File System (CIFS) file sharing protocol.

When SMB signing is enabled on both the client and server SMB sessions are authenticated between the machines on a packet by packet basis. This does have a performance hit of between 10% to 15% as every packet's signature has to be verified.

To enable SMB signing on the NT Server, perform the following:

  1. Start the Registry Editor (Regedit.exe)
  2. Move to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters
  3. From the Edit menu select New - DWORD value
  4. Add the following two values EnableSecuritySignature and RequireSecuritySignature if they do not exist.
  5. You should set to 0 for disable (the default) or 1 to enable. Enabling EnableSecuritySignature means if the client also has SMB signing enabled then that is the preferred communication method, but setting RequireSecuritySignature to enabled means SMB signing MUST be used and so if the client is not SMB signature enabled then communication will fail
  6. Close the registry editor
  7. Shut down and restart Windows NT.

By default a Workstation with SP3 or above is SMB signing enabled but to manually enable:

  1. Start the Registry Editor (regedit.exe)
  2. Move to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
  3. From the Edit menu select New - DWORD value
  4. Add the following two values EnableSecuritySignature and RequireSecuritySignature if they do not exist.
  5. Enabling EnableSecuritySignature means if the server also has SMB signing enabled then that is the preferred communication method, but setting RequireSecuritySignature to enabled means SMB signing MUST be used and so if the server is not SMB signature enabled then communication will fail
  6. Close the registry editor
  7. Shut down and restart Windows NT.

If you have set RequireSecuritySignature then any clients not support SMB signing will fail to communicate including logons and you may receive the error:

"Invalid user name or password..."

If you get this, check the workstation is SMB signing enabled.


Heya folks, Ned here again. Many years ago, we made configuring SMB signing in Windows pretty complicated. Then, years later, we made it even more complicated in an attempt to be less complicated. Today I'm here to explain the SMB signing rules once and for all. Probably.

Sign me up!

What is signing and why do you care

SMB signing means that every SMB 3.1.1 message contains a signature generated using session key and AES. The client puts a hash of the entire message into the signature field of the SMB2 header. If anyone changes the message itself later on the wire, the hash won't match and SMB knows that someone tampered with the data. It also confirms to sender and receiver that they are who they say they are, breaking relay attacks. Ideally, you are using Kerberos instead of NTLMv2 so that your session key starts strong; don't connect to shares with IP addresses and don't use CNAME records - Kerberos is here to help!

By default, domain controllers require SMB signing of anyone connecting to them, typically for SYSVOL and NETLOGON to get group policy and those sweet logon scripts. Less well known is that - starting in Windows 10 - UNC Hardening from the client also requires signing when talking to those same two shares and goes further by requiring Kerberos (it technically requires mutual auth, but for Windows, that means Kerberos). 

SMB signing first appeared in Windows 2000, NT 4.0, and Windows 98, it's old enough to drink. Signing algorithms have evolved over time; SMB 2.02 signing was improved with HMAC SHA-256, replacing the old MD5 method from the late 1990s that was in SMB1 (may it burn in Hades for all eternity). SMB 3.0 added AES-CMAC. In Windows Server 2022 and Windows 11, we added AES-128-GMAC signing acceleration, so if you're looking for the best performance and protection combo, start planning your upgrades. 

The confusing bit

This 20+ year evolutionary process brings me to the confusing bit: "requiring" versus "enabling" signing in Windows security policy. We have four settings to control SMB signing, but they behave and mean things differently with SMB2+ and SMB1.

  • Policy: "Microsoft network client: Digitally sign communications (always)"

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters

RequireSecuritySignature = 1 or 0

  • Microsoft network client: Digitally sign communications (if server agrees)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters

EnableSecuritySignature = 1 or 0

  • Microsoft network server: Digitally sign communications (always)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters

RequireSecuritySignature = 1 or 0

  • Microsoft network server: Digitally sign communications (if client agrees)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters

EnableSecuritySignature = 1 or 0

Note my use of bold. "Always" means "required." "If agrees" means "enabled." If I could go back in time and find out who decided to use synonyms here instead of the actual words, it would be my next stop after buying every share of MSFT I could get my hands on in 1986. 

These settings live here in the classic Security Settings of computer group policy you'll see by launching GPMC.MSC or GEPEDIT.MSC.

With me so far? Cool.

Understanding 'Required' 

The “enabled” registry setting for SMB2+ client and SMB2+ Server is ignored. It does nothing at all. It is pointless unless you are using SMB1. SMB2 signing is controlled solely by being required or not, and if either the server or client require it, you will sign. Only if they both have signing set to 0 will signing not occur. Again, SMB signing is always enabled in SMB2+. 

 

Server – RequireSecuritySignature=1

Server – RequireSecuritySignature=0

Client – RequireSecuritySignature=1

Signed 

Signed 

Client – RequireSecuritySignature=0

Signed 

Not Signed

Understanding 'Enabled' 

The legacy SMB1 client that is no longer installed by default in Windows 10 or Windows 2019 commercial editions had a more complex (i.e. bad) behavior based on the naïve idea that clients and servers should sign if they feel like it but that it was ok not to sign otherwise, known as "enabled", i.e. "if agrees". Signing is still possible in any case, nothing turns the signing code off. This is not a security model we follow anymore but everyone was wearing 1-strap undone overalls and baggy windbreakers at this point in the 90s and thinking they looked good. SMB1 also had the "required" setting, for those who wanted more strictness, and that will override the "if I feel like it" behavior as you'd hope. So we end up with this complex matrix. Again, it only matters for the SMB1 protocol that you are not supposed to be using.

 

Server – RequireSecuritySignature=1

Server – EnableSecuritySignature=1

Server – EnableSecuritySignature=0

Client – RequireSecuritySignature=1

Signed

Signed 

Signed 

Client – EnableSecuritySignature=1

Signed 

Signed 

Not signed 

Client – EnableSecuritySignature=0

Signed 

Not Signed 

Not Signed 

And another thing

The idea that the server should mandate these settings in either case isn't great either; it leads to attacks where someone intercepts the negotiation and says "nah, don't sign, you're fine". Which is why years ago we created pre-authentication integrity protection, UNC Hardening, and added the ability to require signing when mapping drives with NET USE and New-SmbMapping. All of this client-side security requirement is the proper technique, where the client decides it wants security and if it doesn't get it, closes the connection. Requiring Kerberos by disabling the use of NTLM and enabling UNC hardening will make things much more secure. In fact, I have a long article on all of this you should read once, then five times more: 

How to Defend Users from Interception Attacks via SMB Client Defense

The big sum up

If you really, really want to understand SMB signing, the article to read is SMB 2 and SMB 3 security in Windows 10: the anatomy of signing and cryptographic keys by Edgar Olougouna, who works in our dev support org and is a seriously smart man to be trusted in all things SMB. 

As for all these weird ideas we had around signing back in the late 90s - I wasn't around for these decisions but it's ok, you can still blame me if you want. At least I never wore the 1-strap overalls.

Until next time,

- Ned "I saw the sign" Pyle

How do I enable smbv2 signing?

How do I enable SMB signing?.
Start the Registry Editor (Regedit.exe).
Move to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters..
From the Edit menu select New - DWORD value..
Add the following two values EnableSecuritySignature and RequireSecuritySignature if they do not exist..

How do you check SMB signing is enabled?

The policies for SMB signing are located in Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.

Is SMB2 signed?

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. ... The Basics of SMB Signing (covering both SMB1 and SMB2).

What is SMB signing disabled?

SMB Signing Disabled is a Medium risk vulnerability that is one of the most frequently found on networks around the world. This issue has been around since at long time but has proven either difficult to detect, difficult to resolve or prone to being overlooked entirely.