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. To...
Updated Nov 09, 2023
Version 14.0
Blog Post
Hi tdrob28,
With those settings this will be the signing situation:
* Pre-"SMB 2.0.2": signing will be enabled, but not required, which should be interpreted here as "sign whenever possible", so when the other party requires or enables it.
* From SMB 2.0.2 onwards: signing will be enabled, but not required, which should be interpreted here as "effective signing, when at least one party requires it". This means that if you configure your settings on every Windows client and server there will be no signing whatsoever among Windows systems, as not a single Windows system requires SMB signing. If your Windows system talks SMB with a non-Windows system (or a Windows system that's configured otherwise) which has SMB signing required, then your Windows system will use SMB signing.
("enabled, but not required" is a phrase I'm using here, it's not MS terminology.)
For completeness, this is the way it works for every possible situation:
Pre-"SMB 2.0.2" on pre-“Windows Vista SP1/WS08” | Server - required | Server - enabled, but not required | Server - disabled |
Client - required | J | J | - |
Client - enabled, but not required | J | J | N |
Client - disabled | - | N | N |
Pre-"SMB 2.0.2" on "Windows Vista SP1/WS08"+ | Server - required | Server - enabled, but not required | Server - disabled |
Client - required | J | J | J |
Client - enabled, but not required | J | J | N |
Client - disabled | J | N | N |
From SMB 2.0.2 | Server - required | Server - not required |
Client - required | J | J |
Client - not required | J | N |
(You can notice that the meaning of words differ, depending on the situation we're talking about. E.g., "Client - disabled" refers to another behavior in table 2 than it does in table 1. In table 2 it doesn't mean signing can never be happening, because it does when the other party requires signing!)
So to give you a summarized answer to your question: no, SMB signing is not turned off for SMB 2+ for your Windows systems with the settings you've written down, but in many cases signing will indeed not be used (although this depends on your environment of course: if your Windows systems talk most of the time with non-Windows systems which have SMB signing required, that's another story of course).
If you ALWAYS want SMB 2.0.2+ signing you need to enable "Microsoft network client: Digitally sign communications (always)" and "Microsoft network server: Digitally sign communications (always)". This also takes care of SMB signing for SMB pre-2.0.2, BUT some connections could fail on pre-“Windows Vista SP1/WS08” (not among Windows systems with this policy enabled, but with other (Windows or non-Windows) systems which have SMB signing disabled , as you can see in the table above. Be aware signing is not supported at all on pre-"Windows NT 4.0 SP3" & pre-"Windows 98" (SMB signing was backported to CIFS with these aforementioned Windows versions).
Look, make an inventory of your environment related to SMB (which systems have which SMB properties and which systems should be able to communicate with eachother through SMB) - don't be scared: sometimes such an inventory can be achieved quite quickly, depending on the scope, complexity, the view you have on it, etc. If you don't end up with systems with "really (100%) disabled SMB 1 signing", then you only need to enable the 2 "(Always)" GP policies. Otherwise you need to accept possible failed connections (which may be OK for some situations, e.g. when you shouldn't communicate with older systems at all through SMB, so when in practice this isn't an issue at all) or indeed loose the signing security a bit... I want to stress that the latter is only the ultimate expedience!
Regards,
Pedro