As you probably know, loopback processing is a feature of Active Directory Group Policies which applies user settings in a GPO to any user who logs on to computers in the GPO's scope (whereas the standard behavior would be to apply user settings only if the user account is actually located whithin the GPO's scope). This is useful when you want all users logging on to a specific computer to receive some user policy, regardless of where their user accounts are actually located in AD.

The problem: when loopback processing is enabled, a GPO containing user settings is applied to everyone using those computers, and you can't bypass this by using ACLs on the GPO, because it's not actually applied to users, but to computers.

The question: how can loopback processing be bypassed for specific users who need to log on to those computers but should not be subject to those policy settings?

Case in point: there are several terminal servers where GPOs with loopback processing are used to enforce heavy user restrictions on everyone who logs on to them (they should basically only be able to run a bunch of company-approved applications); but this applies even to Domain Admins, which are thus rendered unable to even launch a command prompt or open the task manager. In this scenario, how can I tell AD to not enforce those settings if the user logging on belongs to a specific group (such as Domain Admins)? Alternatively, even the opposite solution ("only apply those settings to users belonging to a specific group") would be fine.

But please, remember that we are talking about loopback processing here. The policies are applied to computers, and the user settings inside them are applied to users only because they are logging on to those computers (yes, I know it's confusing, loopback processing is one of the trickiest things to get right about Group Policies).

  • 1
    not being able to bypass settings per user is exactly why you use loopback. – Jim B Jun 30 '16 at 18:10
  • Please read technet.microsoft.com/en-us/library/cc782815(v=ws.10).aspx They create 2 GPO, one with loopback and one with the user setting linked to the terminal server OU. They state to remove the admin (by removing authenticated user) from the second GPO's only. – yagmoth555 Jul 1 '16 at 2:21
  • The policy is applied to computers... meddling with user permissions should not work; however, I'm now more confused than ever. Some testing is in order; I'll come back to this question after having verified how this actually works. – Massimo Jul 1 '16 at 6:16
  • Use a second enforced policy linked to the users to undo settings acquired from loopback processing? – BlueCompute Jul 7 '16 at 8:06

I think the solution would be WMI filtering (that's how I did it in my place).

You create a WMI filter that catches those workstations you want.
You create a GPO with the user settings only, and with security filtering.
You put the two together, and place the GPO on the users container.

So the WMI filtering specifies the comptuer it applies to, and the security filtering the users it applies to.

And drop the loopback.
It will give you more headaches than you bargained for, as it doesn't apply only to the specified GPO that it is configured in, but to all policies applied to the computers.

If you have kb3163622 installed on your workstations, you can do the same by using security groups only.
This update changes the way user policies are applied.
From now on, user policies are actually applied under both the computer and the user security context.
So if you'll put in the security filtering of that GPO the computers and users you want it to apply to, that will do the same trick as the WMI (assuming you're not going for some complex query).

| improve this answer | |

A deny ACE for Apply Group Policy permission for the security principals in question (User/Group) on the group policies with the user settings in the computer OU will prevent the user group policies linked at the computer OU from applying.

However, if loopback policy processing is configured for Replace mode, the user group policies that are in scope for the user account location (and not for the computer) will be ignored.

| improve this answer | |
  • The policy is applied to computers, not users; it only affects uses due to loopback processing. Denying users the rights to apply it has no effect, because the policy isn't actually applied to users. – Massimo Sep 25 '16 at 18:28
  • The user policy setting applies to users, and users cannot apply the settings if there is a decent ACE. I confirmed this in testing. Loopback only means check the computer scope for user policies, and If the user policies in the user account scope should be merged or replaced/ignored. It doesn't mean that user settings apply to computers. – Greg Askew Sep 25 '16 at 18:58
  • I actually tried that and it didn't work; maybe I missed something, I'll try again... – Massimo Sep 25 '16 at 20:43
  • @Massimo: No problem. And you are correct, it IS confusing. :-) – Greg Askew Sep 25 '16 at 20:48
  • @Massimo You were probably missing the KB patch talked about in the other answer that was edited with this detail, this solution works fine assuming you have that applied. I assume you already figured this out by now but wanted to mention just in case. – Pimp Juice IT Jul 31 '19 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.