How do you lock down a Terminal Server?

Two friends of mine, Christa Anderson and Kristin Griffin, are collaborating on a Windows 2008 Terminal Services book for Microsoft. Part of this project includes small "tips from the field" entries written by different people.

Two friends of mine, Christa Anderson and Kristin Griffin, are collaborating on a Windows 2008 Terminal Services book for Microsoft. Part of this project includes small "tips from the field" entries written by different people. They asked me to write a short bit on security, specifically, what's my one "hot tip" about locking down a terminal server?

For me this was easy, because I think there's one super simple thing that's better than any other advice I've ever received about locking down a Terminal Server. That tip? Remove the "execute" NTFS permission from everywhere except the folders where it's absolutely needed (which is probably only the Windows and Program Files folder). But folders like temp, temporary Internet files, the Outlook saved attachments folder, and the home drives--there is no reason that a user should ever have to execute anything from these folders. And honestly, if you just pull the execute permissions, you almost don't have to worry about anything else. How could users possibly install rogue software if they can't run anything from those locations? (Well, depending on your client drive mapping rules I guess.) How can users even infect a server if they can't execute anything from these locations?

Implementing this is pretty straightforward. The easiest way is to create a path rule with software restriction policies (part of Group Policy in Windows 2003 / 2008). You could also do this via good old-fashioned NTFS permissions, although you have to be careful that users don't have enough permissions in a folder to grant themselves execute permissions if you just remove it.

Besides this, what else do you do to lock down a Terminal Server? Microsoft actually has a great KB article detailing all of the Group Policy settings you can make to lock down Terminal Servers. They also published a fairly decent white paper on this topic a few years back. What other tips and tricks do you have?

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Sounds like a good idea but has anyone done this in production?  comments?
For us the basics are removing the run line from the start menu and hiding the local drives.  Those aren't the only things we do, but it's 2 of the simplest quick lockdown ideas we do...
i do this on my production wts 2003 boxes (silly students like to try and do bad things)... and will be doing so here when i transition over 2008 this summer
Removing the execute permission (Actually traverse folder/execute file) with inheritace set to files only is quite bothersome in any larger environment (due to how NTFS works)  Windows 2003 R2/2008 file screenig seems to be the easier alternative.

Restricting the UI is only saving users from themselves, it's not what I would call effective lockdown. There are really only two things worth implementing:

  1. Ensure all users have standard user accounts only

  2. Enable a whitelist of applications (e.g. Software Restriction Policy, AppSense Application Manager, RES PowerFuse etc)

Hi Aaron,

Where you say use a whitelist of applications, do you mean a list of executables that CAN run or a list of executables on the system that CANNOT be run?  Is it possible do you know if the functionality of AppSense Application Manager can be achieved using Windows' Software Restriction Policies (2003 and\or 2008)?

Thanks, Mark



Hey, Brian--thank you for the plug. It makes working on the book on a gorgeous July weekend in Seattle a bit easier.

For anyone who's interested, the TS Resource Kit (MS Press) will be out this fall.



Hi Mark, Application Manager is more flexible than SRP. The default configuration for AM will block any executable content that is not owned by the administrator. Which essentially means that users cannot run an executable not installed on the machine by the administrator. I think RES does something similar.
You could quite easily automate/script SRP so that it does the same. It all depends if you have the skills, money, or both.

Hi Christa

 I wrote a doco on this for my Sans Gold certification.

Had some good feedback on it.


Catch ya




Have you ever looked at ThinLaunch Sofwtare's product, Thin Desktop?
Check out WorldExtend IronDoor, you can use it to secure connections to your server, and keep users seeing what only they need to see.