Securing Windows Server 2008 Terminal Services

One area of great advancement in Windows Server 2008 are the improvements seen in Terminal Services. While Windows 2000 and Windows Server 2003 provided basic terminal services support, Windows Server 2008 provides advanced services. These advanced Terminal Services services include the Terminal Services Gateway, Terminal Services Session Broker, Terminal Services Web Access and Terminal Services RemoteApps. No longer do you need to go to a third party to get an enterprise ready Terminal Services solution.

As you plan for your Windows Server 2008 Terminal Services rollout, you’re going to have to consider the security implications of your solution. Terminal Services presents a unique security situation, because you have dozens or hundreds of users connecting to the same machine. Thus, misbehavior of one user on that machine can potentially effect many other users ability to get their work done.

Consider the following when preparing to secure your Windows Server 2008 Terminal Server:

  • Configure network level authentication. Network level authentication is a more secure form of authentication, as the user is authenticated before the terminal services session starts. This helps reduce the risk of Denial of Service attacks.
  • Enable Single Sign-On for Terminal Services. Single sign-on allows users to log in once using a password or smart card, and then be able to reuse those credentials when connecting to other machines in the same domain. This improves security because the user won’t have to potentially expose his password when logging on to different servers, or having to reinsert the smart card when connecting to other servers.
  • Change the default RDP port. While this is security through obscurity, every little bit helps.
  • Use smart cards with Terminal Services. Smart cards are inherently more secure than using user names and passwords. The Windows Server 2008 Terminal Server fully supports smart card authentication and you should take advantage of that capability.
  • Use the NTFS file system. This should go without saying. You must use the NTFS file system if you want to enforce NTFS permissions on the Terminal Server machine. In addition, NTFS gives you the ability to set quotas and perform file system auditing.
  • Use TS Easy Print exclusively Previous versions of Terminal Services required that you install the users’ local print drivers on the terminal server in order to allow them to print to local printers. The TS Easy Print driver does away with this issue and the potential security issues of involved with installing a large number of printer drivers that might have security flaws or introduce instability to the Terminal Server.
  • Partition user data on a dedicated disk. Dedicate a disk for user data if you allow users to upload data to the terminal server. Allowing users to store data on the boot partition or any partition that stores system data or services could potentially allow users to create a denial of service condition on the terminal server.
  • Create specialized OUs for terminal servers. You should create OUs for the Terminal Server and the Terminal Server users, and then instruct the users to log on to the Terminal Server with the account that was placed into the locked down OU.
  • Set Group Policy settings for the terminal servers. There are a number of Group Policy settings that you can use to lock down the Terminal Servers. These would be applied to the Terminal Servers OU.
  • Set Group Policy settings for the remote desktops. Configure locked down RDP settings in Group Policy and apply them to the user OU that you created for the Terminal Services users.
  • Restrict users to specific programs. User software restriction policies to control what applications Terminal Server users can use when connected to the Terminal Server
  • Limit terminal server security auditing. Event logging can take a toll on a server, and especially a server that is typically highly loaded, such as a Terminal Server. Make sure that you enable logging at a high enough level to meet your company’s security requirements, but not so high that you impede performance.

For details on how to implement each of these recommendations, check out the Windows Server 2008 Security Guide at



Thomas W Shinder, M.D.

Email: [email protected]
MVP – Microsoft Firewalls (ISA)

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top