Connection Security

Remember from Chapter 2 that "connections" in the Terminal Server environment refer to the groups of settings that apply to a specific Session Protocol / Network Protocol / Network Interface combination in the form of a connection listener port. There are multiple options configured at this "connection layer." Many of them directly impact the overall security of the system. Additionally, there are many neat tricks you can do to provide different levels of security to different interfaces.

Connection Properties

When configuring the properties of a connection listener port (Terminal Server Configuration Utility | Right-click on connection | Edit | Advanced Button), it's important to remember that those properties will affect all users that connect to the Terminal server via that connection unless you check the box for each item that allows the server to use the settings in each user's profile.

Let's examine each of the following connection layer security settings:

• Session timeouts

• Working with broken connections

• Client reconnection options

• Auto session logon

• Limiting the number of sessions per connection

• Disabling logons

• Encryption

• Using default Windows authentication

• Initial programs to be executed

• Remote Control

• The RDP TCP port

Session Timeouts

You can configure three different timeout periods for each connection: connection timeout, disconnection timeout, and idle timeout. Each of these choices allows you to specify the timeout in minutes. A checkbox allows the timeout settings of the connection to default to those specified in the user's account settings as opposed to by the connection itself. This allows for different settings on a user-by-user basis. Selecting "no timeout" disables that specific session timer for that connection.

The "End a disconnected session" limit causes the server to reset a disconnected session after the specified time has passed. The current user will lose any work that was in progress. The disconnection timer is a good way clean up any disconnected sessions that users have forgotten about. Many companies set this to approximately 2880 minutes (48 hours). If they have some situations requiring less time, they configure those in the user profile.

The "Active session limit" lets you specify the maximum time that an RDP session can stay connected. After this time passes, the server either disconnects or terminates the session. (The decision to terminate or disconnect the session is determined by "when session limit is reached" option further down on the screen.)

The "Idle session limit" specifies the amount of time that a live connection can stay in an idle state (no activity) before the server automatically disconnects or ends the session. From a security standpoint, the idle timeout works well as an "automatic lock-down." Many companies set their idle timeouts relatively low so that if a user leaves his desk with an active RDP session open, the server will disconnect the session after a few minutes. Then, when the user returns to his desk, he can conveniently reconnect to his disconnected session without losing any work. Like the active session limit, you can specify the action taken when the idle session limit is reached—the session is either ended or disconnected.

Extreme care must be taken when working with connection timeouts. Almost all environments that utilize connection timeouts configure them as a property of the user account (at the "user layer"), instead of configuring them here as a property of a connection. The one exception is the disconnection timeout, which is used to clean up any old sessions.

Working with Broken Connections

The term "Broken Connection" specifies what happens when an RDP client stops responding to the Terminal Server during an RDP session. Broken sessions can result from network failures, power failures, and crashed client devices.

At the connection layer, specify what action the server should take when a connection is broken (Terminal Services Configuration MMC snap-in | Connections | Double-click the connection | Sessions tab | "When session limit is reached or connection is broken" option). You have two options. The server can end the session or it can simply disconnect it. The choice you make here also affects the actions that take place when a session reaches its active or idle limits. From a security standpoint, the broken connection action does not pose much of a security risk because even if you allow disconnected sessions, users must successfully authenticate before they can reconnect to a broken session.

You might be wondering about the "Auto Client Reconnection" that is available with the latest Microsoft client and how it relates to the broken connection detection of a Terminal Server. On newer versions of the RDC client (at least version 5.2, which is newer than the one that ships with Windows XP), auto client reconnect allows RDP clients to automatically reconnect to a Terminal Server if their RDP sessions are interrupted. If you want users to be able to automatically reconnect to broken sessions, ensure that this option is set to "Disconnect from session" (which is the default).

Reconnecting From Any Client

You can also use the "Sessions" tab of the connection properties sheet to specify how users can reconnect to disconnected sessions (if disconnected sessions are permitted in your environment).

Some people view the ability to reconnect from any client as a security problem. In actuality, the security risk is not great since the user must authenticate on the new client before being able to reconnect to a session. Also, the user can only reconnect if the disconnected session was started with the same credentials as the new user. One user cannot reconnect to another user's disconnected session.

Potential security problems can arise, however, when multiple users log on with the same user account to access Terminal Servers. This is common in many environments for kiosks, common applications, or task-based workers. If a user authenticates with credentials that were used to start multiple sessions (which have since been disconnected) on one server, the user will be presented with an option to choose the disconnected session to connect to. It's possible that the user might pick a session that does not belong to him and be able to view privileged information or data. (Of course, one could argue that if there's any chance that a session could contain sensitive information, users shouldn't be logging on with shared credentials anyway.)

