Configure SMB Signing with Confidence

Hi,

I've read the latest posts in this forum thread and would like to give my 2 cents 🙂

First of all, SMB 1 is still out there. Yes, it shouldn't be there anymore and yes, Microsoft should keep pushing to eradicate this old-fashioned SMB version. I completely agree. However, the fact is SMB 1 is still out there and we're not talking about exceptions; at the same time SMB is not a pure entertainment protocol, it exists mainly for "more serious" scenarios (which make it worse that it's still used, I agree...). Some companies and people should indeed really move on, but many others really have a hard time: they don't have a clue of what's going on and/or they just don't have the money and/or skills to upgrade. Smaller and/or poorer companies/people, especially in underdeveloped countries, can't just upgrade a NAS, old printer or medical equipment. They just can't (again, I agree many of them can and should do this, but even then many others keep behind). Let me repeat what I mean: everyone should do as much as possible to eradicate SMB 1 (including Microsoft!), but at the same time too many cases still exist where SMB 1 is still the harsh reality. Over time things will improve and yes, there will be a time where you can't just keep compatibility alive (even when this would mean a disaster to some...). Personally I think it's still too early, but I'm seeing light at the end of the tunnel already, especially in developed countries.

Secondly, Microsoft is evolving on this topic (yes, they are), starting from Windows 8.1/WS12R2 (making it possible to uninstall SMB 1; before you could disable SMB 1, but not uninstall it). In Windows 10 Version 1703 SMB 1 was even disabled (though not uninstalled!) by default. From Windows 10 Version 1709 & Windows Server, version 1709 it was disabled and uninstalled by default in a certain set of scenarios (depending on edition, clean install/upgrade, Insider/non-Insider and SMB 1 used/not used); if one needs more information on when exactly, please ask me and I'll post it here. Also, SMB client and server were now 2 different features in Windows (so if one could not be uninstalled, the other one could). With Windows 10 Version 1809 they even evolved more.

Thirdly, even if SMB 1 is disabled or even uninstalled, it's just impossible for Windows to check for the existence of thousands and thousands of registry entries just to determine they shouldn't be there anymore and thus be deleted. If they're there and they're useless, then they just keep sitting there. This is also the case for old SMB signing registry values. In theory such kind of auto deletion could be useful, although on the other hand this is not always the case: sometimes configurations are kept for when certain features would possibly be enabled later (you can see this a strength actually).

Number 4: yes, sometimes documentation and names are confusing. Sometimes this is because of historical evolution (BTW, renaming those things can be confusing as well, you know!), in other cases it's because of someone who has done a bad job 🙂 (but I understand everyone does this from time to time, although one person does this more than the other :-D).

Last, but not least: the 2 conflicting best practices. I can only agree. But... it's just not as bad as it sounds. The first link (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) tells us there are 2 possible best practices and come from a time where both were common as a best practice (the archived (!) page also mentions the targeted (older) Windows versions!). The other 2 links are for Windows 10 and modern Windows Server versions (as stated so on those pages) and in those cases/times the more strict possibility is now considered as the only best practice. I agree ideally this should have been clarified better, but IMHO it's not unlogical at all. Be aware that a best practice doesn't mean another solution can be the "right" choice: it depends on the exact definition of "best practice", but in reality I interpret this almost always as "best practice in mainstream/typical situations" and this can change over time of course.

Oh yes, one last thing: enabling SMB signing does have an impact on performance, whether you have old or modern resources. You should compare SMB signing enabled and disabled with the same set of resources in both cases. When enabling SMB 1 signing the performance hit is larger than with SMB2/3. I must say I don't really get what is meant with "slower performance on client computers when all policies are enabled" compared to the first best practice (I do understand the fact enabling every GP policy can introduce connection failures, depending on which older systems have which SMB settings and which systems should communicate with eachother over SMB; see my next post for more details on this) <= I'm talking about the first link here.

Regards,
Pedro