Demystifying the UNC Hardening Dilemma

Had an interesting issue come up today, and wanted to break it down a bit for my own understanding. A customer had a domain running DCs in Server 2008 R2 with a 2008 Forest and Domain Functional Level. Nothing wrong with this configuration as it is supported as of today, but was curious how hardening affected this older domain.

The problem statement: With 2 domain controllers both functioning, Windows 7 systems had no issues getting Group Policy. On the other hand, Windows 10 did have issues retrieving Group Policy.

So, first, about UNC hardening, or my take. Think of UNC hardening like a "trusted path, or source". For you devs out there, or even scripters, you've seen trusted locations before, where maybe scripts will not run because they were not in a "trusted location". Yes, I do miss running tests from my home directory and storing all my VB projects there. Don't judge, it was a different time. :)

Windows 10 by default enables this feature, and for good reason. It used to be that any UNC share was trusted without question, and with UNC hardening, you can protect code from running from sources you do not trust. What are some of the important shares? Let's just start with the domain controller shares and where Group Policy is applied: SYSVOL and NETLOGON.

There are 2 ways to set UNC hardening and its exceptions: Group Policy and Registry. Of course, keep in mind that if you are locked out of SYSVOL, you will see an error like the following when running gpupdate /force:
Computer policy could not be updated successfully. The following errors were encountered:
The processing of Group Policy failed. Windows attempted to read the file \\yourdomain.fqdn\sysvol\yourdomain.fqdn\Policies\{GPO GUID}\gpt.ini from a domain controller and was not successful.

Running a dir \\yourdomain.fqdn\sysvol will also result in the error: The network path was not found. You may also see an "access denied".

If the above applies to you, you will need to fix this via registry. First, there are 3 settings for hardening, allow me to briefly explain.

RequireMutualAuthentication (this can be set to 0 or 1): By default, SMB doesn't actually perform mutual authentication, but delegates this to the security provider of the remote system. If the remote security provider negotiates an authentication, then the connection is allowed. Of course, enforced by setting RequireMutualAuthentication to 1. This can be bypassed with 0 of course.

RequireIntegrity (this can be set to 0 or 1): This is where SMB signing comes into play - if you are still using SMBv1 (please don't), setting this to 1, for example, will disallow access to the path by requiring something the client cannot support.

RequirePrivacy (this also can be set to 0 or 1): This is where SMB encryption is set. SMB Encryption is only supported on Windows 8/Server 2012 and later, meaning setting this will break connections to Windows 7 systems. I found this to be a troublemaker when testing.

So, back to fixing the problem: If you had the above error trying to apply Group Policy, you can navigate to this registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths

You will need to set 2 entries (both REG_SZ)
1. \\*\sysvol
2. \\*\netlogon
with this value: RequireMutualAuthentication=0, RequireIntegrity=0, RequirePrivacy=0

Of course, replace yourdomain.fqdn with your actual domain's FQDN. In addition, these settings can be tweaked to fit your environment better. Do keep in mind that you will need to reboot after making this change, don't bother doing anything else. You should then be able to do your gpupdate /force successfully.

You may also set this in Group Policy, but keep in mind that changing this setting won't do you any good if you are not able to contact the DC and apply policy - so first things first, work the registry. The GPO setting is located at:
Computer Configuration / Administrative Templates / Network / Network Provider and the setting name is Hardened UNC Paths. Enable this, click Show, and add your shares and values here, i.e. \\*\sysvol as value name and RequireMutualAuthentication=0, RequireIntegrity=0, RequirePrivacy=0 as value.

Hope this helps demystify the reasons why Group Policy wasn't applying to these Windows 10 devices, but to the Windows 7 ones.

— If you like my blogs, please share it on social media, rate it, and/or leave a comment. —

Comments

• Anonymous
  November 30, 2017
  What I can't figure out is why the problem only occurs in one of our domain locations. We're using the same hard drive image, same username, and the troublesome W10 computers are in the same OU as the successful ones. Computers in one location work without the reg entries. In the other location, all of our tested computers so far have required them. The reg entries aren't a practical solution when people travel between the sites.
  • Anonymous
    January 02, 2018
    Charlie, I know this seems like a typical answer, but you may want to look into what policies are being applied between working and non working systems. I ran into a situation recently where 1 domain couldn't deploy an OS, only to find some odd batch file was being run in the deployment. Like I said, it seems like a basic answer, but removing policy for testing is a place I would start.
• Anonymous
  February 21, 2018
  Could you please tell me if the registry settings apply to the Windows 10 Computer or the Domain Controller or both ?
  • Anonymous
    February 27, 2018
    Hello Robert, good question. This is a client side setting.