Change in GPO Processing

  • 331 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

Show More Posts
Close