Auto Session Logon

The Logon Setting section of a connection's properties let you use one set of credentials to automatically log on any user that attempts to start an RDP session via that connection. Using this setting can pose a tremendous security risk, as any person could access to the system without being officially set up or authorized. It is relatively simple for a user or attacker to download and install the RDC client software and then to "discover" the Terminal Server, connect to it, and be automatically logged on.

Limiting the Number of Sessions per Connection

The maximum number of concurrent sessions can be limited per connection on the connection's main property page. In general, this setting is not used since this limit applies to all users—including administrators.

Disabling Logons

Disabling logons is useful if a custom connection is needed from time to time, but you do not want to have the connection open all the time or have to recreate the connection each time it is needed. Disabling the logons of a connection does not cause existing sessions to be broken—it merely prevents additional users from being able to log on.

Encryption

The required level of encryption can be set at the connection level, affecting all sessions on the connection. The details of the various levels of encryption will be discussed in the network security portion of this chapter.

Use Standard Windows Authentication

On the bottom of the main property page of the connection's properties is a fairly benign checkbox labeled "Use standard Windows authentication." Checking this box forces user authentication (over that connection) to occur through the standard Windows authentication DLL, msgina.dll.

If you install the Novell NDS Client on your Terminal Server, the Novell client authentication and logon DLL (nwgina.dll) will replace the Microsoft DLL. The "Press CTRL+ALT+DEL" logon screen is a Novell screen instead of the standard Microsoft screen after you install Novell's NDS Client. Checking the "Use standard Windows Authentication" checkbox will force RDP sessions to be logged on via the Microsoft client when that connection is used.

This is useful if you have two groups of users that connect to the same Terminal Server. You can create two separate connections—one for each group of users. Use one connection (call it "RDP1-TCP") for users that use the Netware Client can have the "Use standard Windows Authentication" box unchecked, allowing them to log on with the Novell authentication. Use the other connection ("RDP2-TCP") for users connecting to authenticate via the Microsoft logon DLL.

The end user experience is the same, regardless of whether the "Use standard Windows Authentication" box is checked or unchecked. The RDP client only passes the basic authentication parameters to the Terminal Server, and the checkbox merely specifies which DLL handles those parameters after they are received by the server.

Specifying an Initial Program to be Executed

A Terminal Server connection can be configured to set the initial program for every user that connects via the connection. This topic was fully covered back in Chapter 5, and the security aspects of configuring initial applications were covered previously in this chapter.

Setting the initial program at the connection layer functions in the exact same way as setting it for one specific user, except that the connection layer setting applies to all users on that connection without exception. As soon as the user logs on, the specified program is run. As soon as the user closes that program, he is automatically logged off. At no time will the user ever see a desktop unless the desktop is specified as the initial program to run.

Specifying an initial program to be executed is a good way to lock down your server if all users will need to use only one program. Users still need to authenticate before the program is run (unless the AutoLogon is configured). When the user closes that initial program, the connection is terminated.

Since this option is set at the connection layer, the initial program will affect everyone who connects, including administrators. (Administrators would be able to still remotely connect to the console session.) Setting the initial program at the connection level is most useful for Terminal Servers that serve as public terminals or kiosk devices.

As an interesting side note, even if a user connects to an initial application configured via his client or an RDP file, via a connection listener port that has the initial program specified, the initial program specified at the listener will run, not the one specified in the RDP file or at the client.

Remote Control

Basic remote control parameters can be set at the connection layer, such as whether remote controlling or view of another session is enabled and what type of notification or input the target sessions have. Many organizations choose to set different remote control parameters for different connections. Refer to the "Administrative Environment" segment of this chapter for more information on remote control.

TCP Port Used for RDP Sessions

By default, Terminal Servers accept inbound RDP sessions via TCP port 3389. For added security, some administrators like to change this port number. This port can be changed in the registry at the following path:

Key: HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\ RDPConnectionName\

Value: PortNumber

Type: REG_DWORD

Data: Port number in hex (default 3389 = d3d Hex)

The "RDPConnectionName" in the above registry path is the name of the ICA connection you would like to change, for example "RDP-TCP." Because the RDP port configuration is a connection layer setting, you can configure different ports for different connections. After changing this port number, restart the server.

Remember that if you change the RDP port on the server, you must also change the port that the RDP client looks for.

