Change in GPO Processing

  • 336 Views
  • Last Post 28 June 2016
a-ko posted this 16 June 2016

 https://support.microsoft.com/en-us/kb/3163622 MS16-072 changes the way user policy objects are accessed. They are now accessed via the machine’s security context, not the user context. Which means if you’ve been using security filters for user policies, these policies will no longer be applied to the system unless you perform the included fixes. This is a pretty big change. Goes back to why I recommended against using GPO Security Filters unless absolutely necessary…. -Mike C

Order By: Standard | Newest | Votes
Ravi.Sabharanjak posted this 16 June 2016

Will the security filtering still be honored though, if you have the authenticated users / domain computers with read permissions on a gpo that is filtered to certain user groups?
in this situation, will the machine read the policy, and then determine whether to apply settings based on the user's group memberships?
thanks,-Ravi

show

a-ko posted this 16 June 2016

I’m going to guess probably, based on what the change says. I am only uncertain because I haven’t run into the issue myself and have no real inclination to test. I’ll be auditing work environments tomorrow… 

show

kennedyjim posted this 16 June 2016

Yes.  The retrieval is in machine context, but application is still in the user/group context. I experienced the issue, the fix works and users are being properly

filtered.

 

show

SamErde posted this 16 June 2016

My team has also confirmed that GPOs with user security filtering are processed correctly if Authenticated Users has Read permissions added after security filtering is applied. Thankfully this is something that we already had in place, as it makes troubleshooting and RSOPs easier to read.
I think I smell blog posts being cooked up from the AD team, Darren Mar-Elia, and Alan Burchill, just to name a few. :)
Sam


show

ahobbs posted this 16 June 2016

Which fix did you apply?
Adding Domain Computers with Read Permission?
Sent from my iPhone


show

SamErde posted this 16 June 2016

No, you just need to add Authenticated Users with Read permission.


show

kennedyjim posted this 16 June 2016

Yes, this is what I also did.

 

show

ahobbs posted this 16 June 2016

So applying Authenticated Users with Read permissions to all GPOs will fix the issue irrespective of whether security filtering is used?
A
Sent from my iPhone
On 16 Jun 2016, at 13:21, Sam Erde <samuel.erde@xxxxxxxxxxxxxxxx> wrote:
No, you just need to add Authenticated Users with Read permission.


show

kennedyjim posted this 16 June 2016

Correct.

 

show

darren posted this 16 June 2016

You don’t need to change the ACL if you are not using per-user sec filtering on a given GPO, since Authenticated Users is already there by default. I did indeed blog post and

write a script to remediate this so have a look here:

https://sdmsoftware.com/group-policy-blog/bugs/new-group-policy-patch-ms16-072-breaks-gp-processing-behavior

 

In general, I would say it’s better to apply a Domain Computers ACE if you have to apply a new permission, because it limits the read exposure, but yes, Authn Users Read permission

works as well and that’s what my script does by default.

 

Darren

 

show

a-ko posted this 16 June 2016

I’ll copypasta what I posted on another forum where we’re discussing this… Limiting the scope doesn’t really matter from a security perspective. Group Policy Objects change Registry settings. Registry is read access to all users of a system. (this includes application accounts, local accounts, built-in accounts, non-privileged, etc.) Computer accounts are far more likely to get compromised than user accounts. When a piece of malware takes over a computer (and gains SYSTEM privileges on the box through EOP), it now has access to the network based on whichever permissions the computer object has. The risk for “authenticated users” versus “domain computers” is not really that big of a deal. 

show

darren posted this 16 June 2016

I’m not sure I follow Mike. Group Policy does more than just change registry settings, but regardless, the decision of choosing Authn Users vs. Domain Computers is one of discovery

scope. Any process running as any domain user has the ability, by default, to read

every GPO, regardless of whether the user/computer has processed it or not. Many shops, recognizing that this means that security posture is wide open to be discovered to any UN-privileged user, have chosen to remove Authenticated Users read from many

of their security-related GPOs to prevent this discoverability. Adding that ACE back then undoes this. However, using Domain Computers does not do this, unless, as you point out, someone is running as LocalSystem. I would also argue that if malware has localSystem,

all bets are off for both computer or user, so it’s a bit irrelevant. PtH, for example, is about exploiting privileged user creds to move laterally, rather than machine creds. But in either case, no, this change would not matter in an exploit scenario.

 

Darren

 

show

g4ugm posted this 16 June 2016

This sounds like a “security by obscurity” thing. What you are saying is you don’t want authenticated users to read policies. Once they are applied you have no choice as they are in the registry Dave 

