Securing Terminal Services

Securing Terminal Services

Once you have identified the threats facing your Terminal Services deployment, you can take action. The measures you can take include the following:

• Choose the correct Terminal Services mode.

• Restrict which users and groups are assigned the Log On Locally user right.

• Prevent remote control on terminal servers.

• Restrict which applications can be executed.

• Implement strong encryption to data transmitted between the client and server.

• Strengthen the security configuration of the terminal server.

Choosing the Correct Terminal Services Mode

When you install Terminal Services on a Windows 2000 server, you must select between two modes: remote administration mode and application server mode.

Remote Administration Mode

Remote administration mode, by default, allows only members of the local Administrators group to connect by using Terminal Services. Nonmembers cannot connect to the terminal server, and the maximum number of simultaneous connections is two.

Remote administration mode should be implemented when administrators require the ability to remotely manage servers such as domain controllers. Microsoft recommends you implement Terminal Services only in remote administration mode on domain controllers so that nonadministrators are not assigned the Log On Locally user right.

Application Server Mode

Application server mode allows Terminal Services clients to connect to the terminal server and run any installed applications. The only limiting factors to the number of simultaneous connections that can be made are the physical hardware implemented for the terminal server and the number of licenses you have purchased. For example, if the users implement applications that are processor dependent, such as Microsoft Excel, you should allocate 10 MB of RAM for each Terminal Services client session.

Microsoft recommends you implement application server mode on member servers when you want users to run an application remotely. For example, you might consider using Terminal Services to deploy an application with a corporate security policy that does not allow it to be run locally on multiple client computers. Terminal Services allows the application to be run from a single location (at the terminal server), rather than at each of the remote client computers.

You also can use Terminal Services when client computers on your network do not have sufficient hardware to run Windows 2000 Professional or Windows XP Professional. In these cases, clients can connect to a server by using application server mode to gain access to a full Windows 2000 desktop without upgrading the client OS to Windows 2000 Professional or Windows XP Professional.

Installing applications once Terminal Services is installed in application server mode has its issues. Applications must be installed to allow execution by remote users. We recommend you either run the command Change User/Install in a command prompt before installing applications or install all applications by using the Add New Programs option in the Control Panel s Add/Remove Programs applet.

Restricting Which Users and Groups Have the Log On Locally User Right

The Log On Locally user right is required to connect to a Windows 2000 terminal server. You can restrict which users or groups can connect by using Group Policy to define the users or groups assigned the Log On Locally user right.

To ensure consistent application of the user rights, consider placing all terminal servers in the same OU and defining the user rights in a Group Policy object (GPO) linked to the OU. Ensure that terminal servers are dedicated terminal servers or that they do not host other network services or data that would restrict the assignment of the Log On Locally user right. For example, it is not a good idea to install Terminal Services in application server mode on a domain controller because nonadministrators would require the Log On Locally user right.

Preventing Remote Control on Terminal Servers

Remote control allows administrators to view session actions of a Terminal Services connection. In addition to allowing administrators to view sessions, remote control enables them to perform actions in Terminal Services sessions. These actions are performed in the security context of Terminal Services users, allowing administrators to impersonate users.

You can restrict the use of remote control either in the properties of each user account or in the Terminal Services Configuration console in the properties of the Remote Desktop Protocol Transmission Control Protocol (RDP-TCP) connection object.

In the properties of a user account, in the Remote Control tab, you can choose whether to enable remote control. If you do not want remote control capabilities for a user s Terminal Services connections, disable the Remote Control check box. If you do require remote control capabilities, enable the Enable Remote Control option. In addition, you should enable the Require User s Permission option to prevent an administrator from spying on a Terminal Services user. When you enable remote control, you must decide how an administrator interacts with the Terminal Services user. You can choose between the following options:

• View The User s Session

  The administrator can only view the user s actions from a remote location.

• Interact With The Session

  The administrator can take control of the user s session and perform actions on behalf of the user.

  If you allow administrators to interact with the Terminal Services connection, they will be able to perform actions in the security context of the user.

Alternatively, you can override individual user remote control settings by defining the default remote control settings in the Terminal Services Configuration console at the terminal server. Settings defined in the Remote Control tab of the RDP-TCP Properties dialog box override any individual user s remote control settings.

Restricting Which Applications Can Be Executed

Rather than allowing Terminal Services users to connect to any application running on the Windows 2000 terminal server, you can restrict which applications they can execute. You can choose to either restrict users to a single application or create a list of approved applications that can be executed in a Terminal Services session.

