Connection-Specific Settings

This configuration affects all users who connect from network clients to a Windows terminal server over a specific connection (in this case, Microsoft RDP 5.2). The corresponding tool is Terminal Services configuration. Only an administrator on the Terminal Services Machine has access to this tool. It is also possible to copy certain options from the individual configurations for users or clients.

User-Specific Settings

This configuration affects an individual user account and is performed by the administrator through user administration. It is important to keep in mind that the corresponding options were added for local user-specific components of computer administration with Terminal Services installed and user administration on the domain level.

Moreover, these user-specific settings are active only if they were approved during the configuration of the connection-specific settings. If they were not approved, the connection-specific settings overwrite the user-specific settings. Terminal Services configuration is therefore stronger than user administration.

Client-Specific Settings

This configuration applies to an individual client and can be performed on the client hardware or the client software. The client user might even have permission to select setting options. These client-specific settings are active only if they were approved during the configuration of the connection-specific settings. If they were not shared, only the connection-specific settings apply. User administration is therefore stronger than client configuration.

Connecting

When Terminal Services is started, it first initializes two user sessions in idle mode. A monitoring thread is launched and waits for a connection request via a certain TCP/IP port. As soon as a user connects to the terminal server through his or her client, the connection request is immediately accepted and forwarded to the kernel driver of the appropriate protocol (for example, RDP). The kernel driver transmits the request to Terminal Services. Terminal Services initializes a special thread to handle the request.

This new thread handles the negotiation between server and client regarding cache size, compression, encryption, client version number, license details, and virtual channels. If the connection is successful, it is assigned to one of the idle sessions. Then the session space is initialized (Csrss, WinLogon, and kernel driver) and a new idle session is generated. Finally, the user is authenticated by means of an interactive dialog box or automatic forwarding of the identification information on the client. As soon as the user is identified, he or she can start the interactive session.

Disconnecting

The user can terminate the connection between client and terminal server without logging off. The connection can also be terminated when a predefined time limit is reached. The session’s graphical image and user processes are stored on the server just before disconnecting. Therefore, the user can reconnect to the session on the terminal server and resume work. The IDs of disconnected sessions and the corresponding user IDs are stored in memory. They can be reused at any time on reconnection.

From a technical perspective, only the RDP and TCP/IP drivers are removed from memory when a connection is terminated without logging off. The kernel element of the 32-bit subsystem handles interrupting all graphical output to the system driver. This means that the session becomes invisible until the user reconnects or on reaching the predefined time limit for automatic removal of the disconnected session from memory.

The applications that were open when the session was disconnected continue to run without interruption. For instance, an FTP client can continue downloading a document from the Internet without a problem in a separate user session, even though the user is no longer connected interactively.

Reconnecting

When a user requests a new connection to the terminal server after disconnecting, a new session is generated. The logon screen prompts the user for authentication if the user ID was not automatically transmitted. If the system detects a separate session for this user from the logon ID and password, the user is reconnected to that session. The required drivers are loaded and the graphical subsystem is invoked to display the current session contents.

If configured to do so, disconnecting and reconnecting can also be used on the server side for unstable network connections. If a client loses the connection to the server, the server detects the interrupted data flow and saves the session for a preset period. Even if a client is accidentally switched off, no data is lost to the user. When the client is switched on again and the user logs on to the terminal server, the user is reconnected to the previous session.

Logging Off

Of course, a user can log off a terminal server session, that is, terminate the session. The result is the same as logging off the local Windows XP or Windows Server 2003 console. All resources that the session was using are released on the server.

General

The first tab is labeled General. Use this tab to enter an optional comment to describe the connection, the degree of encryption, and the standard authentication method you selected. The transport protocol to transmit data streams over RDP 5.2 is always TCP/IP and cannot be modified. The RDP 5.2 connection type is also a default value that cannot be changed.

For the server, you can choose between four degrees of encryption for data transmission between server and client for RDP 5.2.

• Low All data sent from the client to the server is protected with 56-bit encryption. Data sent from the server to the client is not encrypted.

• Client-compatible All data transferred both from client to server and server to client is protected using the maximum encryption supported by the client. The client thus determines the degree of encryption. However, this could allow unencrypted data to pass through the network, depending on the client configuration.