show

a-ko posted this 16 June 2016

I just don’t see the issue. And limiting “discovery scope” is not something that anyone has identified as a true problem except in specific high security scenarios where you’re implementing Mandatory Access Control (read: SELINUX)—but in a Windows environment this is almost guaranteed to break things so it’s best not to touch ACLs unless you know exactly what you’re doing. I always generally recommend not removing privileges from objects. In this case, the tool lets you—but you wouldn’t bother with it if you didn’t have an interface to do so. It’s not like you would go through ADSI Edit and start changing security permissions on AD objects (typically because ADSI Edit scares most people that use AD) if MS didn’t expose this functionality through GPMC. The behavior has changed from a GPO processing standpoint. And now requires you to do other things. While “Domain Computers” would work, it’s marginally no better than leaving it as the default “Authenticated Users”. There’s nothing in your GPOs that should be considered “secure information”. -Mike 

show

darren posted this 16 June 2016

Well it’s beyond obscurity, because you are using real security to permission access to a resource on a need-to-know basis. Not every GPO applies to every user/computer in

the domain so the argument that it’s in the registry is not necessarily true. So, by granting authenticated users read access to every GPO by default, it’s no different than saying that you’re going to give everyone read access to that Word doc that holds

everyone’s salaries.

 

Still, I will admit, of all the things you can do to protect the security posture of your environment from being discovered, this is probably low on the list.

 

Darren

 

show

kurtbuff posted this 16 June 2016

So, just to pop in this thread and ask a question....

I had audited by hand all of the user-focused GPOs, and only one of
them didn't have Authenticated Users with Read permissions, so I fixed
that.

However, I ran the script from here:
https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/
and a substantial fraction of the GPOs that are applied to machines
(no user settings in them) don't have Authenticated Users - and many
of them do use security groups for filtering.

This raises the question in my mind (and I think I know the answer,
and I believe it's negative, but I pose it anyway) if I grant Read
permissions to either Authenticated Users or Domain Computers, will
computers not in the nominated security groups all of a sudden start
applying those GPOs?

The thing I do notice is that the groups used for security filtering
already have Read permissions on their respective GPOs, so I want
clarification, just to be sure...

Kurt

Kurt

show

kennedyjim posted this 16 June 2016

"if I grant Read permissions to either Authenticated Users or Domain Computers, will computers not in the nominated security groups all of a sudden start applying those GPOs"

No, because Read does not allow Apply. There is a specific check box to allow Apply, don't check it.


That said I do not know if this change applies to computer GPO's. The only reports we have so far are for user GPO's. You should test, apply the update to a machine that is currently in the scope of these filtered GPO's.

Let us know how it goes. :)

show

a-ko posted this 16 June 2016

The problem only affects user policies.

Machine policies are fine since those were already previously accessed via the machine context.

Though I still would review using security filters....it's REALLY not the best practice..

show

kurtbuff posted this 16 June 2016

That's exactly what I thought.

I might have to gin up a dummy GPO and use that for testing, if I have the time.

Kurt

show

kurtbuff posted this 16 June 2016

Following your advice on using OUs instead of security filtering would
make our OU structure much more complicated.

For instance, within a single department, I have staff with laptops,
and those machines must have bitlocker and directaccess policies
applied, but I don't want those GPOs applied to the desktops.
Additionally, some machines in each department are nominated as test
candidates for patches via WSUS - the test candidates get patches
immediately after release, and the others get them a week later,
assuming no problems arise.

But, that means, with the conditions I've outlined, going from one OU
for each department's computers to, at a minimum, 4 OUs, and that
doesn't include other circumstances.

I think the explosion of OUs for taking into account each of those
(sometimes overlapping) cases would make things harder to manage.

Kurt

show

a-ko posted this 16 June 2016

OUs were kind of designed for this, though.

I think there's a general recommendation against deep OU nesting but I'm not sure what the technical reasons for that are...

show

jheaton posted this 16 June 2016

Ok, so let me pose this, and have you tell me how I "should" be doing it.

I have login policies done through GPO. I have an OU, that covers Northern California, which has multiple offices. Each office has its own server, and I want the users in that office to map to their local server. We've done this by creating separate GPOs, and applying them to security groups of people in the different offices, through Security Filtering.

How would you accomplish this? And don't say DFS, because we are actually going down that road, just not there yet.

show

dddugan posted this 16 June 2016

Single GPO with group policy preferences?

show

kennedyjim posted this 16 June 2016