Restricting Terminal Services Sessions to a Single Application

In the Terminal Services Configuration console at the terminal server, you can configure Terminal Services to execute a single application rather than launch the Windows desktop. This setting is defined in the Environment tab of the RDP-TCP Properties dialog box. When you enable the option to override settings from the user profile and Client Connection Manager Wizard, you must define which application executable is launched and which folder is the default folder.

When Terminal Services is configured to launch a single application, the application is immediately launched when a user connects to a terminal server. When the user exits the application, the Terminal Services session terminates.

Configuring Terminal Services to launch a single application does not preclude the user from launching another application from within that single application. For example, if you restrict a Terminal Services user to running Microsoft Word, nothing will prevent that user from launching Explorer.exe from a Word macro.

Restricting Terminal Services Sessions to Specified Applications

In most cases, you will want to restrict which applications are available to Terminal Services users. By using the Microsoft Application Security tool (Appsec.exe) from the Microsoft Windows 2000 Server Resource Kit (Microsoft Press, 2000), you can control which applications can be executed.

The Appsec.exe tool allows you to designate which executables are available to Terminal Services users when they connect to a terminal server running in application server mode. Each application is referenced by its full path. For example, C:\Program Files\Microsoft Office\Office10\Winword.exe is the default path for Microsoft Word 2002. If you copy the Winword executable to another folder, the Appsec.exe tool blocks its execution.

The Appsec.exe tool does not perform any hashing functions on the executable. The tool only looks at the full path of the executable to determine whether the application is allowed to run. If attackers are able to overwrite the allowed application, they can run that application in place of the approved application. For example, if attackers overwrite Winword.exe in the path detailed previously with Cmd.exe, they can gain access to a command prompt.

Once the Application Security tool is enabled, nonadministrators are limited to the applications included in the listing. Default applications are included in the Appsec.exe tool. You should review the default applications listed and determine whether you need them in your environment. Administrators of a computer are not affected by the Appsec.exe restrictions and can run any application loaded at the terminal server.

If you implement the Appsec.exe tool, ensure that you also apply the patch discussed in 257980, Appsec Tool in the Windows 2000 Resource Kit is Missing Critical Files.

Implementing the Strongest Form of Encryption

Terminal Services can implement different levels of encryption to protect data transmitted between the Terminal Services client and the terminal server. The level you select should be based on your company s security policy.

The Terminal Service encryption level is defined in the Terminal Services Configuration console via the General tab of the RDP-TCP properties of the terminal server. You can choose from the following encryption levels:

• Low encryption

  Network traffic is encrypted only when sent from the client to the server. Data is encrypted by using the RC4 encryption algorithm with either a 40-bit key or a 56-bit key. The 40-bit key is required for RDP 4.0 clients. RDP 5.0 clients implement a 56-bit key by default. This encryption format protects passwords input by users but does not protect the screen data returned from the server to the client.

• Medium encryption

  Network traffic is encrypted in both directions as it transmits between the client and server. Data is encrypted by using the RC4 encryption algorithm with either a 40-bit key or a 56-bit key.

• High encryption

  Network traffic is encrypted in both directions as it transmits between the client and server. Data is encrypted by using the RC4 encryption algorithm with a 128-bit key and requires the installation of the Windows 2000 High Encryption Pack at both the client and server. If the High Encryption Pack is not installed, encryption will fall back to the 40-bit or 56-bit key used for medium encryption.

  High encryption is limited to countries/regions that the United States does not have an embargo against. For more information on the export of High encryption, see http://www.microsoft.com/exporting.

Strengthening the Security Configuration of the Terminal Server

You can increase the default security configuration of the terminal server by installing Terminal Services with the Permissions Compatible With Windows 2000 Users option enabled. The default setting, Permissions Compatible With Terminal Server 4.0 Users, allows users connecting with Terminal Services clients to modify critical registry and file system locations. Access is granted by using the TerminalServerUser account in discretionary access control lists (DACLs).

If you install Terminal Services with Permissions Compatible With Terminal Server 4.0 Users, you can strengthen the security by implementing the Notssid.inf security template. This template reverses weakened security settings and ensures that registry and file system permissions do not refer to the TerminalServerUser account. To implement the Notssid.inf security template, have a local administrator run the following command at the terminal server:

secedit /configure /db notssid.sdb /cfg notssid.inf /log notssid.log /verbose

This command applies the Notssid.inf security template and records a log file in a file named Notssid.log.