1

A Windows 10 update introduced a security enhancement, where the windows 10 client is unable to browse to syslog and netlogon shares in order to prevent unintended access to these locations.

The symptoms would be that any attempt to access these shares from a windows 10 machine, the user is prompted for login credentials and not even the domain admin account would be granted access.

This can be resolved by adding the DC's UNC path (<\\DC_name>) to the Hardened UNC path within the local GPO editor of every windows 10 client, which can be located under

Computer Configuration > Administrative Templates > Network > Network Provider > Hardened UNC Paths

Now this is a working solution however it's not ideal, as we have 120 + clients (some of them at geographically remote sites), and it's not as convenient to do them manually, let alone the fact that defeats the whole purpose of opting for a domain controller for central client management.

When trying to push such setting from GPO there are 2 issues:

  1. The same GPO is not available in GP management console on server 2012 (DC).
  2. Since GPOs are pushed through the sysvol folder, and such folder is inaccessible (unless you do the fix manually), it's a rather impossible to push to client.

The desired outcome is where this issue is solved through the DC rather than from every windows client individually.

I look forward to help.

Thanks,

J

  • You need to provide more information. What errors are you getting? What have you already tried to troubleshoot the issue? – pat o. Feb 4 '16 at 14:13
  • 2
    Questions seeking installation, configuration or diagnostic help must include the desired end state, the specific problem or error, sufficient information about the configuration and environment to reproduce it, and attempted solutions. Questions without a clear problem statement are not useful to other readers and are unlikely to get good answers. – Daniel Feb 4 '16 at 14:21
  • Thanks for your response. I've updated the question with hopefully clearer answers to your questions. I'm not getting any error as the systems are working as they're intended, however the way this is setup it's quite inconvenient as it's preventing me from managing remote computers. – joebegborg07 Feb 5 '16 at 5:47
  • 1
    Is KB3000483 installed on the 2012 DC? UNCH was a hotfix for 2012 R2, so you won't have it as an option for GPO until that has been installed. – Clayton Feb 5 '16 at 22:02
  • Hi @Craig620 and thanks for your reply. I've installed the hotfix and the GPO was available. I've tried to push it to all users (by including it in the default domain policy), however the GPO still doesn't show up when executing gpreult on clients (following gpupdate /force). Any idea why ? – joebegborg07 Feb 8 '16 at 5:55
2

After further research it was determined that this was solvable by hardening UNC paths on clients manually. We used the following script for easier achievement:

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

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

This just applies the hardened UNC paths using command line rather than clicking your way through the local GPO. It's understood that a solution is a work in progress for this matter by Microsoft.

| improve this answer | |
0

You said you were putting the DC_NAME in the GPO as the hardened UNC. The examples in the KB are \\*\Netlogon and \\*\Sysvol. Probably not a good idea to use DC names, because those change, and clients may also use \\DOMAIN_NAME\Sysvol. If you are still using specific DC names in the UNCH GPO settings, that may be the problem.

Your original post never mentioned that you have a mix of 2012 and 2003 DC's. Sounded like you had only 2012 DC's. UNCH was never made avail for the 2003 OS.
Read the KB https://support.microsoft.com/en-us/kb/3000483

We determined that implementing these changes in Windows Server 2003 SP2 would require such comprehensive architecture changes that it would destabilize the system and result in application compatibility problems. We continue to recommend that customers who are security-conscious upgrade to our latest operating systems to keep pace with security threats and benefit from robust, modern operating system protection.

| improve this answer | |
  • Thanks for your feedback Craig. We've made further research and determined that this was a bug residing in windows 10 systems. I posted our workaround above. – joebegborg07 Feb 9 '16 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.