Question

Locked

Best Way to Lock Down a Terminal Server?

By bens ·
We are in the process of configuring a terminal services on MS Server 03 and I thought I would ask for some knowledgable input...

Do you think that applying local security policy to remove unwanted items (control panel, run, etc...) is the best approach? From what I've seen, this locks down admin access as well, which I really would like to have.

OR

Is applying through Active Directory GPOs is a better approach? This method however seems to be applying restrictions on all computers the user logs into - something we only want to do on the server.

All in all, I am looking for the balance between locking down the interface but still being able to admin the box as needed. Any ideas? Is anyone using a different method to secure terminal services?

This conversation is currently closed to new comments.

7 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Answers

Collapse -

OU

by Jellimonsta In reply to Best Way to Lock Down a T ...

I created a Terminal Server OU in AD and placed the GPO policies on that OU. I locked it down tighter than a drum for any user.
Then, when you wish to adminster the server you move it back to the server OU.

Check out this link too...
http://www.microsoft.com/downloads/details.aspx?FamilyID=7f272fff-9a6e-40c7-b64e-7920e6ae6a0d&DisplayLang=en

Regards.

Collapse -

User affects?

by bens In reply to OU

I've read through that before - so you are using the second method of placing the computer object in an OU, where you lock down User Configurations in the GPO? I guess I might not be understanding loopback processing, that the "Planning" pages mention.

So by doing this all users aren't affected with their current logons, they are only affected when they logon to the terminal server?

Collapse -

OU

by Jellimonsta In reply to User affects?

You apply the settings to the OU, so it only affects user logins on systems in the OU.
As I mentioned, my configuration affected all logins, so to administer the box I moved it to the server OU. While having to move the computer is not 'ideal', I really liked the fact that no one could mess with the config of that system.

Collapse -

User Group Policy loopback processing mode

by JyrkiAr In reply to OU

I moved this answer one step higher level. Deleting own post would be usefull feature here.. . .
Editing seems to work so here we go!

Collapse -

"User Group Policy loopback processing mode"

by JyrkiAr In reply to User affects?

AFAIK; in situation where only TS computer account is located in OU where GPO is linked it reads first computer policy part of GPO and after that user policies from same GPO and assigns them for every user no matter if there is user accounts or not in that OU.

There's also setting replace/merge which should be considered carefully.. .

Replace mode clears all other user policy settings that _any_ user that logs on to that computer might inherit from other policies -and adds only user policies in GPO which is assigned to OU where TS computer account is located.

Merge mode is quite self explanatory.. it merges user policies from Terminal Server GPO to inherited user policies.

But if there is conflict between inherited user settings and user settings in TS GPO, later one wins.

--
I checked that conflict behaviour to avoid disinformation..
http://technet.microsoft.com/en-us/library/cc978513.aspx

Collapse -

Best Practice from Microsoft

by Senrats In reply to Best Way to Lock Down a T ...

I had the same problem. This is from Option 2 in the MS "Locking Down Windows Server 2003 Terminal Server Sessions" manual.
"After installing and configuring all applications on the Terminal Server, place the Terminal Server computer object into the locked down OU. Enable loopback processing. All users who log on to the Terminal Server are then restricted by user-based policies as defined by the locked down GPO, regardless of the OU the user is located in. This can prevent many local changes from being applied to the Terminal Server; however, the server can still be remotely maintained. If administrators need access to the Terminal Server, log off all users and temporarily restrict their logons to the Terminal Server. Move the Terminal Server computer object out of the locked down OU, then log on. Return the Terminal Server computer object to the locked down OU, and re-enable user logins after maintenance is complete. This implementation does not require users to have multiple user accounts. It can also prevent configuration changes to the Terminal Server while it is in production."

Back to Networks Forum
7 total posts (Page 1 of 1)  

Related Discussions

Related Forums