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.