Or a Northern California OU with a sub OU for each office under that. The drive mappings just hit those office OU's, the common ones hit the N CA OU. Or keep doing it the way you are, it is perfectly acceptable and is referred to as a best practice and/or suggested by MS in lots of places. Here are a couple.

https://technet.microsoft.com/en-us/library/cc779168(v=ws.10).aspx

https://blogs.technet.microsoft.com/grouppolicy/2009/07/30/security-filtering-wmi-filtering-and-item-level-targeting-in-group-policy-preferences/

show

SmitaCarneiro posted this 16 June 2016

If you're referring to item-level targeting, that is querying AD, would that not add a delay in processing?

Smita

show

SamErde posted this 16 June 2016

My short answer would also be a single GPO with preferences for each site. I'm also curious if the op has different AD sites set up for each physical site that he is trying to achieve this at.


show

jheaton posted this 16 June 2016

We've got so many OUs already that I don't want to separate them further. I think I'll just stick to the way it is for now, and wait for DFS to eliminate all these mapped drives.

show

darren posted this 16 June 2016

GP Preferences with Item-Level Targeting is the common way to handle this. I've seen customers put literally 1000s of drive mappings, each with ILTs, in a single GPO. Obviously depends a bit on your topology however. In Windows 8.1+, MS got rid of the round-trip required to evaluate user security group filtering in ILT, so if your clients are newer, they can take advantage of this.

Darren

show

jkolenda posted this 16 June 2016

All,
I have been following this thread for awhile.  not sure if this has been 100% answered or not.  Apologize if that has been.
Just curious if I currently use security filtering with AD groups to open up something for certain users say like regedit, and if I add authenticated users back to the GPO will read permissions not apply group policy permissions will that apply that GPO to all users?
I am thinking and hoping that will not be the case.  But then thinking if the machine policy is the one pulling the GPO not it might.


show

kennedyjim posted this 16 June 2016

Read permissions for everyone will not apply it to everyone. It will allow the machine to read the gpo. Then the users with Apply will get it.





















show

jeremyts posted this 16 June 2016

I didn't know that Darren. Do you have a reference for that as I can't find anything? I only thought they addressed the round-trip on computer groups a few years ago now: https://blogs.technet.microsoft.com/askds/2011/08/18/improved-group-policy-preference-targeting-by-computer-group-membership/

Cheers,
Jeremy

show

jheaton posted this 17 June 2016

We're all Windows 7 at the moment. Also, we do have separate sites for each of our server sites, so downtown Sac, and 14 other sites. Things are working fine as-is, so I don't think I'll be changing how we are doing the GPs, I'll just have to add what needs to be done to make them work.

show

darren posted this 17 June 2016

Jeremy-
Now that I'm reading that, I had it backwards. It was per-computer security group ILTs that were "fixed", as noted below. Per-user security group ILTs never did a round trip. I'm looking for references to that but it's mostly internal stuff I have based on conversations from about 3 years ago with the product team, related to some slow boot/slow logon reporting we did around GP. I'll see if I can find a more definitive reference. I think my timing was wrong--it was probably Windows 8 when that came out, though I could swear it was later. Apparently I've been doing this too long...

Thanks,

Darren

show

Alix posted this 21 June 2016

Hi everyone,
Since the application of the security updates of last week, I have GPO problem which has not disapeared with adding the configuration described in MS16-072.Event ID 1085 :
Windows failed to apply the Group Policy Registry settings. Group Policy Registry settings might have its own log file.
Error Description : parametre incorrect.
I have to say that on one of the Domain controllers, I had to uninstall all the security updates of last week (replication error 1753) and I think that it is correlated => uninstalling the update on all the DC ? Any idea ? (by the way, the DC are 2008R2 and I m trying to activate the GPO logging) 
Alix
2016-06-16 7:15 GMT+02:00 Mike Cramer <mike.cramer@xxxxxxxxxxxxxxxx>:
 https://support.microsoft.com/en-us/kb/3163622 MS16-072 changes the way user policy objects are accessed. They are now accessed via the machine’s security context, not the user context. Which means if you’ve been using security filters for user policies, these policies will no longer be applied to the system unless you perform the included fixes. This is a pretty big change. Goes back to why I recommended against using GPO Security Filters unless absolutely necessary…. -Mike C

SmitaCarneiro posted this 21 June 2016

I’ve noticed issues too. My test environment that is Server 2012 r2 based , now has problems applying GPOs. I cannot edit any GPOs either, even though I can link

and unlink them. It seems to be related to the UNC hardening that MS recommended last February to require authentication and Integrity checking for the SYSVOL and NETLOGON shares. Am still working on it.

 