• High All data sent from the client to the server and vice versa is protected by an encryption using the maximum encryption supported by the server. For a standard terminal server, this is 128 bits. International clients that do not support this encryption cannot connect to the server.

• FIPS-conform All data exchanged between client and server is verified according to Federal Information Processing Standard 140-1.

  Note

  In some countries, the law limits the level of encryption; for example, the level might be limited to 64 bit. Therefore, the specific language versions of Windows Server 2003 Terminal Services do not support higher encryption in these countries. Clients that must request a higher encryption cannot connect to the language-specific terminal servers with lower degrees of encryption.

If you activate the Use standard Windows authentication option, you cannot use any third-party security components for user authentication. In this case, Microsoft GINA-DLL is used exclusively.

In production environments, you use this tab only to adapt the level of encryption to the corresponding requirements. Other options are usually not as important here.

Figure 2-16: General settings of a connection protocol in the Terminal Services Configuration.

Logon Settings

The Logon settings are configured under another tab. On the client, you enter the logon information (including the password, if required) into the fields under the corresponding radio buttons. The data is passed on to the server at logon. Be careful not to confuse this with the single sign-on solution in which the information the user enters at logon is automatically used to establish a session on the client. Even though this option is convenient for logging on to a terminal server session, it does present security problems. Furthermore, not all clients support this option.

Alternatively, you can input a user name, domain, and password for logging on to the terminal server. This enables an automatic logon, too, and is valid for all user sessions requesting a connection over this type of protocol. In many environments, however, there might still be security concerns regarding user access. Nonetheless, this is a very powerful option that allows anonymous users to access a terminal server running noncritical applications, for example, information terminals in a department store.

You can make both logon options more secure by requiring the user to enter the password manually. To activate this option, select Always request password option. This prevents the stored password from being used, no matter where it resides (client side or server side). Regardless of the logon option, users will be required to enter their password each time they log on to the terminal server, thus significantly increasing security.

Figure 2-17: Connection protocol logon settings.

In production environments, always select this option button, unless the user is authenticated in a special secured environment that is safe for password transmission.

Sessions

The configuration of sessions on this tab sets the timeout limits for Terminal Services and determines the reconnection settings. The timeout limits are set using three counters. You have the choice of three predefined settings:

• End a disconnected session This counter sets the maximum time a disconnected user session remains in memory. When the interval specified is completed, the session is ended; that is, the session is physically removed from memory, the user’s applications are terminated, and the user is logged off. Terminal Services configuration allows you to set the value for the protocol in question (only RDP in the default installation) only if you select Override user settings. In this case, the setting you define here overrides the corresponding setting in the terminal server-specific expansions for local users and groups or users and computers in the Active Directory directory service. In this way, the terminal server administrator can set a generally valid standard for the behavior of Terminal Services for separate sessions.

• Active session limit This counter sets the maximum duration of a user session. When the time is up, the session is either disconnected or ended, depending on the settings specified in the following paragraph. To set the active session limit value, you also need to override the user settings.

• Idle session limit With this counter, you set the time that a user can remain inactive. If this time limit is exceeded, the session is either disconnected or ended, depending on the settings described in the following section. This is yet another value that you can set only if you override the user settings.

Setting session limits does involve a certain amount of risk. For instance, if the idle session limit is set to 60 minutes, a session might be disconnected or ended when the user is simply on an extended lunch break. In the worst case scenario, data might be lost. On the other hand, setting a time limit is sometimes the only way to prevent inactive users from wasting server resources.

Figure 2-18: Configuring user session limits.

The following settings relate to system behavior when the session limit is reached or the connection is broken. Selecting Override user settings combined with Maximum Idle Time overwrites the settings in the terminal server-specific settings for local users and groups or users and computers in the Active Directory. Thus, the configuration settings chosen here turns an individual user request into a generally binding system behavior preset by the terminal server administrator.

When the session limit is reached or the connection is broken (for example, by switching off a client), there are two options:

• Disconnect from session The network connection is interrupted but the session remains stored in terminal server memory. This applies to all open applications and the corresponding user data.

• End session The user session is completely removed from memory. Unsaved application data is lost if the user did not save it and no automated backup processes were activated.

