Group Policy for Terminal Server

Loopback processing will "replace" or "merge" (depending on how you configure it) the GPO that is applied to a user ONLY when they are logged on to a specific machine (in this case, your terminal server). It's pretty much a necessity when locking down Terminal Server sessions.

Along with the first two, my guess is that the reason it isn't applying is because you may be linking the wrong tree type to the OU.  Set up a new GPO (or edit the old) with all of the settings you want locked down on remote logins.  Then drill down to Computer Configuration > Admin > System > Group Policy > User Group Policy loopback processing mode.   I would suggest going replace if you are concerned about security, but merge will work as well since the computer settings override user settings, so only non configured user settings in the lockdown GPO will be able to be applied if they are configured in the user GPO.  

Read this thread. I explain in detail what you need to do to get Group Policies working properly on TS.
https://www.experts-exchange.com/questions/22960486/2003-AD-GPO-Issues.html

Cláudio Rodrigues
Microsoft MVP
Windows Server - Terminal Services

OK I'm pretty close.
On the terminal server OU I already have a 'remote user' policy which is just that - Members of the remote user OU get one set of policies.
Now when I enable my 'loopback policy' if I log in as a member of the remote user OU I am getting the loopback policy enforced.  
How do I make it so when I log in as someone from the remote user group I am only applied the remote policy?

I think they way to fix it is to set a deny permission in the properties of the loopback policy for the remote user group.  Is this accurate?

I'm not sure that I understand what you're saying/asking....but...

Try setting the loopback policy to "merge" instead of "replace".

If you want to have the permissions of a user group applied and NOT the loopback policy applied, go into the GPO for the loopback policy and go to the delegation tab.  Add Remote User Group and change the permission to apply the GPO to deny.  This does, however negate using loopback processing in the first place, as the whole point of it is to apply user settings to a computer group, forcing everyone who logs into that machine to use that GPO's user settings rather than the ones they inherit based on the OU that the User Object resides in... at least if you use replace.  If you use merge, then, well lets say that there are 3 settings, A, B, and C.  If A is configured in both, then the loopback processing will have User setting A in the loopback GPO used.  If B is configured in only the loopback GPO and not any GPO linked to the OU that the User Object is located in, then it uses the setting the loopback GPO.  If C is not configured in the loopback GPO but it is in the GPO linked to the OU with the User Object, then merge will allow the setting in the latter GPO to be applied to the user logging in.

Which is why you would want JUST Loopback Processing enabled in the Loopback policy, set it to merge, and use another policy to actually apply your lockdown. This is how my Citrix server is setup and it works like a charm.

Right.  I would suggest 3 GPOs.  1 to enable Loopback Replace.  1 for Computer Settings, and 1 for User Settings that would be applied via the Loopback Replace.

Let me try and explain better
I am a member of the the group remote user and I log into the TS I get the loopback policy.
The remote user has their own OU and own policy that needs to be applied.
Terminal Server
     Loopback Policy
     Remote User Policy

When I log in as a 'remote user' the loopback is applying not the remote.  I need the remote user policy apply to only the remote users group and the loopback apply to everyone else.

Domain user logs in --> Loopback applied
A member of the 'remote users' group logs in --> remote user policy applied

Does this make more sense?

Edit

Domain user logs in --> Loopback applied
A member of the 'remote users' OU logs in --> remote user policy applied

Okay, that makes it quite a bit more complex.  The problem is that I don't think you can have loopback linked to that OU and have it not be applied.  The thing is that the computer basically calls itself a user as well when you use loopback.  Here is the way it works:

1: computer boots and gets applied computer node settings.

2: user logs in and is applied user settings.

3: computer sees that loopback is applied, and then either discards the previous user settings and applies its own (replace), or accepts the new settings and adds non conflicting additional settings from the ones in step 2.

So, let's say you have control panel disabled in the user node being used in loopback, but enabled in the GPO linked to the 'remote users' OU.  When a remote user logs in, replace or merge, it doesn't matter, the computer setting wins out and the control panel is disabled.

If you don't have many conflicting settings, then this is acceptable as a merge.  

If you do have a lot of conflicting settings, I think I need to know a little more about what settings are different between Domain User on a normal PC, Domain User on TS, and Remote User on TS.  What are you trying to allow the Remote Users that you don't want to allow the Domain Users?  Then, what is allowed on a normal PC for a Domain User that isn't allowed for a Domain User on TS?

Ok...

EACH policy has to reside on the OU of the specific machine you want loopback processing to apply to. The reason this is occurring is because you are trying to replace a policy with nothing. And in nothing is exactly what's getting applied. Here's a layout that I KNOW works.

Terminal Server OU
   -Loopback Policy (apply to Authenticated Users)
   -Remote Users Policy (apply to remote users group)

Both policies should be linked to the OU that contains the machine.

