Windows 10 workstation Group Policy errors

[Metanis]

While troubleshooting Windows 10 related Network Browsing issues (documented at https://www.technibble.com/forums/t...orking-smb-configuration-in-windows-10.68432/ ), I also discovered my new Windows 10 workstations were experiencing consistent problems applying domain group policies.

My primary Microsoft domain controller is a 2008R2 box. My Windows 10 workstations had been in-place upgraded from Windows 8.1 and I know that Group Policy was working fine at one point because I use WSUS and it is configured on the workstations via a domain-wide group policy.

My initial troubleshooting led me toward network authentication issues because of the 1058 error I would see in the event logs. The 1058 error points in 3 different directions. Since I was already having network browsing issues I initially tried to resolve the problems with SMB versions.

After fixing the SMB and network browsing issue, my group policy problems were still not resolved. So I endeavoured to confirm and verify my DNS environment. (I do a lot of experimentation with different Servers so there were some Active Directory metadata issues to resolve.) But eventually a "dcdiag /testNS" on my domain controller displayed clean. But it still didn't fix my group policy issues.

The next logical step was obvious but I missed it at first. But eventually I removed the workstations from the domain and rebooted. Then I changed the machine's name and rebooted, finally I put it back in the domain and rebooted again. This cleaned up some old "stuck" policies, but I still wasn't getting the current domain policies. My error message when using the "gpresult /H gpreport.html" command-line option changed however. It no longer report authentication issues, it now reported "network path not found"! So I had moved the problem a bit farther down the line.

That was the clue which allowed me to find the issue with "hardened paths". It seems Microsoft had a security vulnerability with Group Policy being spoofed. They quietly fixed it in early 2015 with a feature called Hardened Paths which tries to ensure your group policies can only be provided by a properly authenticated domain controller.

At this point I don't know or even care why, but my 2008R2 server cannot properly handle "hardened paths". The temporary (maybe permanent) fix is to turn off the feature on each server and workstation. This is done by creating 2 registry keys and then restarting the boxes.

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\SYSVOL" /d "RequireMutualAuthentication=0" /t REG_SZ /f

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\NETLOGON" /d "RequireMutualAuthentication=0" /t REG_SZ /f

In conclusion, my network is back to 100% after enabling all 3 flavors of SMB, disabling the Hardened Path option, and (workstation only) removing, renaming, and rejoining the domain. I'm just throwing this out here in case it can help someone else.

 

[Jonathan Shapiro]

Thanks for a great article. I bumped into something very similar with my laptop. In my case when GP wouldn't refresh, I looked at the servers closely to make sure there were no issues. Of course 650 other people process policy just fine, so I kind of figured it wasn't a server issue. It was really vexing because I could open any policy folder from Explorer just fine. I used procmon to monitor my machine while doing a gpupdate. I noticed the update runs in the context of NT AUTHORITY\SYSTEM. That's when I realized that SYSTEM may not have permission. To test this theory, I used PSEXEC to open a command prompt on my machine in the SYSTEM context. This is what I found:

DIR \\domain.local\sysvol would throw an error about bad username/password.
DIR \\domain.local\netlogon would throw an error as above.
DIR \\domain\sysvol would return a listing
DIR \\domain\sysvol would return a listing

ping domain.local would yield an IP address of a local DC.

DIR \\ip address\sysvol would return a listing
DIR \\DC Name\sysvol would return a listing

I used Wireshark to monitor the failing directory listing and it seemed to be Kerberos error.

I tried everything you published in your article, and nothing helped.

Just for fun, I got the idea this morning to try this from my System command prompt:

net use \\domain.local\sysvol

Then I supplied my credentials.

This command completed successfully.

Now I tried my DIR tests again as above. Everything worked!!!

I tried a GPUPDATE, and that now worked.

I rebooted my machine a few times, and my machine was still processing policy with each reboot. I kind of expected that I'd have to repeat the above with each restart. Somehow, the above seems to have squared away the trust issue for the SYSTEM account on my machine. I spent days on this, and I cannot believe this.

 

[Metanis]

[QUOTE="Jonathan Shapiro"[/QUOTE]

Do you know what might have caused the problem in the first place? Malware or other exploit attack?

 

[Jonathan Shapiro]

I actually don't know exactly when policy stopped processing. I ran a gpresults report in the beginning, and it led me to believe it last processed policy in late April. I pull weekly image backups of my computer, so after I exhausted other ideas, I rolled it back to an image from 2 months ago. I had to disjoin/rejoin it to the domain, but policy still didn't work, and my machine was now 2 months back in time. I decided to roll it forward to my most recent image and keep digging. I came across several articles including the one here talking about hardened security and mutual authentication issues for the SYSVOL and NETLOGON folders. I tried everything in this article too. It sure sounded like my problem, except in my case only the SYSTEM account couldn't get to the SYSVOL area and only when using the fully qualified domain name \\domain.local\sysvol. My monitoring tool showed that that is how a GPUPDATE accesses the share. Anyway, it is almost 24 hours since I made the tweak, and GP is still refreshing okay.