GPO Loopback & Security Filtering Explained

Start from the Default — Authenticated Users

Out of the box, every new GPO carries one security filter: Authenticated Users, holding both Read and Apply Group Policy permissions. That group is wider than it sounds — it includes every signed-in user and every domain computer account — and it is why a fresh GPO "just works" for everyone in the OU it is linked to. You can see the filter in the Group Policy Management Console: select the GPO and look at the Security Filtering box on the Scope tab. Everything in this video is a deliberate change to that default — and every surprise starts there.

Turn On Loopback Processing

Loopback processing is a computer setting. Edit the GPO that is linked to the OU holding the computers, and go to Computer Configuration → Policies → Administrative Templates → System → Group Policy. Open Configure user Group Policy loopback processing mode and set it to Enabled. From that moment, the user settings for anyone who logs on to those PCs are taken from the GPOs linked to the computer's OU instead of only the user's own OU. Loopback never changes the computer half of policy — computer settings always process normally.

Choose Merge or Replace Mode

The same setting asks for a mode, and the choice changes everything. Replace skips the user's own user-side GPOs entirely — only the user settings from the computer's GPOs apply. That is the mode for kiosks, classrooms and RDS servers, where the machine must present one identical, controlled environment to absolutely everyone. Merge applies the user's own GPOs first, then applies the computer's user settings on top — and the computer's settings win any conflict. Merge fits normal PCs where the person keeps most of their usual policy but the machine's rules must have the last word.

Aim the GPO with Security Filtering

Security filtering is how you stop a GPO from going to everyone in the OU. Select the GPO in the console, open the Scope tab, and in the Security Filtering section remove Authenticated Users and add only the group that should receive the policy. To receive a GPO, an account needs both Read and Apply Group Policy — with only one of the two, the GPO is either never downloaded or listed but skipped. Filtering is the standard way to pilot a new policy on one small group first, or to target a single department, without moving a single account between OUs.

Keep the Computers' Read Permission (MS16-072)

This is the trap that has bitten admins since June 2016. The MS16-072 security update changed how Group Policy is retrieved: the computer account now fetches user GPOs from the domain controller in the computer's own security context. So the computer must hold Read permission on every GPO it fetches — including user GPOs filtered to a group the computer is not a member of. If you removed Authenticated Users in the previous step, open the GPO's Delegation tab, click Add, and give Authenticated Users (or Domain Computers) Read permission only — reading is all the machine needs; Apply stays with your target group.

When Loopback and Filtering Meet

The two controls interact, and the interaction catches even experienced admins. The user settings that loopback delivers still live in GPOs linked to the computer's OU — but they are still user settings, so the person at the keyboard still needs Apply Group Policy on that GPO, and the computer still needs to Read it. Tighten the filter on a loopback GPO to a computer group only, and the machine dutifully fetches a GPO whose user settings nobody sitting at it is allowed to apply: a perfectly configured kiosk GPO that silently delivers nothing. Before blaming the policy itself, check both halves of the permission pair.

Prove It with gpresult

Do not guess — verify. On the affected PC, in the affected user's session, open Command Prompt and run the video's proof command:

gpresult /h report.html

Open the generated report.html and read the verdicts. Applied GPOs are listed at the top, and every rejected GPO carries its reason: Denied (Security) means a filtering decision, Denied (Inaccessible) means a fetch or permissions failure, and Denied (Empty) means that half of the GPO simply has no settings. With loopback working, the fingerprint is unmistakable — the GPOs delivering the user settings are the ones from the computer's OU. Work the evidence in this order — scope, filter, loopback — and most "GPO not applying" cases explain themselves.