In the real world, very few people choose to change the RDP port, mainly because there are plenty of other security measures that can provide excellent security and they don't want to deal with configuring all of their clients to use a nonstandard port. "Security through obscurity" is not generally viewed as a strong security measure.

Connection Permissions

You can specify which users and groups are able to connect over a particular connection listener port. However, you can also specify (from a permissions standpoint) just exactly what you want them to be able to do.

Like all security in Windows 2003, you can build extremely advanced custom sets of permissions, giving each user or group exactly the options they need. User and group permissions can be specified at the connection layer, with the permissions affecting the configured users for each connection.

Advanced Permission	Allows the User or Group to...
Query Information	Obtain information about the current session
Set Information	Configure connection parameters
Remote Control	Remote Control other user's sessions
Logon	Connect via selected connection
Logoff	Log off other users
Message	Send popup messages to other sessions
Connect	Reconnect to disconnected sessions
Disconnect	Disconnect other peoples' sessions
Virtual Channels	Use virtual channel in a session

Figure 12.5: Advanced connection permission properties

To make your life easier, Microsoft has "preconfigured" three different security levels: Guest, User, or Full Control. The permissions granted for each level are shown below.

	Guest	User	Full Control
Query Information		•	•
Set Information			•
Remote Control			•
Logon	•	•	•
Logoff			•
Message			•
Connect		•	•
Disconnect			•
Virtual Channels			•

Figure 12.6: Preconfigured connection permission levels

You can customize any of these levels or create your own by highlighting the user account or group and then clicking the "Advanced" button. For example, you might give one group "shadowing" permissions without having to give them full access rights. This setting would be accomplished by clicking the "advanced" button, selecting the group, clicking the "view/edit" button, and selecting the rights needed for that group. However, the preconfigured levels work well for most situations and save you from having to manually select each option.

It's important to understand that these permissions only affect the one connection at which they are applied. It is possible for one user to have "Full Control" rights on one connection and "No access" rights to another.

For each line-item property, there are two boxes: allow and deny. If you select the deny box, the option is explicitly denied for that user or group, and this "deny" takes precedence over any other allow permissions configured in any other group, similar to "no access" NTFS permission.

If you're using a third party software such as Citrix MetaFrame that uses its own connection listener port, some people recommended that you disable the RDP connection listener port. While doing this would minimize your security risk, it actually increases your overall risk. If there's a problem with your MetaFrame connection that prevents a session from connecting, you would have no recourse unless you are located physically near the server. In the real world, most people choose to leave the default RDP connection listener port active when using MetaFrame, but configure the permissions so that only administrators are able to connect. That way you protect the connection while giving your own group a backdoor connection in case of trouble. (Although if your administrator account is called "administrator" and its password is "password," keeping RDP active is a valid risk. If such is the case in your environment, put this book down and pick up a copy of Security for Dummies.)

Strategies for Using Multiple Server Connections

Terminal Server connection listener ports can be used in creative ways to provide different types of security. All security configuration settings that are applied at the connection layer apply to all users that connect via that port. However, there is nothing to say that you can't have more than one connection listener port for each protocol.

If you put multiple network cards in a Terminal Server, you can create multiple RDP-TCP connections, one for each card. To do this, change the LAN adapter for the connection's properties (Terminal Services Configuration MMC| Connections | Double-click the connection | Network Adapter). Change the network adapter from "All network adapters configured with this protocol" to just the network adapter that you want to use. Then create a new connection for the other network adapter (Terminal Services Configuration MMC | Right-click on "Connections" folder | Create New Connection). Because each network card would have a different IP address, each connection will be accessible via a unique IP address and therefore a unique DNS name.

This allows you to have a completely different set of properties for the same server, each accessible via its own unique address. This arrangement is useful if you want to provide different groups of users access to the same server, but want different connection-layer settings to apply to each group. One group could access server1.yourcompany.com and the other group could access server2.yourcompany.com. In reality, each would be using a different connection of the same server.

Advantages of Configuring Multiple Connections

• If you need different connection layer settings on one server, this is the only way to do it.

Disadvantages of Configuring Multiple Connections

• You need one physical network card for each unique connection.

• All users connecting to the server via its NetBIOS name will connect via the same network adapter.

Connection Configuration in the Registry

All connection listener port configuration information is stored in the registry of each Terminal Server in the following location:

HKLM\System\CurrentControlSet\Control\TerminalServer \WinStations\<RDPConnectionName>

Because this configuration information is stored in the registry, you can allow or deny specific users access to the appropriate registry keys. If a user has the ability to write to this registry key, then he will have the ability to change the parameters of Terminal Servers connections, regardless of the permissions that are configured elsewhere.