Keeping Terminal Service Secure

Because terminal servers will often be accessible via the Internet it is important to ensure that they are well secured. Whenever possible, take a layered approach to securing the devices.

Adding Security via Firewall Settings for ASP Terminal Servers

When using Terminal Servers in an ASP environment or sometimes even in a corporate environment you will want to provide some protection for the servers by placing them behind a firewall. By default RDP communicates over TCP port 3389. If for some reason you would like to change the default port this can be done by modifying the following Registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber

Use Registry Editor at Your Own Risk

If you use Registry Editor incorrectly, you could cause serious problems that might require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

After modifying this key the server must be rebooted. A simple service restart does not do the trick.

Only RDP Clients Version 5.1 or Later

Only RDP clients version 5.1 or later are able to connect to a Terminal Server running on a nonstandard port. To make a connection to a server running on a nonstandard port you must follow the server name with a colon and the port number, for example, Terminalserver1.companyabc.com:1234

Administrators will need to fully understand their firewall and its settings. A lot of firewalls are configured to close connections after a certain period of inactivity. Although in theory this is a great feature for a firewall, when you're trying to run a terminal server session through this firewall it is not. Prolonged periods of inactivity within the terminal session (if someone steps away to a meeting, goes on break, or takes a phone call, for example) mean no packets are passed back and forth between client and server. So what happens is the firewall closes the connection resulting in a lost session for the user. Worse yet, more times than not due to the way the session is broken the terminal server ends up leaving the session in an active state and the end user cannot connect back to it without assistance from you. In these cases you might attempt using the keepalive or reconfigure the firewall so it doesn't drop idle connections.

To properly configure Keepalive, modify the following Registry keys:

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server DWORD "KeepAliveEnable" value should be set to 1 DWORD "KeepAliveInterval" value should be set to 1 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters DWORD "KeepAliveInterval" value in milliseconds DWORD "KeepAliveTime" value in milliseconds DWORD "TcpMaxDataRetransmissions" numeric value 

After setting these go into the Terminal Services Configuration Snap-In and under Sessions check the Override Users Settings box and chose Disconnect from Session.

Building Terminal Services the Right Way

Special thought and care should go into building a terminal server that is being used for the deployment of applications or desktops to end users. You should approach this with the knowledge that the end user is now effectively sitting down at the console of the server and working. As such the proper planning and building of the terminal server is critical to providing a stable, secure, and easy to use Terminal Server.

Because the end user is in essence sitting in front of the server it is your task to not only build the server so that the end user can run the applications necessary to work, but also restrict as much as possible of what the end user can do yet still work. An improperly locked down terminal server can and will spell disaster for the end users. Whether done purposely or accidentally , system changes, installation of third-party applications, deletion of files, and so on can equal downtime for all the users of that terminal server while you attempt to repair the damage.

Take the time up front to plan and build a securely locked down terminal server and it will pay off down the road in fewer support issues and less server maintenance.

One of the goals of managing an Application Terminal Server is to simplify security. One easy way to accomplish this is to break the server into three discrete partitions that can be secured independently. An example of a multipartition configuration would be as follows :

• Use C: for the Operating System4 gigs + pagefile space

• Assign D: for the applicationsdepends on how many apps you plan to installuse common sense

• Utilize E: for the temporary profilesdepends on how many concurrent users you have and if you do or do not use folder redirection and profile exclusions. If you do not use folder redirection or exclusions from the profile, the temporary profiles can grow to be very large. In the tens or even hundreds of megabytes. If you do use folder redirection and or exclusions profiles can be kept as small as a few hundred KB, generally growing no more than 24MB in size.

As you progress you will see that by breaking the server into three partitions you make things easier because the server has now been broken down into distinct categories that NTFS permissions can be applied to fairly easily without disrupting the functionality of the operating system or applications.

The C: drive will be for the operating system and system files only. By doing this, access to the C: partition can be locked down because there will be no user or application files here and thus no need for any accounts other then system and administrators to be able to write or even view the files.

The D: drive will be used as the target drive for application installations. It is advised that each application be installed into its own separate directory. For example install application A into D:\applicationA and application B into d:\applicationB not D:\program files\applicationA and d:\program files\applicationB. Different applications will require different file permissions to run correctly. If they are all installed into the same root directory it makes it a lot more tedious to secure with NTFS permissions.

That leaves the E: drive. This partition is set aside for the temp profiles terminal server creates during a session. Remember that even if you use roaming Terminal Server profiles, a local profile is always created for each session. By default Windows will place the users' profiles under C:\documents and settings\username. Because the goal here is to simplify securing the partitions you do no want to require any end user access to the C: partition and as such would rather have the profiles be created on the E: partition instead. To change the default behavior and move the profile location to the E: drive, the following steps must be performed.

1. Create a Documents and Settings Folder on the E: drive.

2. Modify this key to change where the local copy of the profiles is written. By default it is % systemdrive %\documents and settings.

3. Modify HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory Reg_Sz to a value of e:\Documents and Settings

4. Reboot the server.

5. Copy over the Default and All Users profiles to the new location.

Locking Down the Server with GPOs

Building the server with the three distinct partitions, installing applications into separate directories, and moving the location of the temporary profiles is a great foundation for building a great terminal server. This only the beginning.

Using GPOs you can effectively limit a lot of undesired activity on the terminal servers. Although GPOs cannot protect the terminal servers 100% they are a great tool to use to achieve your goal.

A simple way of managing the GPO(s) for your Terminal Servers is to create an OU for your terminal servers and place the servers into that OU, and create a group policy for them. In this example it is called Lockdown . In order to prevent the group policy from interfering with your ability to perform your duties on the box, you will want to modify permissions on the GPO so that the terminal server administrators, whomever they might be, have the Deny box checked next to Apply Group Policy. See Figure 20.3.

Figure 20.3. Setting Deny permission on the lockdown GPO.

This prevents the policy from being applied when you log in so you can still work. Remember that machine policies will still take effect, but most policies that would end up crippling you are user-based and as such won't be applied when you log into the server. Now you can safely modify settings in the lockdown GPO. What you do and don't do here really depends on your environment and the applications you're going to deploy. It is highly recommended that you configure a set of policies, test your environment, configure another set, and test again until you are completely satisfied.

The Office Resource Kit Has Templates You Can Add

If you're deploying Office, the Office Resource Kit has templates you can add to lock down and configure Office applications. Setting default file save locations, removing the Visual Basic editor, and much more can be done via GPO.

Locking Down Directory and File Permissions

Applying proper directory and file permissions is a very important step in locking down the terminal server. Although the GPOs do a great job of attempting to keep users from doing malicious or accidental harm to the system they are not enough. A good set of directory and file permissions are a crucial piece of the lockdown process. This is also the area that you need to take the most care. Restrictive directory and file permissions can end up causing undesirable side effects while running applications via Terminal Services. It is imperative you fully test to the best of your ability the functionality of all applications hosted via Terminal Services after every round of modifications to directory and file permissions.

Policy Templates Will Be Too Restrictive

Although policy templates might work great for a standalone server with the role of a print server or a file server, they will be too restrictive for Terminal Services. Always fully test the environment after applying the templates.