Wednesday, August 17, 2016

The return of UNCHardenedPath problems.

Last week we rolled out some new GPO security settings which made our Windows 10 machines stop being able to process group policy changes.  First we noticed the GPP drive maps had stopped working and when we ran gupdate /force manually it failed citing that it couldn't access gpt.ini for
31B2F340-016D-11D2-045F-00C04FB984F9 (aka the Default Domain Policy).
While researching it we found many articles on how Windows 10 by default has UNC Hardenening enabled and the various patches (MS15-011, MS15-014) had affected many users in GPO environments.  We weren't using user filtering and all of our GPOs had Authenticated users listed with Read and Apply permissions so that wasn't it.  So for testing, we added the registry keys to disable Mutual Authentication on a laptop.

New-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths" -Name "\\*\SYSVOL" -Value "RequireMutualAuthentication=0" -Property "String"

New-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths" -Name "\\*\NETLOGON" -Value "RequireMutualAuthentication=0" -Property "String"

We were able to run gpupdate /force successfully after that but we didn't like that solution because that meant we'd have to manually update a lot of machines since even login scripts were broken at this point.  That and it just didn't make sense that Microsoft would have implemented all these security controls if they didn't work so we continued researching.  We found the next clue at the end of Sean Greenbaum's post - patch MS16-075 / KB 3161561 which was released in June and purportedly had caused issues for users trying to access SYSVOL shares.

The workaround listed was to set the SmbServerNameHardeningLevel to 0 under
on the domain controller servers.  That registry key corresponds to the GPO security policy
Ensure 'Microsoft network server: Server SPN target name validation level' is set to 'Accept if provided by client' or higher
which was one of the settings that we'd changed the week before.  Setting that to Off changes SmbServerNameHardeningLevel to 0.  Once that change was made on the Domain Controller GPO and applied, all of our client issues were resolved.

Ultimately this came down to insufficient testing on our part and it is one of the risks of trying to harden down existing systems.


No comments: