It’s 2021, why am I writing a post about Group Policy? Everyone has retired their AD infrastructure and is using Intune for everything now, right? No? Bueller? Anyway, the topic of Loopback Processing came up a few times recently in the WinAdmins Community, and there always seemed to be some confusion around it. I’ve done a bit of untangling misconfigured loopback processing settings in the past, and figured I’d throw something together that documents what I’ve seen and know.
What Is Loopback Processing?
Microsoft Docs is the best place to answer this, but the TL;DR is this: it allows you to apply user policy settings to computer objects, or more specifically, any user that logs into a specific computer.
In a GPO, there is two sections: computer configuration, and user configuration. The settings within each of these sections can only be applied to the respective object type. If you create a GPO containing only computer settings, and link it to an OU containing only user objects, the effective result is nothing happens. The reverse is also true, unless you enable loopback processing (which is a computer setting). There are a few typical use cases for doing this, usually due to needing to maintain a specific/controlled environment for anyone that logs in:
- Computer labs
- Publicly-accessible terminals/kiosks
- Shared devices
- Terminal Services/Remote Desktop Session Hosts
- VDI
Another situation for using Loopback Processing that I’ve seen was if you cannot apply policy to user objects at all. For example, imagine an AD design where all user objects are managed via an external Identity Management Solution. No changes should be made directly to users within AD, so they are located within their own restricted OU.
To Merge, or to Replace?
When you first look at the computer setting to enable loopback processing, you’ll see you need to pick a processing mode, “merge”, or “replace”.
- Merge mode: Gathers all user settings applied to both the computer and user objects, and applies them all. If the same setting is configured in both locations, the one applied to the computer wins.
- Replace mode: Gathers only user settings applied to the computer object. User settings applied to the user object are ignored.
If you enable loopback processing, it will default to replace mode, which is the typical configuration for when you need to maintain a strict, controlled, user experience for anyone that logs into a computer. Merge mode is useful if you need to control some aspects, but also want to carry over settings applied to user objects, just as drive mappings, printers, etc.
One caveat to using merge mode is that it will double group policy processing time, as the policy tree needs to be traversed twice to determine what settings need to be applied. This is where I typically see slow logon time issues, or settings not applying as you think they should.
“Best Practices”
The following is what I consider my “best practices” for configuring loopback processing in my experience:
- Create two purpose-built GPOs to enable it loopback processing (one for each mode). These GPOs should only contain this one setting. Lock down who can edit these GPOs (I’d go as far limiting permissions to Domain Admins).
- Link your loopback processing GPOs as necessary, and enforce these links, to ensure any loopback processing setting change in any other GPO does not cause any unexpected issues.
- Create user setting GPOs as needed, and link them to the necessary OUs containing computer objects that you want to control the user experience on.
- Don’t enable loopback processing if you don’t need to. If your computers and users are in distinct OU structures, apply policies to them as needed.
- In the situation of not being able to apply any policy to user objects, enforce replace mode from the top down across all OUs containing computer objects.