...I guess what's confusing is that typically a Remote Users policy is established in order to be applied when a user connects remotely. But it sounds like you are trying to establish a policy for your remote users regardless of how they are connected....

OK a normal PC
Domain user has full access to their machines, no restrictions. just the default domain policy applied.  Default Domain policy not tweaked much at all, so we can disregard that.
Domain users on TS - Default Domain policy applies
They can access control panel and things like add/remove programs;system;etc (this is what I am trying to prevent)
I have implemented local policies on the TS for critical items such as who can shut down the server, etc.

Remote user -  People out in the field who need to print through TS and access shared drives.  Remote
Remote user policy is applied at the OU level and linked to the TS OU
We hide most items on the control panel except for mouse/printers/font
Cant access local TS drives

What I am looking for is to have the remote users log in and the remote policy applies, domain user logs in and loopback applies

The best thing to do is have the loopback apply JUST the loopback (I think that's where it's getting confusing). Then establish two other policies on your TS OU in addition to the loopback policy - one for your Domain Users and one for your Remote Users. Then use Security Filtering to apply each accordingly. That's the most straightforward way to do what you're trying to do.

I;m not sure that will work, Haze, though I could be wrong.  The thing to keep in mind is that the *computer* is the one applying the user policies, not the actual user, so filtering that way won't work.  Otherwise, you could apply delegation to deny remote users the ability to apply the gpo used in loopback and it would work.  But it isn't the remote user applying, it is the computer, which is not in remote users, and therefore will not be getting the restriction.  

ryan: That helps, but what I'm failing to understand now is what the remote user should be able to do that the domain ts user shouldn't.  If the extent of it is printing, shared drives, mouse/font etc, why not just let the domain TS users get those as well?  If you want only the remote users to get access to shared drives, do that with NTFS permissions instead, that way you can use the same policy for both.  Unless I am missing something about what remote users should have that domain TS users shouldn't.

Haze0830:...I guess what's confusing is that typically a Remote Users policy is established in order to be applied when a user connects remotely. But it sounds like you are trying to establish a policy for your remote users regardless of how they are connected....

Close domain users - if they connect internally through remote desktop they have default domain policy access.
This allows them access to all the applets in the control panel

That's the setup I'm currently using. (the one I've described).

Do you have your loopback set to merge or replace?

Replace

Huh, guess I was wrong.  Go with what Haze said, if it works.

Lets do this.

On your TS OU. Set your Loopback policy to apply to Authenticated Users and change the setting to Merge. Then link your Remote Users policy to the TS OU and have it apply only to your remote users group.

Test it and tell us what happens.

ok sit tight

Haze0830:Lets do this.

On your TS OU. Set your Loopback policy to apply to Authenticated Users and change the setting to Merge. Then link your Remote Users policy to the TS OU and have it apply only to your remote users group.
Test it and tell us what happens.

Loopback set to auth users
remote set to only remote users

Log in as domain user and remote policy applies
I ran the modeling and loopback policy blocked because security filtering
Again auth users is set

Log in as remote user remote policy applies

So both of the logins, remote users and domain users returned the remote user policy?

t_taylor:So both of the logins, remote users and domain users returned the remote user policy?

Correct

Loopback not being applied to domain users because security filtering

If I go into remote policy and deny domain users the default domain policy applies
If I go into loopback auth users is there so I tried adding the group domain users and still no go, remote policy applies

You know what - it looks like its merging as you stated.
The differnecess between the policies isnt worth this trouble.  How can I ust have the remote policy apply to all that log onto the server?  Instead of applying to just remote have domains users get applied as well.

What are the differences, anyway?  I don't think I ever understood.

Setting it up from to just have both running remote policy is pretty easy.  Just take the GPO with the domain user settings that is linked there and delete it.  If it is in the same GPO as the computer settings or anything else, you will have to go into that GPO and remove them all, hence why I suggested earlier to have 1 for computer, 1 for loopback only, and 1 for user.  Anyway, just make sure the only GPO linked to that OU is the remote users GPO.

OK deleted the link
so now in the TS OU there is only the remote policy in which security is set to auth users
Log in as domain users default domain applies.

Now I assume I just add the domain users group to the security?

The differences were so minimal like in the control panel I wanted domain users to have network places but not for remote users.

added domian users to security for the remote policy and logged in and domain user did not apply remote policy

You could probably create a new GPO with just the settings that will be different for the TS users.  Set loopback to Merge, then in the delegation, add Remote Users and then set apply group policy to deny.  This is basically what Haze said would work, but it may be a little more straightforward to see it it does.

If you have the security set for Domain Users and the GPO isn't being applied and another GPO is, then something is wrong.  The ONLY things that should be linked to the TS OU should be a GPO for loopback, one for computer settings to lock down, and one for user settings to lock down.  Don't forget that if you have a setting higher up, say at domain, and the GPOs linked to TS OU don't have that setting configured, you will inherit from the GPO higher in the tree.

Thank you all.