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
Change in GPO Processing
- 392 Views
- Last Post 28 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?
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…
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
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. :)
Which fix did you apply?
Adding Domain Computers with Read Permission?
Sent from my iPhone
So applying Authenticated Users with Read permissions to all GPOs will fix the issue irrespective of whether security filtering is used?
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.
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:
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.
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.
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.
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
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
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
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.
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
However, I ran the script from here:
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...
"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. :)