Mark Minasi's Tech Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
DM-AVAL

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 81
Reply with quote  #1 
I posted a question about this on TechNet, referring to an article by Darren Mar-Elia, and then, realizing that there is a Group Policy section here (with his name mentioned), I thought I would ask my question on this forum as well (even though someone may have answered the question on TechNet - it can't hurt to confirm).

Essentially, it's a matter of determing whether the hardened path settings for NETLOGON and SYSVOL should be part of the default domain controllers policy (since those shares only exist on domain controllers) or part of the default domain policy.

(Or, alternatively, part of a separate GPO linked to either the domain or the domain controllers OU).

Here is the link to the Technet post:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/d97e1c83-b434-436e-9f53-f5d1d6a30fe6/group-policy-and-ms15011-default-domain-or-default-domain-controller-policy?forum=winserverGP#7b6ae2ad-f8ed-4513-ad5a-22153e119914

Here is the link to Darren's article:

https://sdmsoftware.com/group-policy-blog/security-related/understanding-jasbug-vulnerability-group-policy/

Thanks in advance!

 
0
gpoguy

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 50
Reply with quote  #2 
The policy that delivers the harden paths needs to be processed by clients that would be talking to the hardened paths. Even though DCs are technically clients to themselves for GP, the real target for this hardened path policy is all of your other clients/servers in the domain. So the ideal scenario is to put this setting into a GPO that is linked to an OU where your clients and servers reside. However, if that doesn't exist (i.e. all machines are on the Computers container) then putting the setting in the Default Domain Policy would do the job as well. Let me know if I can answer more there.

Darren

__________________
Darren Mar-Elia
MS-Group Policy MVP
Founder--SDM Software (https://sdmsoftware.com)
Need Group Policy Training? Check out my Group Policy Fundamentals course: http://pluralsight.com/courses/group-policy-fundamentals
0
DM-AVAL

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 81
Reply with quote  #3 
Thanks Darren.

I do have some follow-up questions.

In this article...

http://blogs.technet.com/b/askpfeplat/archive/2015/02/23/guidance-on-deployment-of-ms15-011-and-ms15-014.aspx

there is a section pertaining to clients (in the broadest terms - that could be servers here) applying Group Policy at different times.

There may be some clients that are not updated initially, or are but don't get the new GPO settings before the Domain Controllers are set to use them?

What happens then? Is there a chance that clients could no longer "talk" to the domain controllers?

The response to the question does not answer the question. It veers off into the subject of firewalls blocking Kerberos and WAN links. For arguments sake, let's assume everything is in a single AD site and there are high-speed links everywhere (LAN speed - 100 Mb/sec AT VERY LEAST). Let's also assume that no firewall, hardware or software, is blocking Kerberos traffic.

Is there a scenario where the GPO being applied "here but not there", could block communications between domain controllers and clients, notably concerning Group Policy?

Note: we are only planning to harden NETLOGON and SYSVOL at this time.

And yes, I have tested this with settings applied on the domain controller and settings not yet applied yet on clients. I run gpupdate /force on the client or reboot the client, then reboot a couple more times. No apparent problems.

So why am I even asking? Well, because the collective experiences of forum members here may have encountered a scenario that I have not reproduced in my testing and that I would want to be aware of.

Lastly, the group policy setting in question does seem to add an key to the registry...

HKLM\Software\Policies\Microsoft\Windows\NetworkProvider

When I remove the shares in the SHOW section of the group policy (there's a screenshot of this in your article, Darren), and THEN run gpupdate, this seems to eliminate the NetworkProvider key in the registry along with any subkeys or values.

So it seems that the registry is not "tattooed" in this situation. correct?

And that the recovery plan, if we had to back out of this change, would simply be to remove the settings (or disable the policy if we use a separate GPO for this) and then run gpupdate, locally or remotely?
0
gpoguy

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 50
Reply with quote  #4 
A few questions here so...

First, the order of application is not relevant here. In fact, applying this to DCs themselves, while thorough, sort of ignores the scenario this is trying to protect against. Essentially this prevents man-in-the middle or connection hijacking of communications between clients and SMB servers (in this case the SMB happens to be SYSVOL and NetLogon on DCs). Since DCs don't actually talk to anyone but themselves for GP processing, then hardening of SYSVOL and Netlogon is probably overkill. In addition, hardening of the DC has no interaction with the hardening on the client, so I don't think you have to worry about the latency of those GP settings getting out to all your clients. When it gets to the client ,then their interactions with the DC will be hardened.

To your other question, yes, because of where those network provider settings are stored in the registry, they will by definition not tattoo the system when the GPO is unapplied.

Darren

__________________
Darren Mar-Elia
MS-Group Policy MVP
Founder--SDM Software (https://sdmsoftware.com)
Need Group Policy Training? Check out my Group Policy Fundamentals course: http://pluralsight.com/courses/group-policy-fundamentals
0
downtime

Senior Member
Registered:
Posts: 108
Reply with quote  #5 
When I implemented this policy I placed the hardened path settings for NETLOGON and SYSVOL in a Custom Domain Controllers GPO AND Client PC GPO. There is no harm in adding to both GPOs. Mine has been running like this for a few months now.

BTW, I think it's good practice to never modify the default GPOs (Domain Controller or Domain). I would recommended creating new ones.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.