Florian’s Blog

[ - or: How can I use the loopback processing mode for machine but leave some users out of this? ]

I created an article earlier on Loopback Processing, so this is just an update and another aspect of loopback since this question came up twice in the last week.

Using loopback, you can advise a machine to “look” at the User Configuration “side” of Group Policy application. This can be great if you want to lock down your Terminal Servers, no matter which user logs in there. With the default GP processing, users have their own portion of policies applied, Terminal Servers have their own. But for Terminal Servers, you sometimes want to have more restrictive settings applied to a user - or completely different settings from desktop machines users work on a daily basis. This is where loopback kicks in. Loopback makes your Terminal Servers look at the User Configuration settings on all the policies in its scope - and applies them. Depending on the mode you choose - “Merge” or “Replace” - you get different results.

So, this is working for users, but what if you want to exclude your Administrators from that?

You surely want to lock down Terminal Servers but want to be able to let yourself and others in your Admin-team manage the servers - or have less restrictions on it.

The answer in this is the way, the machines process the user configuration settings that are in its scope. The machine doesn’t simply process the policies in its scope, it actually impersonates the user to do so. So when Bob logs on to his machine and loopback is in - let’s say - Replace mode, we know his user portion of policies is not regarded. His machine will now look at all policies in its scope using his credentials to see whether he has access to those policies and can process them (I think it was Mark Heitbrink who once wrote something like: “the machine has the user’s hat on to try to apply the policies” - that’s a good picture for it!) . If Bob has no permissions on a policy that his machines would apply (for example “Apply Group Policy” permission is denied for Bob), that specific policy is not applied during Loopback Replace mode.

The bottom line is - Bob needs sufficient permissions on the policies, loopback shall apply.

This is where we can work on it. If you want to create exceptions for your administrators, put them into a security group and deny “Apply Group Policy” permissions on that loopback-policy in the machine’s scope that would normally apply to all users.

Well, that leads to further thinking. If you’re using loopback in “Merge” mode, you know “User Configuration” is processed twice. Once for the actual user and after that, once for the “machine” with the user’s hat on. If the user has no permissions to apply the loopback-policies, the user’s “normal” Group Policies will be applied.

But what if we run in “Replace” mode and the only loopback processing policy is configured to deny “Apply Group Policy” permissions for our admins? Well, then no user config policies are applied at all. “Replace” mode discards all user config policies an user has - and since we denied application of the loopback processing policy (assuming in this scenario there’s simply one existing - or all of them are denied for application), there’s no user config policy to apply.

Be sure to have a “fall-back” policy for user administrators, if you want to restrict some access to the Terminal Services although they’re admins. Using “Replace” mode will leave them alone with the Terminal Server - with no policies applied.