On closer examination, one combination of settings seems completely useless at first: A disconnected session is ended after 10 minutes, yet the session also ends when the session limit is reached. Can a disconnected session remain in memory? The answer is yes. A user can explicitly ask the client to disconnect from a session. This disconnection does not result from a session limit or an interrupted network connection. In this case, the 10-minute time limit is valid for the disconnected session until it is ended, if the user does not reconnect to it.

A disconnected session can be reestablished by any client under the RDP protocol. The user account and the corresponding password are essential to establish a new connection. This option is particularly helpful if the terminal server is protected by an uninterruptible power supply, but the clients are not. In this case, a short power failure does not result in the loss of user data or application statuses. The user can then continue working with his or her session from any client.

This setting cannot be changed under the RDP protocol. Other protocols might allow limiting reconnections to the previous client. Therefore, this configuration option does appear in the dialog box. Here, too, selecting Override user settings overwrites the corresponding setting in the terminal server-specific expansions for local users and groups, or for users and computers in the Active Directory.

In production environments, the time limits for user sessions are usually set in this tab and can overwrite previously set, different user settings. In particular, this applies to ending a disconnected session after several minutes or hours and after the idle session limit. Therefore, it is strongly recommended that these values be thought through and communicated to users well in advance. When sessions disappear without sufficient warning, users often reject the technology, unjustifiably. It is not the technology that creates the problem, but the organization or, in some cases, the communication involved.

Environment

The Entering two strings in the tab Environment enables the configuration of an exclusive program that is started automatically upon user logon. An entry at the Program path and file name specifies the program desired. The Start in prompt determines the default directory allocated to the program.

When a user logs on, the program inside a full-screen session window is displayed instead of the normal desktop. When the user ends the program, the terminal server session is terminated, too. This leads to a basic form of environment where only one application is able to run.

This option becomes active only if the Override settings from user profile and Remote Desktop Connection or from Terminal Services client option were activated. This overwrites the corresponding setting in the terminal server-specific settings for local users and groups or users and computers in the Active Directory, including the client side as well. In this instance, too, the Terminal Services configuration takes precedence over the user or client-specific settings.

Note

Problems that arise when starting the program over the network might indicate improper timing. For example, the terminal server might be trying to start a program before a required network drive in a logon script is connected. Figure 2-19: Configuring environment settings.

The options in this tab are usually not modified in production environments. In general, a different technology is used to display individual applications. We will describe this technology in detail later in this book.

Remote Control

The Remote Control tab allows a user session to be “mirrored” on another client. This function is for administrative tasks, for example, help desk tasks. The remote control configuration allows you to use user-specific default settings, as well as to fully deactivate and configure the following settings:

• Use remote control with default user settings means that the user settings of a local user or in the Active Directory are used to determine the following options.

• Do not allow remote control prohibits the takeover of a user session thus configured.

• Under Use remote control with the following settings in the dialog box, the administrator can determine if a user must approve of remote control when the administrator assumes control over a session. Additionally, it is possible to define whether the remote session can be viewed only under remote control, or if the administrator can also interact with the session by assuming control of the keyboard and the mouse.

  
  Figure 2-20: Configuration of remote control, where the user must give his or her permission, and the remote session can only be viewed.

  Note

  Labor-law restrictions in some countries prohibit monitoring users without their knowledge. It is therefore mandatory to obtain the user’s permission. For this reason, remote control behavior in production environments is usually preconfigured under this tab and not under user settings.

Client Settings

Client settings allow an administrator access to several options related to the integration of client resources in the user session. Integrating these options supports the intuitive assumption by the user that he or she can continue to use local resources even though the application on the screen is physically running on a remote server. Furthermore, this reduces the time it takes a user to become familiar with the system. For example, during a Terminal Services session, a user can issue the print command without first having to correctly allocate the appropriate resources.

Figure 2-21: Settings for the integration of client resources.

In principle, the following options can be preconfigured for a connection protocol such as RDP 5.2. The first three options can also be defined through the user settings.

• Connect client drives at logon At logon, this option displays the local client drives as network drives in the corresponding terminal server session. These network drives are labeled \\TSCLIENT\A, \\TSCLIENT \C, or \\TSCLIENT \D. This option is activated by default.

