Configure SMB Signing with Confidence

I apologize for the sarcasm here ahead of time.  But, I mean it in jest.  And I think I do have a valid point here. 

And I understand this is something that developed and morphed over the years.  But, it seems to me that the time has come for Microsoft to push SMB and SMB signing forward much further. 

Microsoft started implementing SMB1 in the 1990's and deprecated it in 2013.  SMB1 should be gone from all computers and servers by now.  It's been well phased out.  And network speeds are becoming less of a concern as the technology keeps getting faster and cheaper.  Same with storage drives and storage speeds.  SMB2 was introduced by Microsoft in 2006 with Windows Vista and Windows Server 2008.  SMB3 was introduced with Windows8 and Windows Server2012.  The year is now 2022.

I think it is now time for Microsoft to come up with better design and guidance regarding SMB and SMB signing.

The fact is, you should not have SMB1 on anything that is connected to an internet connected network.  You really should not have it at all.  If you have something that is dependent upon SMB1, it is time to upgrade that thing.  SMB1 should be eradicated.  And Microsoft should patch it out of existence.  Then, the following claim from your article above has more significance.  That claim is:

• "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."  

So, if that is true, and if SMB1 is eradicated from existence (Come on... its time folks) either by Microsoft or in your own environment, then why is Microsoft keeping these two registry entries around?  Can we delete these entries?  If we don't have SMB1 they are useless, right?  So, why keep them around still - which just keeps things unnecessarily confusing?

• HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters\EnableSecuritySignature = 1 or 0
• HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature = 1 or 0

If we have removed SMB1 and have only SMBv2+ then, can we delete these two entries above?  We should be able to since they are "completely ignored."  Right?  So - Can they be deleted?

Also, Microsoft seems confused about this themselves even with their own best practices in their official SMB articles online.  Microsoft's recommended "Best Practices" regarding enabling\enforcing SMB signing conflict with each other depending on where you read them.  It seems to go something like this (actual links below):

"Well...  Well...  Uh... it depends... Actually, No.  No.  Wait.  You should enable the two "If Agrees" options and disable the two "Always" options.  (even though that does nothing SMBv2+ according to Mr. Pyle's article above) [link to article below]

Or...  Wait.  Well, actually, you could just go ahead and require it for all Windows to Windows messaging and see what happens.  But, that might cause you some problems such as slowed communications and even possible outages.  It depends, on a number of things.  So... Yeahhhhhh... Good luck! ... Or...  Wait!  Actually... You know what...  Hold on... (scroll down)  [link to article below]

Example of the above:

Best practices  (1)

1. Configure the following security policy settings as follows:
   • Disable Microsoft Network Client: Digitally Sign Communications (Always).
   • Disable Microsoft Network Server: Digitally Sign Communications (Always).
   • Enable Microsoft Network Client: Digitally Sign Communications (If Server Agrees).
   • Enable Microsoft Network Server: Digitally Sign Communications (If Client Agrees).
2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client computers and prevent them from communicating with legacy SMB applications and operating systems.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj852239(v=ws.11)?redirectedfrom=MSDN#best-practices

... Well... Um...  Now that we think about it more, you should enable both of the "Always" options...  But...  Wait... Be aware that there could be some potential impact because of storage and drive speeds. ...? A faster drive can store data faster than a slower drive, just in case you didn't know that.  I mean.... What we are trying to say is that you probably will notice more of a negative impact by SMB signing on a faster network than a slower network... .... ?  (Blink... blink...)  Well... as long as you aren't using hard disk drives from the 1990's on your computers, which is why we mentioned drive speeds at the beginning above.  If the hard drives can't keep up with your fast network, then... you won't see that much impact.  Well, that is until you upgrade your hard drives to modern drives which are wicked faster.  Then your slow 1990 hard drives aren't a bottleneck anymore.  So hard drives could be factor also... if you have old hard drives from the 1990's on your servers and workstation.  (you really should upgrade those btw) 

What we really mean is... - There are a lot of things that you have to consider here.  It's all pretty confusing.  So, you're gonna have to just try it, if you want to, and see what happens.  So... uh... Yeah.  Good luck with that!  Cheers!" [links to articles below]

Example of above:

Best practice (2)
Enable Microsoft network client: Digitally sign communications (always)

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always#best-practice

Best practices (3) 
Enable Microsoft network server: Digitally sign communications (always).

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always#best-practices

Note that the very first part of  "Best Practice (1)" listed above conflicts with the last two: "Best Practices (2)" and "Best Practices (3)" listed above.  They literally give opposite advice for the "Best Practice".  Even Microsoft is confused on how to explain and recommend this stuff.

And your article above is helpful Ned.  I especially appreciate learning the "Understand Required" section where it says:  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.

A couple of things regarding this point above.  First, is there any official Microsoft documentation available that confirms this?  Don't get me wrong.  I am sure you are correct.  But, then again, why does Microsoft not have any official publications (that I can find) that states this?  Shouldn't they?  And if this is indeed true, why does MS keep SMB1 and those two registry settings (mentioned earlier above) around still???  Isn't it time to put all of that in it's grave?

And\or if this statement above is true, then shouldn't Microsoft's systems check for SMB1 and if SMB1 is not installed, but SMB2 or SMB3 + etc. is installed, then maybe MS could just grey out and\or delete those two options and registry keys since they are apparently obsolete if you don't implement the long deprecated SMB1.

And\or maybe Microsoft can create a tool to help admins analyze systems and their connectivity, and network speed, and drive speed, and SMB versions installed and come up with a recommendation for the settings.

I once inherited a situation where SMB1 once was in place and SMB signing not enforced.  It seems to me that in that situations like that admins have to address this on every Windows server manually because of all the "what ifs" and confusion.  Maybe on workstations also.  I just don't see Admins throwing a switch on this on company wide scale with a GPO roll-out and then crossing their fingers and hoping for the best.

But, that seems to be exactly what Microsoft is recommending.  I am surprised this archaic stuff is still around even now!

I think Admins deserve something from MS on this now.  It's time.  Time for change MS.

Is there a recommended and well-defined methodology (or a tool like mentioned above?) for implementing this in a production environment that takes into account that...you are implementing this in a production environment? 

That is one thing that I think MS overlooks when addressing things like SMB and SMB signing.  It needs to be done on production systems and admins need better guidance and lesser confusion than what Microsoft is giving them currently.

Make it more simple Microsoft.  The time has come.  These things have been deprecated for a good while now.  SMB1 will soon be deprecated for 10 years now.  Why are those two registry settings still there if they only affect SMB1?  Taking them out would make this a lot easier to understand (since they only apply to SMB1 but don't say that).  Take them out and put the onus to put them back in on anyone actually using SMB1 still for some reason.  SMB1 is the big outlier now.

The time has come MS.