Securing Windows 2000 Terminal Services
By David Mackey
Microsoft® Windows 2000 Terminal Services gives the Windows 2000 Server operating system the capability to serve the 32-bit Microsoft Windows® operating system-based applications to terminals and terminal emulators running on PC and non-PC desktops. The Terminal Services environment is, by definition, a thin-client architecture where all application processing occurs centrally on the server. Therefore, it is important to protect the integrity of the data stored on the Windows 2000 Server as well as the data in transit among the Terminal Services application and its clients. This paper presents the information necessary to implement strong security within your Windows 2000 Terminal Services environment.
On This Page
Windows 2000 Security
The Information Security chain is only as strong as its weakest link. With Microsoft's Terminal Services application, the information security chain includes the physical location of the Windows 2000 Server, the Windows 2000 operating system, the Terminal Services application, and the network communication that occurs among the Terminal Services application and its clients. You should use a comprehensive security plan to review and strengthen all of these security aspects on a regular basis.
Note: This paper will not address specific measures to ensure the physical security of the Windows 2000 Server. To read more about physical-security considerations, refer to the following white paper at http://www.microsoft.com/technet/security/bestprac/bpent/sec1/secstrat.mspx. In addition, Microsoft has published a security strategy white paper that can help prepare the overall security plan for an organization. You can find the paper at: http://www.microsoft.com/technet/security/bestprac/bpent/sec1/secstrat.mspx.
To provide a secure foundation for the Terminal Services application, the Windows 2000 operating system must first be hardened against the threat of malicious activity. The two major categories of malicious activity that you need to protect against are a malicious computer user that has physical access to the Windows 2000 Server or a malicious computer user that has access to the server over a network connection. These two categories of threats should also be considered with the idea that the malicious user can be an unauthorized user or a user who already has some level of access within the environment (e.g., an employee). The hardening process eliminates opportunities for both types of unauthorized access to the server and the data stored within.
The first step in the hardening process is to start with a clean and updated Windows 2000 installation. This process involves repartitioning the hard drive(s), formatting the drive(s), and installing from known good software media. Next, install all the latest Windows 2000 patches by visiting http://update.microsoft.com/microsoftupdate/ for an automated list of applicable patches or by visiting http://www.microsoft.com/downloads/ to manually install the necessary updates.1
After you install the latest software, you must evaluate the server's security settings against the principle of "least privilege." This principle states that information consumers should be granted only the minimum level of access that allows them to do their jobs. For the Windows 2000 operating system, the Security Configuration and Analysis snap-in is a useful tool that can automate much of this process.
The Security Configuration and Analysis tool evaluates the system against predefined security policies and reports those settings that should be changed to improve the security of the system. By default, Windows 2000 includes three basic types of templates: basic, intermediate, and high security.2 The basic security template is the lowest-level security, and the high-security template offers the highest level. These templates review settings associated with password policies, auditing options, account lockout, and a variety of other security settings. After the initial evaluation, you can then use the Security Configuration and Analysis tool to implement the security setting recommendations.
Note: The Security Configuration and Analysis tool has a command-line based sibling—secedit.exe—that can run effectively in a automated batch file or script. To learn more about both tools, refer to the Microsoft article at http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/seconfig.mspx.
In addition to the security settings built into the Windows 2000 operating system, there are a number of additional tools, processes, and configuration changes to help improve the overall security of the server. For more information, refer to Windows 2000 Security Checklist at http://www.microsoft.com/technet/security/chklist/default.mspx.
Terminal Server Security
With the Windows 2000 operating system installed, updated, and secured, it is time to install and secure Terminal Services. You need to make a number of decisions before and during the setup process to help secure the Terminal Services application. For more information on installing and configuring Windows 2000 Terminal Services refer to http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgbm_win_vrci.asp.
Planning
There are several architectural scenarios that you should consider before installing Terminal Services. Each will have its own consequences or benefits within the computing environment.
| • |
Grant access to the Windows 2000 system running Terminal Services using the principle of "least privilege." This scenario imits the users who have access to only those with a business need (e.g., control access using a specific security group other than Users or other generic groups). A separate security group gives administrators more granularity in segregating users. In addition, this scenario limits the abilities users have within the Terminal server environment. |
| • |
Avoid installing Terminal Services on a domain controller for application sharing. Users or groups that access the Terminal Server must have the Log on Locally permission. If Terminal Services is installed on a domain controller, users would have the Log on Locally permission for all domain controllers within the domain. Terminal Services should only be installed on domain controllers in Remote Administration mode only. In addition, the Log on Locally permission should be granted only to administrators. |
| • |
Whenever you install new applications on a Windows 2000 Server, ensure that you reapply the latest service pack and updates. Newly installed applications might make the security patches less effective. In addition, review the files and directories that the new application creates to ensure that the permissions are consistent with the rest of the system security. |
Installation
Although this paper will not cover every step of the installation process, there are two decisions that will affect the security of the Terminal Server. In sequential order during the installation process, here are the considerations:
| • |
Do not enable the application sharing aspect of Terminal Services if the only intention is to enable remote access for administration purposes. The Remote Administration mode allows administrators sufficient access to their servers and restricts the number of concurrent connections to two. |
| • |
Select the Permissions compatible with Windows 2000 server option. This will restrict access to the registry and critical system files. The Permissions compatible with Terminal Server 4.0 users option is intended for legacy applications that may still require this type of open access. Avoid this option unless absolutely necessary. |
Post-Installation
After you install Terminal Services, ensure that the latest patches for Terminal Services are installed by visiting http://update.microsoft.com/microsoftupdate/ for an automated list of applicable patches or by visiting http://www.microsoft.com/downloads/ to manually install the necessary updates. Although patches might have been applied after installing Windows 2000, it is important to apply the necessary patches that address specific vulnerabilities that might exist within Terminal Services.
In addition to the security settings that you must implement with Windows 2000, use the Security Configuration and Analysis tool to apply security settings specific for Terminal Server. The template notssid.inf secures a variety of files and registry settings to limit the areas users can stray.
Also, there are a number of configuration changes that you need to make to the server to increase the security associates with Terminal Services. All of these settings can be accessed through the Terminal Services Configuration tool (Start -> Settings -> Control Panel -> Administrative Tools -> Terminal Services Configuration -> Server Settings).
Here are the various configuration settings and recommendations:
| • |
Terminal Server mode – This setting offers administrators the option to change the Terminal Server mode of operation from Application Server to Remote Administration and vice versa. The only recommendation is to use the Application Server mode only when necessary. |
| • |
Delete temporary folders on exit – Data that is required to support the environment and applications during the Terminal Services session can be created in temporary folders (see the next setting). These temporary folders can be removed after the user logs off. The recommended setting is Yes to ensure malicious computer users cannot access the environmental information stored in the temporary folders. [Default: Yes] |
| • |
Use temporary folders per session – See the previous setting's explanation. The recommended setting is Yes, again to ensure that the environmental data is not left for malicious use. [Default: Yes] |
| • |
Internet Connector licensing – This setting is designed for those environments that plan on sharing applications over the Internet using the Terminal Services Internet Connector. The recommended setting is Disable, but more importantly, you must consider sharing applications over the Internet very carefully. This type of application sharing opens both the server and any network connections to possible manipulation from millions of Internet users. |
| • |
Active Desktop – This setting allows client sessions to use Active Desktop. Because Active Desktop can unknowingly execute a number of scripts and other technologies embedded in Web pages, Active Desktop is not recommended. Use the Disable setting to avoid this vulnerability. [Default: Enable] |
| • |
Permission Compatibility – You can use this setting to change the choice of permissions selected during the installation process. Again, use the Windows 2000 Users setting to secure additional system files and registry settings. |
Terminal Services Network Security
In a typical computing environment, a user logs on to a workstation or server to perform necessary computing tasks. The computer will take input from the keyboard, mouse, and a number of other devices and process the information required. The computer then displays the output on the monitor or sends the output to another device, such as a disk drive or printer.
The Terminal Services' architecture is designed to perform the processing tasks on the server, convert all output into network packets and pass this data to a remote client over the network. Therefore, if a malicious user intercepted these network packets, the user would be able to see all actions performed on the Terminal Server, including every mouse movement, keystroke, and any other data manipulated within the Terminal Services session. Therefore, it is crucial to protect this network data.
Windows 2000 Network Security
Windows 2000 comes with a variety of features to help protect data in transit. Internet Protocol Security (IPSec), built-in support for Virtual Private Networks (VPNs), and support for a variety of remote authentication protocols will help to secure communications to and from the Windows 2000 Server. All of these security features provide another layer of protection around Terminal Services communications. For more information on securing network traffic on Windows 2000, please refer to Microsoft's white paper located at http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-us/deploy/dgfb_emp_amgd.asp.
Remote Desktop Protocol Introduction
Remote Desktop Protocol (RDP) is based on the International Telecommunications Union (ITU) T.120 protocol family of standards. RDP forms the basis for all communication between the Terminal Services server and client. Incorporated in the protocol is its own video driver on the server side to render display output into network packets and send them over the network to the client. On the client side, the Terminal Services client receives rendering data and interprets it into the corresponding Win32® graphics device interface (GDI) API calls. On the server side, RDP uses its own virtual keyboard and mouse driver to receive keyboard and mouse events, such as mouse clicks and individual keystrokes.
To help protect this information while in transit, Microsoft has built encryption into both the Terminal Services client and server using RSA Security's RC4 cipher. This variable key-size stream cipher quickly modifies communication data into encrypted network packets to be sent between server and client. This encryption algorithm is also commonly used for the Secure Socket Layer (SSL) protocol that is used to secure communications over the Internet.
Encryption Levels
Terminal Services offers three general levels of encryption for communication: low, medium, and high.
| • |
Low – Using this setting, Terminal Services encrypts data sent from the client to the server, but not the data sent from the server to the client. This encryption mode uses a 56-bit key length to encrypt data.3 However, the obvious weakness with this mode is the length of the key. Today's standards advise a key length of 128-bit or higher for a high level of security. In addition, the communication from the server to the client is still susceptible to eavesdropping. This mode of encryption is the least secure and should be avoided. |
| • |
Medium – This encryption mode ensures that encryption is applied in both situations—data sent by the client and data sent by the server–. Again, this mode uses a 56-bit key length to encrypt data, which is a smaller key length than is recommended.4 Forego this option in favor of the High encryption setting if possible.5 |
| • |
High – Similarly to the Medium setting, this setting ensures data is encrypted in both directions between the server and client; however, the key length is 128-bit. Even within trusted networks, this encryption mode is the recommended setting. The High setting prevents the possibility of a malicious computer user breaking into the network and installing a network packet analyzer to eavesdrop on the Terminal Services sessions. |
RDP Configuration Settings
Although the encryption mode might be the most important security decision concerning RDP, there are a number of other configuration settings that you need to review to further increase the level of security for Terminal Services.
Below are the various configuration settings and recommendations. All of the following settings can be accessed through the Terminal Services Configuration tool (Start -> Settings -> Control Panel -> Administrative Tools -> Terminal Services Configuration -> Connections -> RDP-Tcp).
| • |
General sheet
| • |
Encryption level – Choose the encryption level based on the recommendations within the previous Encryption Levels section. [Default: Medium] |
| • |
Use standard Windows authentication – If another authentication package is installed on the target Windows 2000 Server, this setting will force Windows 2000 to use its own authentication mechanism. If there is no other authentication package installed, leave this box unchecked. [Default: Unchecked] | |
| • |
Logon Settings sheet
| • |
Use client-provided logon information – Enabling this setting requires the client to enter the necessary user, domain, and password to gain access to Terminal Services. The setting prevents a malicious user from automatically gaining access using a saved account and password on the server. [Default: Selected] |
| • |
Always use the following logon information – This setting allows all Terminal Services clients to use the logon information provided within the associated frame. Because auditing features would always show the same user account as logging on, a malicious user can slip in unnoticed. Avoid using this setting. [Default: Unselected] |
| • |
Always prompt for password – By selecting this option, Terminal Services' clients cannot use a password saved with the client. Instead, at the beginning of every session, the client is always prompted for a password. Using this setting can prevent a malicious user from taking over a client and using the embedded user account and password to login. [Default: Selected] | |
| • |
Sessions sheet
| • |
Override user settings for session limits – By not checking this option, Terminal Services clients are able to set their own session limits. For both availability and security reasons, most administrators should leave this option selected to retain control. [Default: Selected] |
| • |
End a disconnected session – A session can become disconnected under three major conditions: a user chooses the disconnect option to keep all current applications and data available, a user closes the Terminal Services client, or the Terminal Services client abnormally ends. In any case, this setting determines how long the user session will stay active. Generally, this setting should be as short in duration as possible to limit the possibility that a malicious user could manipulate the user data active within the disconnected session. In addition, the short duration limits the performance overhead on the server. Three hours is a recommended limit. [Default: Never] |
| • |
Active session limit – This setting limits the amount of time a user can actively use the Terminal Server. Used in conjunction with the When session limit is reached or connection is broken and the End a disconnected session settings, after this time period has elapsed, a new session connection and login is required. Setting this limit to 1 day ensures that every user must follow the login process daily. [Default: Never] |
| • |
Idle session limit – An idle session is one in which the connection is active; however, the user has not given the Terminal Server input for the stated duration of time. This setting instructs Terminal Services to disconnect or end the session after the stated time limit. Similar to the disconnected session limit, the idle session limit should be a short amount of time. An idle session can occur when a legitimate user has walked away from his/her computer, so it is also important to use a short time limit. The recommended setting is 15 minutes or fewer. [Default: Never] |
| • |
When session limit is reached or connection is broken – The first choice associated with this setting is to override user settings. By checking this option, the server administrator has control over the actions that are executed. For both availability and security purposes, it is recommended that the Override user settings option is checked. [Default: Unchecked]. The two other associated settings—Disconnect from session and End session—determine the actions whenever the active or idle session limits are reached. As long as the disconnected session limit is set, the recommended option is Disconnect from session. When the active and idle session limits are reached, the client's session then goes into the disconnect state. Upon reaching the disconnect state, the clock starts ticking on the disconnected session limit. After the disconnected session limit has been reached, the session is terminated and the client must start a new session. [Default: Disconnect from session] | |
| • |
Environment sheet
| • |
Initial program – When the Override settings from user profile and Client Connection Manager wizard setting is selected, the system administrator can ensure that a specific application is started upon the start of every Terminal Services session. In addition, if user rights are restricted to the Query Information permission, the client session is limited only to that application. For example, if Microsoft Word is the chosen application, every Terminal Services user will have Microsoft Word start automatically upon connection. After the Word application is closed, the Terminal Server session ends. For security purposes, limiting users to one application would be ideal; however, the realities of the environment can prevent the implementation of this "locked-down" approach. [Default: Unchecked] |
| • |
Disable wallpaper – This option disables the display of Desktop wallpaper during the client session. With Active Desktop disabled (and its ability to display embedded HTML and scripts), choosing this option depends more on the user's desire to cut down on network bandwidth. If each session does not need to send large bitmaps of wallpaper, the network communication is improved. [Default: Selected] | |
| • |
Remote Control sheet – This sheet offers administrators three major choices in controlling the ability to remotely control sessions. The remote control feature lets privileged users control another user's session. The intended use of this feature is to let system administrators remotely troubleshoot problems with a user's session. However, the unintended consequence is that privileged users are able to perform actions on the Terminal Server (and other servers within the environment) by using the hijacked user's credentials. Any situation that allows one user to masquerade by using another's credentials should be avoided. The recommended option is Do not allow remote control. If, however, the need for the system administrators to remotely access Terminal Services session outweighs the security risk, the Use remote control with the following settings should be used in conjunction with the View the session setting. This setting mandates that the user give the system administrator permission before a remote control session can even connect. [Default: Do not allow remote control] |
| • |
Client Settings sheet – For security and administration purposes, administrators should uncheck the Use connection settings from the user settings option. By not selecting the option, you ensure that the Terminal Server administrator retains the ability to affect the client settings on a global level. In addition, for the most secure environment, system administrators should uncheck all options within the Connection frame and check all options under the Disable the following heading. When you disallow these options, malicious users have fewer opportunities to exploit these client/server connections. However, in most environments, the client settings will be highly desirable functions to print to local printers, share clipboard items, and a number of other features. The point here is that the server administrator should control these options at a global level. In case vulnerability is discovered, the administrator can disable functions as necessary. |
| • |
Permissions sheet – This sheet is used to grant users access to the Terminal Services application. For Application Sharing mode, the System account, Administrators group, and a users group are the appropriate access levels. In Remote Administration mode, only the System account and Administrators group should be granted access. In both cases, membership to the Administrators group should be tightly controlled. In addition, access should be controlled at a granular level for each of these two major types of users. The following list summarizes the rights that are displayed by clicking the Advanced button:
| • |
Query Information – Allows a user to access information about a session (e.g., client IP address, client name, connection state, client display resolution and colors, etc.). Allow is recommended for both user and administrators. |
| • |
Set Information – Allows a user to set the session information. Deny is recommended for users, and Allow is recommended for administrators. |
| • |
Reset – Allows one user to abruptly close another user's session, which can result in a loss of data. Deny is recommended for users, and Allow is recommended for administrators. |
| • |
Remote Control – This permission is necessary to use the Remote Control feature discussed previously under the Remote Control sheet bullet. Deny is recommended for both users and administrators. |
| • |
Logon – Allows a client to establish a Terminal Services session and is the minimum permission necessary for any user to establish a session. Allow is necessary for both users and administrators. |
| • |
Logoff – Similarly to the reset function, this permission allows one user to affect another session. However, this permission lets one user logoff another. Deny is recommended for users, and Allow is recommended for administrators. |
| • |
Message – Allows a user to send a message to another logged-in Terminal Services user. Deny is recommended for users, and Allow is recommended for administrators. |
| • |
Connect – Allows a user to connect to a disconnected session. This right is necessary to allow the option of users connecting to their disconnected session. Allow is recommended for both users and administrators. |
| • |
Disconnect – Similarly to Reset and Logoff, the Disconnect permission allows one user to affect another's session. The permission lets a user disconnect another's session. Deny is recommended for users, and Allow is recommended for administrators. |
| • |
Virtual Channels – Allows a user to access the virtual channel during a Terminal Services session (e.g., map a drive, use local printers, use local COM ports, etc.) This permission will depend on the configuration you chose on the Client Setting sheet because those configuration settings will require this permission. However, the recommended setting is Deny for both users and administrators. | |
Terminal Services Client Security
If you follow the previous recommendations, most security configuration options will be moved from the client to server. Therefore, each client deployed throughout the environment will not need to be configured every time a policy change is mandated. However, one important security aspect still exists for Terminal Services client—updates.
When deploying Terminal Services, you should build a process around deploying updates to the client. This process will ensure that in the event an exposure is found within the client software, administrators can quickly deploy patches that Microsoft provides.
Terminal Services Application Security
By default, a Terminal Server that is deployed in Application Sharing mode offers any application within the environment to the user. In other words, any user with access to the system will be able to execute the applications installed on the server. Group Policy, file permissions, and registry permissions can limit this ability. However, an industrious user can get around Group Policies by executing CMD.EXE or launching an embedded object. File and registry permissions are effective countermeasures; however, the administrative overhead associated with setting permissions on individual files makes it a less-desirable option.
For these reasons, Microsoft offers the Application Security (Appsec) tool to limit access on an application-by-application basis. The tool works by allowing only users access to a list of executables using the path and filename (e.g., C:\WINNT\SYSTEM32\CMD.EXE); all other executables will not run.6 When you use Group Policy to hide applications from the end user and Appsec to limit access to only approved executables, the Terminal Services environment will have an additional layer of security above the operating system and the Terminal Services application.
The Application Security tool is available with the Windows 2000 Server Resource Kit. To learn more about the Appsec tool, refer to the following white paper at http://www.microsoft.com/windows2000/techinfo/reskit/tools/hotfixes/appsec-o.asp.
1 Most malicious computer users gain entry into systems by exploiting software vulnerabilities for which the manufacturer has long since offered patches. After the initial update of the Windows 2000 Server, you should continually check for and install software updates.
2 The intermediate- and high-security templates are designed specifically for Windows 2000 workstations and domain controllers. The basic security policy has a separate policy for member servers. However, you can modify any policy by changing the policy's text files located in \WINNT\SECURITY\TEMPLATES.
3 If Terminal Server client version 4.0 is used in communication, a 40-bit key is used. Only version 5.0 of the client uses the 56-bit key.
4 If Terminal Server client version 4.0 is used in communication, a 40-bit key is used. Only version 5.0 of the client uses the 56-bit key.
5 Due to local laws that apply to Microsoft, the 56-bit key length is the most secure method available for Terminal Services consumers outside of North America.
6 Because applications can start more than one executable or library during execution, the Application Security tool has a feature to track all of the files that an application uses. After these files are identified, the administrator can simply import all files into the list of approved executables.