• Connect client printers at logon At logon, this option displays the local client printers as network printers in the corresponding terminal server session. This option is activated by default.

• Default to main client printer This option determines whether a print job is forwarded automatically to the terminal server default printer or to the main client printer. This option is activated by default, which sends the print job automatically to the default client printer.

• Limit maximum color depth With this option you determine whether you want to limit the maximum color depth for a terminal server client using this connection. If this option is active, you can select 8-bit, 15-bit, 16-bit, or 24-bit. The default setting is preconfigured to 16-bit.

Printer connections will take the most time because numerous driver combinations can apply. The other interfaces are a bit easier to integrate, although you can always disable them again as well.

The following options can be disabled regardless of how you initiated the connection to the client drives or printers, that is, either via the options described earlier or via the user settings in the system tool Computer Management.

• Drive mapping If you check this box (that is, you disable it), you will not be able to connect to the local client drives from a Terminal Services session. You can also override the Connect client drives at the logon option described earlier. This option is disabled by default, that is, you will connect to the client drives at logon.

• Windows printer mapping If you check this box (that is, you disable it), you will not be able to automatically connect to the client printers at logon. However, you can still manually initiate a connection to a client printer from a Terminal Services session if the LPT or COM port options are enabled. This option is disabled by default, that is, you will connect to the client printers at logon.

• LPT port mapping If you check this box (that is, you disable it), the list of available printers will not include any client printer connected via the LPT port. This option is disabled by default, that is, you can manually integrate all printers that are connected via the LPT port on the client. When you log on again, printers you mapped manually will be restored only if Windows printer mapping is enabled.

• COM port mapping If you check this box (that is, you disable it), the list of available printers for Terminal Services sessions will not include any client printer connected via the COM port. This option is disabled by default, that is, you can manually integrate all printers that are connected via the COM port on the client. When you log on again, printers you mapped manually will be restored only if Windows printer mapping is enabled.

• Clipboard mapping If you check this box (that is, you disable it), no data exchange between terminal server and terminal server client is possible via the clipboard. This option is disabled by default, that is, the clipboard does allow data exchange.

• Audio mapping If you check this box (that is, you disable it), it is not possible to transmit audio data streams from terminal server to terminal server client. This option is enabled by default, that is, system sounds and other audio signals of the user session will not be transmitted to the client.

  Important

  LPT and COM mapping support only the connection of printers via the respective ports. Other local client devices, such as serial bar code readers, cannot be contacted using RDP 5.2. The network bandwidth required can be heavily influenced by the combination of client and server clipboards and the client printer mapping. For instance, when you copy a large graphic from an application running on the client and place it into an application running on the server, all the data on the clipboard must be transmitted via the network. Printer mapping is another critical issue, because a print job of several megabytes can put quite a load on a narrowband WAN connection for some time. This, of course, affects the operating speed of the clients connected via remote access server (RAS).

The configuration options are very comprehensive. Therefore, it is easy to make mistakes. Please make sure that you determine in advance the options you need for productive operations in the target environment.

Network Adapters

On the next tab, you select one or more network adapters to allocate to the connection protocol. Allocating a certain network adapter to a protocol can make a lot of sense in some environments. This is especially true for complex networks in which clients are connected via LAN and WAN lines.

The tab provides an additional configuration option: the number of possible connections. That number can be unlimited or clearly limited to a certain quantity of simultaneous RDP connections over the network adapter selected. In this way, you can determine the number of network connections and thus the RDP bandwidth used for one network adapter. The remaining bandwidth can then be reserved for other services. See Figure 2-22.

Figure 2-22: Selecting the bound network adapter and the maximum number of connections.

Permissions

When it comes to user access, security plays a major role on a terminal server. For this reason, the Permissions tab provides access to the security settings of individual protocols.

Permissions control what a user or a group may or may not do. Only an administrator can modify the standard access types: Guest access, User Access, and Full Control. They are listed in Table 2.5.

Figure 2-23: Setting permissions.

Access to Terminal Services or starting a Terminal Services session is usually regulated by Remote Desktop Users, a particular user group. New users who are to work on the terminal server are therefore added to this group. You should not modify this permission structure without a good reason to do so.