Another reason not to completely disable SMB Signing on a server through GP

I have a post on this blog about creating a special GPO on SBS to disable SMB signing so that Macintosh workstations can access server shares. In that post, I present a solution that is contrary to what other folks in the community have suggested for a solution:

Create a separate GPO and do not modify the Default Domain Controller and Default Domain policies

Explaining this one is simple – by creating a separate GPO with the settings, you can “turn on” or “turn off” the settings by linking and unlinking the GPO in the domain. You can’t do that when you edit the default domain policies. If you want to “turn on” or “turn off” the settings for testing, you have to go in and modify the default policies each time you want to make a change. Plus, editing the default policies is a risk, because if you screw up something, there’ no “undo” feature, unless you’re smart enough to make a backup of all the GPOs in the domain before you go off and do any editing.

Only change the Microsoft Network Server: Digitally Sign Communications (Always) setting

By changing this setting, the server no longer forces all clients to use SMB signing, which would prevent the Macintosh from accessing SMB shares. With this change, those clients that do request SMB signing will still be able to communicate with the server over a secure channel.

So why not turn off everything so that all clients do not use encrypted communications at all? Well, this Microsoft KB article, You may receive an “Access denied” error message when you try to join a client computer to a Microsoft Windows Small Business Server 2003 domain by using the ConnectComputer Wizard, shows what can happen.

If you completely disable all SMB signing on the server, forcing all workstations to attempt communications without encryption, one of two things can happen. First, like the article above indicates, if you take that workstation and try to join it to another domain, or even try to log in and access shares on another domain controller (particularly problematic for laptops that travel between sites with different domains), and that other site requires SMB signing, the workstation will not be able to communicate. Its settings, based on the previous GPO, prevent it from being able to use encryption and thus cannot access the server.

The reverse is true as well. If you disable signing completely on a server, and someone brings in a workstation that, because of group or local policy, requires encrypted communications to the server, it will not be able to communicate with your server.

When I was first adapting this documentation for use with the MS whitepaper on connecting Macs to SBS, I ran my original setup past Damian Leibaschoff, one of the geniuses I worked with on the PSS (now CSS) SBS support team at MS, which did recommend making changes to both the (Always) and (If client agrees) settings. Damian explained to my why this was a bad idea, and so I changed it in all the places I had it documented. So, I present his argument here again.

So, is it the end of the world if you choose to edit the default domain policies instead of creating new GPOs to deal with SMB signing? No, but be prepared to try and recover from a completely dead network. One wrong move inside the default domain policies and you can kill your network in a hurry. Is it possible that you’ll never run into the scenario where completely blocking SMB signing on your network causes a problem? True, but be aware of the risks you take when doing so. You never know what new situation you might find that is a problem because SMB signing has been blocked completely on your server.