In Windows Server 2003, Microsoft has redesigned many aspects of Terminal Services. In the new OS, Remote Desktop supplants Windows 2000 Terminal Services' Remote Administration mode, client server encryption has been increased, and you can use Active Directory (AD) Group Policy to centrally perform most Terminal Services configuration management. However, properly securing Terminal Services remains a tricky process, in which you must balance the level of user access with data security. And each server in a given organization might require a different degree of lockdown. For example, consider the security contrast between a custom application running Terminal Services in a public kiosk and a server in your data center that only administrators remotely access through Remote Desktop. The former requires a high degree of lockdown, whereas the latter requires little Terminal Servicesspecific lockdown. Let's look at some of the major considerations behind locking down Terminal Services for Windows 2003.
New and Improved
Terminal Services is installed by default in every Windows 2003 and Windows XP setup. Multiple applications—including Fast User Switching, Remote Assistance, Remote Desktop, and Terminal Server—use this service to enable remote, interactive systems management. What we're concerned with in this article is securing the Windows 2003 server-based Terminal Services applications Remote Desktop and Terminal Server. For the most part, both applications use either local or remote Group Policy Objects (GPOs) to restrict user access. Remote Desktop is intended for systems administration tasks and limits connections to two users, plus a third connection to the console. Terminal Server's connections are designed for many concurrent user sessions, and capacity is generally determined by licensing and hardware constraints.
Terminal Services lets you remotely control a computer by using the Remote Desktop Connection client via the Remote Desktop Protocol (RDP). New to Windows 2003 is the RDP 5.2 protocol. This new version supports new mapping of services from the server to the client—for example, mapping printer ports, COM ports, the clipboard, drives, and even audio functionality. For example, you can connect to a remote computer and copy a snippit of text from Notepad, then paste it into an application on your host computer. Similarly, if you're at home accessing email from your work computer, your home speakers will play your work computer's audio alert when new mail arrives. You'll want to consider restricting these mappings, particularly if users are connecting to the Terminal Server system from an outside computer, such as a home system. For example, with drive mappings enabled, remote users can access their home computer's C drive directly from the Terminal Server session, making it simple to copy company files to the home computer. You should take similar precautions with your printers, COM ports, and even the clipboard. (Of course, you'll also want to restrict other access methods related to Terminal Server.)
By default, Remote Desktop and Terminal Server aren't installed. To discover any systems that are accepting Terminal Services clients, use your favorite port scanner and search your network for TCP port 3389, which is the network port that RDP uses. Positive hits indicate that a Terminal Server computer is listening.
Enabling Remote Desktop
Installation of Remote Desktop and Terminal Server occurs in two separate places in Windows 2003. To install Remote Desktop, go to the Control Panel System applet and click on the Remote tab. Select the Allow users to connect remotely to this computer check box. Next, choose the users that you want to be able to connect to the computer. This process adds users to the local computer's Remote Desktop Users security group. By default, only the members of the local Administrators group and the Remote Desktop Users group will be able to use a Terminal Services client to connect to this computer.
Behind the scenes, the Allow logon through Terminal Services user rights assignment in a domain or local GPO permits this action, but the System applet makes it easy to add users to this role. When you're auditing a computer to determine who can connect to Terminal Services, be sure to check out this GPO setting to ensure that this user rights assignment is correctly configured
Installing Terminal Server
Microsoft has rebranded the long-winded Windows 2000 Terminal Services Application Mode as simply Terminal Server. Before you install Terminal Server, think about how users and administrators of the Terminal Server system should be permitted access to the Internet. By default, Windows 2003 greatly restricts Microsoft Internet Explorer (IE) by way of the Windows component called Internet Explorer Enhanced Security Configuration. Built-in IE security zones (e.g., Internet, Local intranet, Trusted, Restricted sites) enable or disable certain functionality—for example, ActiveX controls and scripting are disabled for the Internet zone. Therefore, users might need to add sites to the Trusted zone so that the sites display properly. Although you can relax this setting for users (who generally operate with lower privileges), you probably don't want to relax it for administrators, who inherently have higher privileges and could put the system at greater risk if their system contracts a virus while visiting a malicious Web site.
Launch the Control Panel Add or Remove Programs applet, click Add/Remove Windows Components, and select Internet Explorer Enhanced Security Configuration. To relax the settings for regular users, clear the Users check box but leave the Administrators check box selected. (In this context, Microsoft defines Administrators as local administrators and power users.) Under this configuration, regular users will be able to browse Web sites as usual, but administrators operating under privileged and higher access will be more restricted in how they use IE.
To install Terminal Server, launch the Add or Remove Programs applet, click Add/Remove Windows Components, and select Terminal Server to launch the installation wizard. Terminal Server requires the presence of a Terminal Server License Server after the 120-day grace period—you'll want to configure such a server because licensing has changed significantly in Windows 2003. (For more information about Terminal Server licensing, see the Windows & .NET Magazine article "Take Control of Your TSCALs," May 2004, InstantDoc ID 42278.) Also, remember that if you install Terminal Server, you'll no longer be able to use Remote Desktop, because both applications use the same client and protocol. Effectively, the many-user Terminal Server replaces the user-limited Remote Desktop.
Next, choose whether to install Terminal Server's default permissions for application compatibility as Full Security or Relaxed Security. These two settings define how the registry and specific system files are restricted from Terminal Server users. In the more restricted mode, users don't have write access to specific application registry keys and critical system files—a situation that could hobble some legacy Windows NT 4.0 applications that require local Administrator access. If you have such applications, you can still run in Full Security mode. However, you must find the registry key that the application uses and edit the security access control entry (ACE) to allow your Terminal Server users to write to that registry key. This procedure might not work in all instances, so if you find that the legacy application still isn't working, you can revert back to Relaxed Security by using the Terminal Services Configuration (TSCC) tool, which I describe later. Relaxed Security introduces a security risk to your server because it allows users wider access to critical system files and registry entries that could be exploited by a worm, virus, or malicious user. So, use this mode only as a last resort. As with previous versions of Terminal Services, you might need to reinstall applications so that they work correctly with Terminal Server.
I don't recommend enabling Terminal Server on a domain controller (DC). For information about establishing a Terminal Server remote connection, see the Web-exclusive sidebar "Connecting to the Console," http://www.windowsitpro.com/windowssecurity, InstantDoc ID 48359.
Locking Down Terminal Server
Generally, locking down Terminal Server consists of restricting the users who can create a Terminal Server session and what they can do in the session, restricting data access through NTFS access control lists (ACLs), and using Active Directory (AD) GPOs and the TSCC to configure Terminal Server settings. Let's walk through each of those processes.
Restricting user access. Earlier, I mentioned the new Windows 2003 built-in local security group called Remote Desktop Users. You can also use this group to manage access to the computer when it's configured as a Terminal Server machine. Only members of this group and the local Administrators group have permission to log on remotely to the Terminal Server system (although you can change this permission in Group Policy, as mentioned). You can manage the membership of this group either from the System applet's Remote tab or directly from the Microsoft Management Console (MMC) Local Users and Groups snap-in.
In addition to adding users to the Remote Desktop Users group to control who can use the Remote Desktop Connection client to connect to the computer, you can further manage basic user permissions and privileges by assigning users to the local computer's various security groups. For example, a member of the computer Users group has limited access and privileges, but he or she can run applications, surf the Internet, and perform other basic functions. For a shared computer such as a Terminal Server system, this level of access is best. But if you need to grant users additional access, you can add them to built-in Windows groups such as Power Users or Administrators, or you can create your own group. By leveraging the Windows groups, you can quickly determine what users can and can't do on the Terminal Server system. In many cases, though, you'll want to further restrict certain files and folders or lock down the server even more.
Restricting data access. Whereas the previous option restricts the user's access to actions such as installing files and modifying system settings, you might still want to lock down specific applications or data on the Terminal Server system's hard disk. To restrict access to particular applications, you can apply a Software Restriction Policy GPO or set NTFS ACLs on the directories of the applications that you want to restrict. The GPO route is advantageous because you can link the GPO to a Domain, Site, or OU AD object, and that GPO will be enforced for any objects within that container. For example, if you manage many Terminal Server systems and you need to add a server, you can configure it and move it to the GPO-enabled OU. After you restart the computer or run the command gpupdate.exe to update the GPO for its new OU, it will be locked down like the others in that OU.
To apply a Software Restriction Policy GPO, first create a new GPO. In the Group Policy Object Editor's left pane, navigate to User Configuration, Windows Settings, Security Settings, Software Restriction Policies and right-click New Software Restriction Policies to create a new policy. In the right pane, you'll see two new folders, titled Security Levels and Additional Rules, as well as the Enforcement, Designated File Types, and Trusted Publishers items. The most important pieces to define in a basic policy are Enforcement, Security Levels, and Additional Rules. Let's take a look at each one.
First, double-click the Enforcement object to invoke the Enforcement Properties dialog box, in which you'll define who and what the software-restriction policy affects. Your enforcement options are twofold. First, you can determine whether the policy affects All software files or All software files except libraries (such as DLLs). Remember that one executable file might reference a large number of libraries. If you select All software files, you must identify not only the primary executable (e.g., winword.exe) but also all of Microsoft Word's DLL files—an onerous task. Selecting All software files except libraries (such as DLLs) means you need only identify the primary executable. Most often, you'll achieve an adequate level of security by setting your enforcement to All software files except libraries (such as DLLs). The second item in the Enforcement Properties dialog box lets you specify whether the policy affects All users or All users except local administrators. If you don't want your software-restriction policy to apply to local administrators, apply the policy to All users except local administrators. Click OK to close the Enforcement Properties dialog box.
Now, open the Security Levels folder. In the Group Policy Object Editor's right pane, you'll see two property nodes: Disallowed and Unrestricted. You must set one of these options as the default security level for your Software Restriction Policy. The default security level, Unrestricted, lets all programs run. If you go with Unrestricted, you must define—in Additional Rules—specific programs (e.g., ping.exe, ipconfig.exe) that you want to prevent users from running. The Disallowed level prevents all programs not explicitly defined as unrestricted in Additional Rules from running. When you create a new Software Restriction Policy, Windows creates four Additional Rules that permit applications in \%systemroot%, executables in \system32, and applications in Program Files to run unrestricted. These rules let the Terminal Server system operate even when it's configured under the more restrictive Disallowed Software Restriction Policy. You must create Additional Rules for every program that you want to override the default security level. To create your Additional Rules, right-click the Additional Rules node in the left pane of the Group Policy Object Editor, under Software Restriction Policies. (See the Web-exclusive sidebar "Using GPOs to Restrict Software," InstantDoc ID 43860, for details about creating and using Additional Rules.)
For more local and granular access control over any file or directory, consider applying NTFS ACLs that restrict access to these resources. Generally, NTFS ACLs don't scale as well as GPOs, which you can manage centrally; however NFTS ACLs let you discretely restrict access on a per-file or per-folder basis. For example, if you install a human resources (HR) application or other limited-access software, you could apply Read and Execute access to only the HR security group. Also, consider modifying the default NTFS ACLs on your Windows 2003 server. For example, by default, all members of the Users group can create files and folders and write or append data on the root drive. Of course, if you edit root-level ACLs, be careful that inheritance doesn't prevent programs in subfolders from running.
Fine-tuning security configuration through a GPO. You can use a GPO to lock down the Terminal Server computer, the users who access it, or both. A GPO consists of both a computer configuration and a user configuration, but each configuration is potentially invoked from separate GPOs, depending on where the computer and user objects reside. The user configuration is applied from the GPO linked to the OU in which the user object resides, and the computer configuration is applied from the GPO linked to the OU in which that user's computer resides. Typically, when a user logs on to a Terminal Server machine, the user configuration from the user GPO and the computer configuration from the computer GPO are used. However, this scenario might not be appropriate when you want to lock down a commonly accessed Terminal Server machine. You might prefer that the user have greater access at his or her workstation than at the shared Terminal Server system. Unfortunately, because the user configuration is associated with the user object (not the computer), the same user-configuration GPO will be applied regardless of which computer the user logs on to. However, you can solve this problem by using a GPO setting called loopback processing.
With loopback processing, you can apply a GPO on an OU containing the Terminal Server computer object that also applies to users contained elsewhere. Doing so lets you configure both computer-configuration and user-configuration GPO settings for the OU containing the Terminal Server computer. Therefore, you can force the Terminal Server GPO's user-configuration settings on any user who logs onto the server. Any user who logs on to the Terminal Server system will be governed by that system's user-configuration GPO instead of any other GPO that might be applied to the user. In the Group Policy Object Editor, navigate to Computer Settings, Administrative Templates, System, Group Policy and enable the GPO policy called User Group Policy loopback processing mode. When you enable this policy, you must select whether to replace or merge the user-configuration settings between the Terminal Server computer GPO and the user's native GPO. If you choose to merge settings, a combination of the user's GPO and the Terminal Server computer's GPO will be in effect. Choosing to replace the settings effectively forces the Terminal Server machine's user configuration onto any user who logs on to the machine. For example, if you place the Terminal Server computer in an OU linked to a restrictive GPO configured with loopback processing, any users who log on to this computer will be restricted under the Terminal Server machine's user-configuration GPO instead of their own user GPO, as Figure 1 shows.
A new feature in Windows 2003 lets you make the majority of Terminal Server security configurations directly through a GPO. From the Group Policy Object Editor, navigate to Computer Configuration, Administrative Tools, Windows Components, Terminal Services to find the Terminal Serverspecific settings. You can also find a small subset of these settings under a similar structure in the Group Policy Object Editor's User Configuration node. Web Table 1 (http://www.windowsitpro.com/windowssecurity, InstantDoc ID 43826) shows the Terminal Server securityrelated policies and their recommended settings. The settings in Web Table 1 increase security, reduce or limit the number of extra sessions that intruders can use as a basis for Denial of Service (DoS) attacks, and reduce the number of latent processes or sessions that result from users forgetting to log off.
Fine-tuning security configuration through TSCC. You can also configure most Terminal Server security settings directly on a Terminal Server computer by using the TSCC tool. (However, if you've set a GPO, the GPO will have priority and the equivalent setting in TSCC will be unavailable.) Launch TSCC from Administrative Tools, Terminal Services Configuration. In the left pane of the resulting dialog box, you can choose to configure Connections or Server Settings. First, click Server Settings, as Figure 2 shows. In the right pane, you'll find two important security settings: You can change the aforementioned Permission Compatibility mode (Full Security or Relaxed Security), and you can choose to restrict each user to one session. Limiting users to one session decreases the possibility of programs in abandoned (or spawned) sessions affecting other users of the Terminal Server system.
The remaining TSCC security configuration occurs in the Connections node. Expand the node, right-click the RDP-Tcp connection, and click Properties to access the RDP-Tcp Properties dialog box. This dialog box contains many of the settings that you can also configure through a GPO, as Web Table 1 shows. On the General tab, you can specify the encryption you want to use. By default, Terminal Services uses Client Compatible encryption, which first attempts 128-bit encryption but will ratchet down to find a level that's usable by the client. The High encryption level forces 128-bit encryption, and the Low encryption level uses 56-bit encryption only from the client to the server. (The other levels provide encryption in both directions.) The FIPS Compliant level meets the Federal Information Processing Standard (FIPS) 140-1 government standards for encryption and is the highest setting that Terminal Services offers. If you're using a strictly Win2K or later network, specify an encryption setting of High to ensure an adequate level of encryption between server and client. You can also require that the Terminal Server computer use standard Windows authentication to authenticate users instead of an alternative authentication system that you might have installed.
Also in the RDP-Tcp Properties dialog box, you'll find a Permissions tab that lists the Terminal Server computer's security descriptors. These descriptors list the users and groups that can perform functions (e.g., log on, take remote control, query or set information, send messages to other sessions, connect or disconnect sessions) on the Terminal Server machine. By default, the local Administrators group and the SYSTEM account have Full Control over these functions, and the Remote Desktop Users group has User Access, which permits the group to log on, connect, and query information. Additionally, the LOCAL SERVICE and NETWORK SERVICE accounts have access to query information and send messages to users. If you don't use Group Policy, be sure to visit the RDP-Tcp Properties dialog box's Client Settings tab and consider disabling Drive mapping, Windows printer mapping, LPT port mapping, COM port mapping, and Clipboard mapping. If computers outside your company access this Terminal Server computer, you should disable these mappings because they provide easy methods to transport data from the Terminal Server computer to another computer.
Beyond Terminal Server
In addition to configuring the security of the Terminal Server computer, you should also consider locking down specific computer features that aren't necessarily appropriate for a shared-access computer. For example, you might want to prevent users from shutting down the computer, restrict access to search functions, prevent browsing the hard disks, and redirect base folders.
Redirecting base folders such as Application Data, Desktop, My Documents, and Start Menu moves these folders to a common location other than the Terminal Server machine. In the Group Policy Object Editor, navigate to User Configuration, Windows Settings, Folder Redirection, and specify the preferred locations for these files.
You can also limit accessibility to security options (e.g., shutting down and locking down the computer), Windows Explorer, Task Manager, Start Menu, and the Task Bar to remove tempting server options such as managing the computer, easily browsing the C drive, and exploring the system's hardware. Web Table 2 lists many of the GPO-supported configuration settings that control accessibility. However, remember that some of these features improve the user experience, so you'll want to review each and weigh usability against security.
Before implementing any of the GPO policies that Web Table 1 and Web Table 2 show, be sure to try them in a test environment that reflects your normal business processes. For example, some patch-management programs distribute patches by means of creating tasks, so if you've locked down tasks for your Terminal Server system, these applications might fail.
You can find many other GPO lockdown settings by editing the GPO linked to your users or Terminal Server computer (when in loopback processing mode). In the Group Policy Object Editor, navigate to User Configuration, Administrative Templates, Windows Components. These templates let you further restrict what users can do. For example, you can lock down IE, NetMeeting, and other applications. Additionally, under User Configuration, Administrative Templates, Control Panel, you can restrict many Control Panel applications (e.g., Add or Remove Programs, Printers and Faxes, Display, Regional and Language Options). Similarly, under User Configuration, Administrative Templates, Network, you can configure whether the system permits users to manipulate offline files and network connections.
A Multifaceted Approach
To lock down Terminal Services, you need to set appropriate user roles—for example, a regular user shouldn't be able to change the time or install programs. You can further restrict access to applications or data either by using software-restriction policies or by setting NTFS ACLs. You can dissuade users from casually poking around on your Terminal Server machine by turning off many of Windows Explorer's search and navigation features. And granular GPO settings can prevent even privileged groups such as Power Users and Administrators from changing the Terminal Server system's configuration or accessing inappropriate data. In Windows 2003's new version of Terminal Server, you'll find granular settings to satisfy any installation.
