Microsoft Windows Server 2003 Terminal Services [Electronic resources] نسخه متنی

Chapter 2 described the options for connecting a terminal server and its clients. Now we will take another look at network connections and clients, but this time with a view to security.

Encryption

A Terminal Services connection’s data streams can be encrypted to minimize the risk of data being intercepted on its way from the server to the client. The default setting includes a 128-bit encryption that experts typically see as sufficiently secure. Furthermore, the data transmitted generally consists of user entries or fragments of the graphical representation of a desktop. Reconstructing a confidential document from this data is therefore no trivial feat, even when transmitted through an unencrypted channel. Only when users enter passwords or other critical character combinations is the potential for danger increased.

Some Terminal Services client versions do not support 128-bit encryption. This might be due to the clients being old or localized clients being subject to the legal stipulations of their target country where only lower encryption levels are allowed. In such cases, it is possible to activate the highest possible encryption level supported by the client.

There are four encryption levels:

Low This level provides 56-bit encryption of data transmitted from client to server, but not vice versa. Data transmitted from server to client is unencrypted.

Client-compatible With this setting, data transmitted between client and server is encrypted at the maximum level supported by the client.

High This level provides 128-bit encryption between client and server in both directions. The encryption algorithm is RC4. The Remote Desktop connection supports this encryption level as a default setting.

FIPS-compliant With this setting, data transmitted between client and server is encrypted in both directions with the help of the Federal Information Processing Standard, also known as Security Requirements for Cryptographic Modules. The standards FIPS 140-1 from 1994 and FIPS 140-2 from 2001 describe the federal requirements of hardware and software encryption methods used by the United States government. The corresponding cryptographic technologies are based on triple-DES for encryption, RSA for exchanging and authenticating keys, and SHA1 for hashing.

In high-security environments, it is recommended that the encryption level be as high as possible. However, this always takes away resources from encrypting and deciphering data on both clients and servers. Alternative encryption methods for the RDP data stream will be discussed later in this chapter.

Time Limits and Automatic Authentication Procedures

The Chapter 2.) This prevents a potential attacker from illegally reconnecting to the saved session using a stolen user ID.

The user session time limits mentioned in the preceding paragraph can be set through Chapter 9.)

A new Windows Server 2003 functionality is the option to reestablish a connection after it is disconnected. The client encrypts and saves the user ID and password in its memory for the duration of the user session. After a short network connection failure, this data enables automatic reconnection to the user session. However, this option might be dangerous if the environment requires a high degree of security. Theoretically, at least, it is possible to imagine a scenario where hackers use harmful programs to steal a user’s logon data from the client and use this information to gain unauthorized access.

Nonetheless, the options that allow the user ID for terminal server logon to be saved in the client software are much more problematic. Although data is saved and encrypted in the user profile, a significantly reduced security level is the price to pay for this convenience. For this reason, it is recommended that Terminal Services configuration or a Group Policy be set in such a way that the user ID always needs to be entered for user logon.

To optimally control user connections to terminal servers, only members of the local Remote Desktop Users and Administrators groups should have permission to log on. All users or global user groups who should have access to the terminal servers can be added to the groups mentioned above through computer administration. This way, each terminal server has a central location where the essential access configuration is handled. The permission settings in the Terminal Services configuration remain completely unchanged.

User Options on the Client Side

If we change perspective and look at the options from a user’s point of view, two questions come to mind: First, how can Terminal Services users adjust the configuration? Second, what security-relevant communication options do these users have regarding other sessions?

Users can change the configuration within the Remote Desktop connection only if they are granted this option through the relevant settings in their account, through Terminal Services configuration, and through Group Policies.

Save my password The password for terminal server access can be encrypted and saved in the user profile if the client platform supports this option. Windows 95/98/ME and Windows NT 4.0 do not encrypt passwords and therefore can present a problem in this terminal server scenario.

Local Resources It is possible to access local drives from the terminal server session and therefore exchange documents and other data between client and server.

Reconnect Reconnect to the terminal server if the connection is interrupted.

As mentioned earlier, these options might cause problems in high-security environments. Only if the user account administrators, terminal server administrators, and Active Directory administrators prevent non-administrator users from changing these settings from the client side can these problems be avoided.

To prevent users from influencing other terminal server sessions, default settings do not give permission for remote control and sending messages. This can be changed on the Permissions tab in Terminal Services Configuration but is not recommended. The additional permissions mentioned in this paragraph should be available only to administrators and colleagues with special tasks (for instance, user support). Otherwise, it can become quite difficult to ensure adherence to corporate security and privacy policies.