Terminal Services, Part 3

In Part 1 and Part 2 of this article, I described some of the options for securing Windows 2000 Server Terminal Services. Here, in Part 3, I'll continue the tour by looking at some of the properties for Terminal Services connection objects.

Remote Control
Terminal Services security is controlled primarily through properties on Terminal Services connection objects using the Microsoft Management Console (MMC) Terminal Services Configuration snap-in. To begin, select the connection object, right-click, and select Properties. The Remote Control tab sets the properties that let administrators and support personnel take remote control of a session. Although this functionality is very useful in an application server scenario, you don’t want someone viewing your Terminal Services session while you are administering a server—much less taking control of it.

The Remote Control tab of a Terminal Services connection object offers three options. First, you can select Use remote control with default user settings, as Figure 1 shows. If you select this option and try to take control of a user’s session, Terminal Services will refer to the remote control settings specified in that user's account. If you are using Active Directory (AD), you can also find these settings in the MMC Active Directory Users and Computers snap-in. If your Terminal Services server isn’t a member of an AD domain, open Computer Management and maneuver to Local Users and Groups. Find the desired user, and open the associated Administrator Properties window. Select the Remote control tab to view the options, as Figure 2 shows.

If you specify that Remote control is enabled, you can stipulate that Terminal Services ask the user for permission before letting an administrator or support staff personnel take control of the session. To control whether Remote control for this user is limited to view-only mode, specify View the user's session or Interact with the session. If you select Interact with the session, you can take control of the user's keyboard and screen to function as that user. If you're securing your server for remote administration only, you will want to disable remote control for all administrative user accounts.

The second choice on the Remote Control tab of a Terminal Services connection object presents an even better way to prevent someone else from using remote control. The Do not allow remote control option, as Figure 1 shows, prevents remote control for any sessions opened that are using this connection object, regardless of the user's remote control settings. I recommend using this setting when you implement Terminal Services only for remote administration.

The third choice on the Remote Control tab is Use remote control with the following settings, as Figure 1 shows. If you select this choice, you get the same options found on the Remote Control tab of user accounts, and the settings you specify here override those made at the user level.

Permissions
The final tab on the properties page for Terminal Services connection objects that relates to security is Permissions. Like all objects in Win2K, connection objects have an ACL that controls who can open a session to the server through Terminal Services and who can perform administrative functions on those sessions and the connection itself. There are three levels of access you can grant to a connection object from the Permissions tab: Full Control, User Access, and Guest Access. However, these access levels are actually different combinations of lower-level permissions, which you can view if you click Advanced and then click View/Edit. There are 10 different permissions, as Figure 3 shows.

Query Information lets you use Terminal Services Manager to view the status of the current sessions associated with that connection. Logon is the most basic permission—you must have Logon access to open a new session and log on to Terminal Services. Message access lets you send messages to other users connected to the server.

Terminal Services gives you the ability to temporarily disconnect from your session, walk over to another computer, and reconnect to the session from that workstation. To disconnect and reconnect to your own sessions, you need only Connect access, but if you also have Disconnect access, you can disconnect someone from his or her session and connect to it yourself from your own workstation. To hijack a session like that, you need Connect and Disconnect access, but being able to reconnect to another user's session is a feature you should disable for remote administration connections. You don't want someone hijacking your session, but disabling reconnection is a somewhat confusing procedure, although at first it seems simple. If you explore user accounts in Active Directory Users and Computers, you'll notice the Sessions tab, which provides time limits for how long Terminal Services keeps applications open in active, idle, and disconnected sessions. There is another option, however—Allow reconnection: From originating client only—that seems more appropriate. You might think that selecting this option prevents someone at another computer from hijacking your session. However, if you carefully read Win2K's Help text, you learn this feature applies only to users connecting through a third-party Citrix ICA client—not the typical Terminal Services client that comes with Win2K. So, to remove this risk, you need to lock down the permissions on the connection object so that the Everyone group is explicitly denied Connect and Reconnect.

The Reset permission lets you end any session associated with the connection object. Resetting a user’s session ends all of its active applications abruptly and can result in lost data. Logoff permission is similar to Reset—the difference is that Logoff causes Terminal Services to log off the user and present the logon dialog box again, whereas Reset closes the entire session.

To configure a connection object’s properties in Terminal Services Configuration, you need the Set Information permission. To successfully take over a user’s session, you must have the Remote Control permission on the associated connection object. Don’t confuse the Remote Control permission with the Remote Control tab on connection objects and user objects. The Remote Control permission specifies who can take control of sessions. The Remote Control tabs on connection objects and user objects limits which sessions and which users another person can take control of remotely.

The Virtual Channels permission controls whether users may access devices on their client workstation from programs they are running in a Terminal Services session on the server. For instance, to use the local COM port on your workstation from an application inside a Terminal Services session, you need the Virtual Channels permission. The default ACL on a connection object in Terminal Services when you install Terminal Services for remote administration simply grants Administrators and the SYSTEM account Full Control. The only change I would recommend is adding an access control entry (ACE) for Everyone that explicitly denies Remote Control, Connect, and Disconnect. This precaution will reduce the possibility of someone using vulnerabilities in RDP to hijack your session. Next time, I'll complete this discussion of securing Terminal Services for remote administration.