This issue I’m having seem to only be at our branch locations and has been going on for at least a few months now. All branch locations have their own domain controller (all 2008 R2).

None of the custom policies I’ve created that apply to the user through security groups are being applied. Any GPO’s that apply to “Authenticated Users” work fine.
I’ve run GPRESULT /H and GPRESULT /SCOPE /V with both USER and COMPUTER options. Neither reports have told me anything useful other than the GPO’s aren’t applying, which I already knew. It doesn’t tell me why.
One thing I did notice in the GPRESULT /H report is that when I run it on a user where the policies are not applying, the denied GPOs section only shows the GUIDs, not the full names of the policies. When I run the report on a user that is working normally, the names are there. Almost like the user that isn’t working isn’t able to read the policies properly?
I’m kind of stumped. I’ve been working on this for a while now and am admittedly fairly new at Group Policy so I’d appreciate any help.

1 Spice up
1 Spice up

Since you mentioned authenticated users, start here: We should sticky the info about MS16-072 & Group Policy

1 Spice up

You guys beat me to it but I will paste anyway

A recent Windows Update is affecting you

To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:

Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).

If you are using security filtering, add the Domain Computers group with read permission.

Here is a Technet blog post about it: https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/

1 Spice up

As I mentioned, this has been going on for months so it’s not any of the recent updates. Additionally, I declined the two recent updates that were reported to have GPO issues.

I also added the Authenticated Users group with Read Permissions anyway just to be safe and that did not resolve anything.

Try adding Domain Computers to the Delegation tab.

Have you ensured that the user that isn’t working is actually a member of the security group through which you are applying the GPO? How do you have your AD laid out? Do you have OU’s separated out by departments? Are you applying the policy itself at an OU level or at the entire Domain level?

I would check the permissions on the policies themselves. It almost sounds like the GPO has had the “read” permission revoked, but “apply” is still configured. Just a guess, but something seems goofy with the permissions.

Do you see a message about the policy being filtered out?

It may help to take a look at the ‘Delegation’ tab and attach a screenshot of the allowed permissions.

1 Spice up

I can do that but these are all User permissions so I didn’t think that was necessary.

It has to do with allowing the machines to process the GPOs. I’m not sure it’s needed in this case either, but… it’s worth a try.

1 Spice up

Yes, the user is in the group that is listed under security filtering.

Our AD is very simple, users are in a Users OU, PC’s are in a Workstations OU, no other division beyond that. The policy is applied to the entire domain.

I’ve checked the permissions, the security group the user is in is listed in Security Filtering and under Delegation it says: Read (from Security Filtering).

Nothing in either section has anything permission-wise other than Read and/or Apply except for the few groups that have Edit. Nothing is denied anywhere.

It still sounds like the update is affecting you. You took Authenticated Users off the policies and they aren’t working. That is pretty much what the update broke. Add Domain Computers like Larry said if you are using a security group to filter who the policy applies to

What says Read under Delegation? Auth Users?

That’s not entirely correct, I ADDED Authenticated Users. It was never there to begin with but I added it after I heard about the update issues. This did not resolve anything and, like I had said, this started long before those updates.

I am still going to add Domain Computers.

It was there at some point, all new policies start with it. But if you say it started before June, then I will take your word for it.

When you remove Auth Users from the Security Filter section it is automatically removed from the Delegation tab. Which is why so many people ran into trouble with this update.

1 Spice up

Please post a screenshot of your delegation tab (don’t forget to sanitize if necessary) on an affected policy, then a screenshot of gpresult. That would help us see what you’re dealing with.

also you can take a look at the group policy modeling in the GP management console… as well as RSOP.msc on the affected computer/user to get some more feedback.

I too would be curious to see the permissions in the delegation tab. wondering if that user or computer is part of a group that is denied access.

Another thought is that something (computer, user or group) is denied access to the sysvol folder where the policies are stored since you only get the SID and not the policy name.