Configure SMB Signing with Confidence

Heya folks, Ned here again. Many years ago, we made configuring 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 signing rules once and for all. Probably.

Sign me up!

What is signing and why do you care

signing means that every SMB 3.1.1 message contains a signature generated using session key and . 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 . 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 -CMAC. In Windows 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 25 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 client: Digitally sign communications (always)”


RequireSecuritySignature = 1 or 0

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


EnableSecuritySignature = 1 or 0

  • Microsoft server: Digitally sign communications (always)


RequireSecuritySignature = 1 or 0

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


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 first 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”. 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. 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 Pyle


This article was originally published by Microsoft's ITOps Talk Blog. You can find the original article here.