Mar 22, 2017
3 mins read
For those not in the know, GPO loopback makes it so User policies apply to Computer objects. It‘s predominantly used for kiosk / shared PCs where you don‘t want anything to change, regardless of which User sits at it.
There‘s two modes, Merge and Replace.
The following clarity is brought to you based on the idea you know a bit about GPO and how to apply it. Some points follow just as a reminder.
Here, is how we‘ve got it setup. On the Left are how the GPOs are applied. There is no WMI/Security/Delegation filtering. On the right is the objects in the OUs.
In this example, We have Loopback Merge at the top of the domain. Now that Only contains loopback settings. No other settings. Once again, Loopback is a setting itself that applies to Computer objects, it is NOT an extra setting to apply to the rest of the settings in that GPO. (you don‘t turn loopback on just for this gpo).
User1 logs into TCUTIL. All the policies in green apply. TCUTIL gets Computer settings, User Settings 2 and User Settings because the loopback applies those User Settings 2 to the computer object. User1 receives User Settings and it‘s in Merge mode so those pull through and get merged
Example 2, exactly the same but we‘re in Replace mode.
Now, User1 doesn‘t get User Settings because the policy is not in the same OU as the computer object. It‘s only applying to a User object and Replace isn‘t interested in that. So it‘s binned.
Example 3. Someone‘s went mental and got 2 loopbacks running wild. A Replace at the top of the domain and Merge further down. Standard GPO order of application goes so the Merge wins. It is treated the same as Example 1.
Hopefully that‘s helped explain how it works. I got caught by the idea that it applies to the other settings in the policy and isn‘t a global setting in it‘s own right for a long time.
Best practice is to minimise loopbacks, or restrict to an OU for kiosk style machines.