It is the most-repeated Group Policy accident of the last decade: an admin tightens a GPO's security filter, removes Authenticated Users, adds the correct group — and the policy stops applying to absolutely everyone, including that group. Nothing is broken. A 2016 security update changed who does the fetching.
Before June 2016, a client retrieved user GPOs using the user's credentials, so filtering a GPO to a user group was self-sufficient. The MS16-072 security update (KB3163622) moved that retrieval into the computer's security context to close a spoofing weakness. From that day on, the computer account needs Read on every GPO it fetches — including user GPOs aimed at a group the machine does not belong to. Remove Authenticated Users carelessly and you remove the computers' Read with it. Here is the whole story, the symptoms, and the fix.
Example report values — the group membership looks correct, which is why this trap wastes so much time.
Group Policy has two halves of work: fetching the GPO files and settings from a domain controller, and evaluating whether this user or computer should apply them. MS16-072 changed the fetcher for the user half. Retrieval now happens with the computer's credentials — the machine proves its right to even see the GPO before the user's memberships are considered.
That is a sensible security design: a rogue device or a spoofed server should not be able to hand a user policies the machine had no business reading. But it made one permission load-bearing that nobody used to think about — Read, for computers, on user GPOs. The default Authenticated Users entry silently provided it, because computer accounts are authenticated users too. The moment an admin removes that entry in the name of tidiness, the load-bearing wall comes out.
The cruel part is the misdirection. The admin checks the obvious thing — the user is in the target group, the GPO is linked to the right OU — and both are true. Yet the policy does not apply, and on the client the GPO shows as filtered out for security reasons, looking exactly like a problem with the user's permissions.
It is not the user. It is the PC standing in front of the user, unable to open the door. Train yourself to translate the symptom correctly: a filtered GPO that broke the moment you edited its security filter is a computer-Read problem until proven otherwise. The other classic clue is scope — it broke for everyone at once, including accounts whose permissions never changed. User problems are personal; fetch problems are universal.
gpupdate /force, then verify with gpresult /h report.html: the GPO should now appear under Applied for target users, and filtered out — correctly — for everyone else.Read without Apply is the whole trick. Computers can fetch; only your group can apply. Nothing about the update needs to be removed, and it should not be: it closed a real man-in-the-middle weakness in how policies were delivered.
Nobody makes this mistake exactly once — they make it as a style, across every filtered GPO they ever tidied. So treat one occurrence as an audit trigger. Walk every GPO that uses security filtering and ask one question of each: if Authenticated Users is not in the filter with Apply, is it (or Domain Computers) present with at least Read? Any GPO that fails that question is either broken right now or one reboot away from confusing you.
Then make the rule permanent in your team's habit: filtering changes are made in the Scope tab, but they are finished in the Delegation tab, where the Read entry is verified before the console closes.
Filter with groups for Apply. Never remove Read for computers.
Authenticated Users in the filter with Apply means “everyone”. Authenticated Users in Delegation with Read only means “every computer may fetch this, and the filter group alone decides who receives it”. Both lines can be true at once, on the same GPO, and together they are the correct shape of every filtered GPO in a post-2016 domain.
The video works through security filtering on a live console — including who needs Read, who needs Apply, and how to prove the result with gpresult instead of hope.
▶️ Watch Full VideoEither works, because both include the computer accounts that perform the retrieval. Many admins standardise on Authenticated Users with Read only on the Delegation tab, since that was the entry whose removal caused the problem. Whichever you choose, keep Apply off for it.
Computer settings were always retrieved in the computer's own context, so nothing changed for them. The update's impact was on the user half: user GPOs are now fetched by the machine account, which is why a user-only filter group is no longer enough on its own.
No — that pattern is personal, so it points at the user: check for a Deny Apply inherited through another group membership, and remember that group memberships are only picked up at logon, so have the user sign out and back in before re-testing. The MS16-072 trap takes the GPO down for everyone at once.