I also heard from a colleague in a different environment that there are issues with Samba servers no longer being able to handle authentication after Microsoft

changed the default behavior of NetBIOS to be more secure

 

This discussion covers it.

https://social.technet.microsoft.com/Forums/en-US/5b32fb1c-bb5d-4be0-8a61-5adcb6ea4eb7/kb3161949-june-2016-update-causes-network-file-shares-to-become-unavailable?forum=w7itpronetworking.

 

Smita

 

 

show

patrickg posted this 21 June 2016

Ran the script to show which GPO’s had the issue, only three did and none were being using by our users. It did warn about the Direct Access policies on the plus we are not in prod yet

with DA.

 

https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/

 

http://www.gpanswers.com/never-a-dull-moment-with-group-policy-or-what-to-do-about-ms16-072/

 


~Patrick

 

 

show

barkills posted this 21 June 2016

MS16-077: “WPAD Update” which includes SMB hardening that by default restricts Netbios over TCP to the local subnet. My senior engineer thinks this might have been the worst named update he’s ever seen from Microsoft,

especially when you combine it with other updates that do mention SMB.

 

We had a major incident last week due to this poorly named Microsoft update, where our Samba servers were rendered dead in the water due to applying this patch to the domain controllers of the domain those Samba

servers were joined.

 

We had “newer” samba servers staged which were not affected and ended up swinging all our client shares to the new samba servers sooner than planned as a workaround.

 

We eventually heard someone else mention a similar problem, and realized that the name of this update was extremely misleading, and we had overlooked it as a possible cause of our incident. Configuring the settings

mentioned in the KB on our DCs did “fix” our older samba servers, but definitely too late to do our customers any good.

 

Not sure how this would relate to the problem mentioned involving GPOs, unless we are talking about domain clients which are pretty old capable of only doing netbios over tcp.

 

 

show

Alix posted this 23 June 2016

Hi all,
since the application of the security patches last week, it seems that the communication between clients and Domain Controller is bizarre : the number of computers returned  by "dsquery computer -inactive 1" is *5 more than "dsquery computer -inactive i" , with i=2 or i>2.
If I test the secure channel of an "alive but inactive computer" (and I propose to name this computer "mypc") with this command :
nltest /server:mypc /sc_query:mydomain
there is no error with the connection status
More the "inactive PC" (which can be a server) seems to be all right : no problem to access remote share etc
Let's say that I am worry : what kind of test can I do ? What about the command "dsquery inactive" and "nltest" : which one is correct ?
Thanks for your advice,
A.
2016-06-21 17:05 GMT+02:00 Brian Arkills <barkills@xxxxxxxxxxxxxxxx>:
















MS16-077: “WPAD Update” which includes SMB hardening that by default restricts Netbios over TCP to the local subnet. My senior engineer thinks this might have been the worst named update he’s ever seen from Microsoft,

especially when you combine it with other updates that do mention SMB.

 

We had a major incident last week due to this poorly named Microsoft update, where our Samba servers were rendered dead in the water due to applying this patch to the domain controllers of the domain those Samba

servers were joined.

 

We had “newer” samba servers staged which were not affected and ended up swinging all our client shares to the new samba servers sooner than planned as a workaround.

 

We eventually heard someone else mention a similar problem, and realized that the name of this update was extremely misleading, and we had overlooked it as a possible cause of our incident. Configuring the settings

mentioned in the KB on our DCs did “fix” our older samba servers, but definitely too late to do our customers any good.

 

Not sure how this would relate to the problem mentioned involving GPOs, unless we are talking about domain clients which are pretty old capable of only doing netbios over tcp.

 

 

show

gduke posted this 28 June 2016

Brian,



 

Thank you for mentioning this. We’re seeing strange GP processing behavior from our Windows 10 clients, specifically not processing many Group Policy objects

that should be applied (and have applied in the past).

 

I remembered you had mentioned that an update made some unexpected changes, which led me to the documentation for

KB3163017, which mentions the following:

 

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior

change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the computer's

security context. […]


 

Symptoms

 

All user Group Policy,

including those that have been security filtered on user accounts or security groups, or both,

may fail to apply on domain joined computers.

 

I’m surprised more things haven’t broken (yet). I haven’t attempted to apply fixes, yet, but this will be first order

of business tomorrow.

 

--Geoff

 

Geoffrey Duke

802.656.1172 |

Sr

Systems Administrator
|

Enterprise

Technology Services
|

University

of Vermont


 

 

 

 

show

Close