Solved

Group Policy for Terminal Server

Posted on 2007-11-16
35
641 Views
Last Modified: 2013-11-21
I am having trouble apply a group policy to our terminal server.
The remote users policy applies perfect to the terminal server but I found I need another GPO to harden it further.  Users outside of the remote user OU (users in the Arizona and California OU)can go into the control panel and have access to all the items there.  I want to remove almost all items except things like printers/faxes;mail;scanners and cameras; etc
Now I created a GPO in the terminal Servers OU (maybe this is my mistake) removing those items from the control panel but the policy is not applying.  GP Modeling is showing empty, but its not. I dont want the policy to apply to the users on their own machines, only when they log onto the TS which is why I created the GPO in the TS OU.
I am a member of the Arizona OU so if I have to create the GPO at the Business Users OU I dont want it to apply to me.  I am a member of all admin groups if that helps.


The AD structure is like so
Domain--
   Business Users OU
       Default Domain Policy
       Arizona Users OU
       California Users OU
Remote Users OU
      Remote Users Policy
Terminal Servers OU
     Remote Users Policy link
0
Comment
Question by:ryansoto
  • 13
  • 10
  • 10
  • +1
35 Comments
 
LVL 2

Accepted Solution

by:
Haze0830 earned 167 total points
ID: 20299303
You need to define a policy on your terminal server OU that enables Loopback processing of Group Policy. Then define a seperate policy in the same OU that locks down your server.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;231287

http://support.microsoft.com/default.aspx?scid=kb;en-us;278295
0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20299328
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.
0
 
LVL 2

Expert Comment

by:t_taylor
ID: 20299497
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.  
0
 
LVL 31

Expert Comment

by:Cláudio Rodrigues
ID: 20299541
Read this thread. I explain in detail what you need to do to get Group Policies working properly on TS.
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_2003_Active_Directory/Q_22960486.html

Cláudio Rodrigues
Microsoft MVP
Windows Server - Terminal Services
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20300482
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?
0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20300606
I'm not sure that I understand what you're saying/asking....but...

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

Expert Comment

by:t_taylor
ID: 20301097
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.
0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20301165
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.
0
 
LVL 2

Expert Comment

by:t_taylor
ID: 20301195
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.
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20301233
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?
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20301253
Edit

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

Expert Comment

by:t_taylor
ID: 20301363
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?
0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20301423
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.





0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20301477
...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....
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20301483
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




0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20301538
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.

0
 
LVL 2

Expert Comment

by:t_taylor
ID: 20301540
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.
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20301568
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
0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20301580
That's the setup I'm currently using. (the one I've described).
0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20301597
Do you have your loopback set to merge or replace?
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20301604
Replace
0
 
LVL 2

Expert Comment

by:t_taylor
ID: 20301607
Huh, guess I was wrong.  Go with what Haze said, if it works.
0
 
LVL 2

Expert Comment

by:Haze0830
ID: 20301632
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.
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20301652
ok sit tight
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20301995
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

0
 
LVL 2

Expert Comment

by:t_taylor
ID: 20302006
So both of the logins, remote users and domain users returned the remote user policy?
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20302139
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
0
 
LVL 2

Assisted Solution

by:t_taylor
t_taylor earned 167 total points
ID: 20302170
Do an RSop on a TS server with a remote user profile.  Find a setting that is set one way in loopback GPO and differently in the Remote Users GPO.  Check to see if it says that the setting in the loopback GPO "wins."  If so, then it is getting both of the settings, just that the loopback is "winning" because the computer always wins over the user. This is kind of what I thought would happen, but maybe we are missing something if Haze says that this method works.  I couldn't tell you for sure, I never set it up this way.
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20302225
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.
0
 
LVL 2

Expert Comment

by:t_taylor
ID: 20302242
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.
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20302318
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.
0
 
LVL 31

Assisted Solution

by:Cláudio Rodrigues
Cláudio Rodrigues earned 166 total points
ID: 20302324
Ryan,

You need to understand what we usually do regarding policies in a TS environment. The idea behind the Loopback setting on TS is to allow you to have a set of policies with whatever you want (restrict start menu options, remove shutdown, do folder redirection, etc) that will apply to users when AND ONLY when they logon to the Terminal Server. This means if they logon to their PCs, nothing will happen (meaning you will not be restricting them that much on their PCs). Of course you can still have policies for the PCs but these will not apply to the TS and vice-versa.
Is this what you are trying to achieve, locking down your users when they connect to the TS BUT do NOT lock them down the same way when they logon to their PCs?
If that is the case. for the TS you must do this. Make sure you follow ALL the steps AND check EACH step.
1. Create an OU called TerminalServers.
2. MOVE all your terminal server COMPUTERS to that OU.
3. On that OU that is ALL you will have. NO USERS, NO GROUP or anything else here.
4. On a DIFFERENT OU create a group called TSUsers and add the users you want to be restricted when logging in to the TS to that group.
5. On the TerminalServers OU, right click it and go Properties. There you will see Group Policies. Create a new policy called TSPolicy. On the security for that policy, REMOVE 'Authenticated Users' and DENY the policy to be applied to Domain Admins or any other administrator. Now ADD the Terminal Servers COMPUTER Objects (and check the option to Apply the policy) AND ADD the TSUsers Group (and check the same Apply Policy).
7. On the TSPolicy, edit it and set the Loopback Processing mode to REPLACE.
8. Edit the policy again to lockdown whatever you want.
9. When done reboot the TS.

If you followed the steps above what will happen is users that belong to the TSUsers group will get the policy applied ONLY when they logon to the TS.

Hope this clarifies what you are trying to achieve.

Claudio Rodrigues
Microsoft MVP
Windows Server - Terminal Services
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20302325
added domian users to security for the remote policy and logged in and domain user did not apply remote policy
0
 
LVL 2

Expert Comment

by:t_taylor
ID: 20302345
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.
0
 
LVL 24

Author Comment

by:ryansoto
ID: 20302361
Thank you all.  
0

Join & Write a Comment

Suggested Solutions

Learn about cloud computing and its benefits for small business owners.
In this article, we will see the basic design consideration while designing a Multi-tenant web application in a simple manner. Though, many frameworks are available in the market to develop a multi - tenant application, but do they provide data, cod…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now