Taking a fresh look at Terminal Services security

Terminal Services is used to simplify application management, but many admins neglect security on the client side of client/server environments. Learn how to mitigate risk.

Many organizations deploy Windows Terminal Services to simplify application management and increase overall security. But Terminal Services environments pose security challenges because many organizations neglect their client computers. They may do this because they view them as insignificant compared with servers. Ironically, the client computers often pose the greatest threat to an organization's overall security.

Below are ways to secure Terminal Services clients.

Why are clients neglected?
Not every organization neglects their Terminal Services clients, but it happens often enough that the subject needs to be addressed.

Client computers tend to get neglected because administrators feel no one is going to be working within the client computer's local operating system. Theoretically, users should turn on their computers in the morning, connect to the terminal server and do all of their work within a hosted environment. This assumption leaves the client computer's local resources vulnerable. In some cases, it may also open the door for data theft. This can occur as a result of Trojan horses installed on a client computer or a malicious user who uses redirection to copy data from the Terminal Services session to local resources.

Are client computers domain members?
Being a domain member is not a requirement for establishing a Terminal Services session. Users must have domain accounts, but the client computer's only job is to run the software that attaches the client to the terminal server. The actual authentication does not take place until the user is connected to the terminal server.

In some cases, this behavior is the norm. For example, Windows Server 2008 allows a remote user to establish a Terminal Services session using a Web browser. You probably wouldn't expect a remote user logging in from who knows where to use a computer in your domain. If users are using computers directly connected to your network, those computers should be made domain members so group policies could be applied.

Why use group policies?
If users are not working in the client computer's local operating system, then why bother securing client computers with group policies?

The answer is you need to be able to control access to local resources. You don't want users to be able to install unauthorized applications, tinker with system settings or infect their computers with malware.

Group policies can be constructed so none of the usual Start menu options or desktop icons are available to end users. When a user logs into the network, the group policy can tell Windows to launch a Terminal Services session and to make sure no other resources are accessible to users.

If you want to lock down the options available through the client computer's Start menu and taskbar, navigate through the Group Policy Object Editor to User Configuration\Administrative Templates\Start Menu and Taskbar.

There are many settings you can use to make various Start menu and taskbar options inaccessible to users, shown in Figure 1.

Figure 1: You can use the Group Policy Object Editor to lock down the Start menu and taskbar (Click to enlarge).

Keep in mind that any group policy settings you apply to the users will typically apply globally. In other words, if you create a domain-level policy that removes all of the options from the user's Start menu, then those options will also be removed from the Start menu that the user sees in the Terminal Services session.

If users need to access Start menu and taskbar options from a Terminal Services session, then you will have to design the group policies so they won't interfere with the Terminal Services session. Since the policies apply to the user accounts rather than to computer objects, fixing the problem isn't as simple as moving the accounts for the client computers to a dedicated organizational unit (OU) and then applying group policies at the OU level.

One option is to give users two separate accounts.

For example, you could create a generic account everyone uses to log into their local PCs, and then use separate user accounts for Terminal Services sessions. Of course, you will have to come up with a way of keeping users from logging into their local computers using their Terminal Services accounts. One idea might be to create separate forests for client computer accounts and for the accounts used for logging onto client computers.

Another way to keep user policies from applying globally is to apply the Start menu and taskbar restrictions at the local computer level of the group policy hierarchy. That way, the restrictions would apply when users log into their local computers, but they wouldn't apply when the users log into their Terminal Services sessions. The downside to this technique is that Microsoft doesn't provide a mechanism for centrally managing local security policies.

Additional group policy settings
In addition to using Group Policy settings to lock down the Start menu and task bar on client computers, there are a couple more things group policies should be used for.

One is to design the group policy so that the Terminal Services client is automatically loaded when the user logs into the system. Typically, a .RDP file that contains all of the parameters for connecting to Terminal Services will be created and then installed onto each client computer. Afterwards, a setting that causes the .RDP file to load automatically as soon as a user logs into the computer can also be created.

The relevant group policy setting located can be found at User Configuration\Administrative Templates\System\Logon. The actual policy setting needed to configure is "Run These Programs at User Logon."

When the .RDP file that users will use to connect to Terminal Services is created, you will notice that there are a lot of configuration options. For example, you can control whether or not resources such as printers, drives and even the Windows clipboard can be redirected. If the goal is to prevent data theft, then locking down these options is essential.

Although typically the various .RDP file options will be configured before the .RDP file is deployed to the client computers, there is nothing to stop users from modifying the settings to meet their own needs. Fortunately, there are a number of group policy settings that you can use to control data redirection and various other Terminal Services settings. You can access these group policy settings at Computer Configuration\Administrative Templates\Windows Components\Terminal Services. Notice that these are computer-level group policy settings.

Client computers are one of the biggest security threats in an organization that depends on Terminal Services, but now you know some ways of locking down the client computers and mitigating these threats.

ABOUT THE AUTHOR:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). He has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Posey has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit his personal website at www.brienposey.com.

This was first published in October 2009

Dig deeper on Terminal Services and Remote Desktop Services

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchEnterpriseDesktop

SearchServerVirtualization

SearchCloudComputing

SearchConsumerization

SearchVMware

Close