Running Windows 2000 Terminal Services is the next best thing to being there--but how do you do it securely?

Securing Terminal Services

Running Windows 2000 Terminal Services is the next best thing to being there--but how do you do it securely?

What’s the stuff of network administrator daydreams? Chocolate éclairs? Lunchtime trysts? How about never having to get up out of that chair? I can’t give you the first two items on the list, but pay attention and I’ll help you find a way to smooth your days (and administrative nights) into same-chair sessions sure to broaden the butt—er—smile of any administrator.

But wait, you say, you’ve got numerous servers to manage and there are just some things at which you have to be present in order to win—er—manage. While Windows 2000 does provide a plentitude of administrative consoles that you can turn on a dime, how can you do things from across the network like configure network connections, work with the local accounts database, and administer server-side programs that don’t lend themselves to remote configuration? Better still, what if you have to do it all from a Windows 98 client? Yech. (Well, sometimes that’s all you have.) What if you’re on the road? What if you don’t want to expose that administrative activity to possible snoopers? How can you encrypt activity between your client and the server?

I’m Feeling Remote

Windows NT 4.0 Terminal Server Edition offered a version of NT developed by Citrix Systems. A single server could become host to multiple sessions by various clients. Each client received its screens from an application running on the server and sent keystrokes and mouse clicks across the network. This approach was similar to but different from the old mainframe, with its dumb terminal setup and ability to save companies upgrade costs. Underpowered machines could be NT look-alikes. Administrators could more easily control the configuration, installation, and upgrade of applications like Microsoft Office. They could even control their clients. NT 4.0 Terminal Server Edition with Citrix MetaFrame loaded could even bring the NT desktop to Unix, Macintosh, and other non-Windows clients.

Win2K offers Terminal Services as an optional service. You load it during installation or by using Add/Remove Programs. There are two modes: Application Server, which is much like the Terminal Server edition of NT 4.0, and Remote Administration, which allows only limited connections by administrators so that they can remotely administer the server.

In Remote Administration mode, only administrators can connect to the terminal server, and a maximum of two connections at a time is allowed. You can further configure the service for a higher level of security. It’s this mode I’ll examine here.

Setting it Up and Securing IT

Installing Terminal Services Remote Administration Mode is a snap. Securing it is common sense (almost). So what’s the drill?

There are three parts to successfully setting up secure Terminal Services: installation, configuring and securing the server, and configuring and securing the client.

Installation

To install Terminal Services, you’ll need your Win2K Server Installation CD-ROM.

  1. From Control Panel | Add/Remove Programs double-click on “Add/Remove Windows Components.”
  2. Click the Terminal Services checkbox.
  3. Click next.
  4. On the Terminal Services page select “Remote Administration Mode.”
  5. Click Next, then click Finish.

Secure the Server

To configure the server, start with the first principle of security: Secure the OS first. Remember to use complex passwords, limit membership in the Administrators group, and use every other trick you know to lock down the OS. For help getting started, see my article, “Securing Windows 2000 in the Enterprise,” in the March issue. Next, consider the options in three Terminal Services applets: Client Creator, Configuration, and Manager.

You use Terminal Services Client Creator to create the client disks. Without these disks you can’t load the client on Windows desktop machines. However, you use the same client for administration that you use for application services. Securing the Client Creator is like securing access to a copy of Win2K itself—it’s just not going to happen. If somebody has a set of client disks, he or she will be able to install the client on a machine (presuming that person can install a normal executable from floppies). Nevertheless, you don’t have to give away the farm. If you wish, use Windows Explorer and traverse to:

%system root%\system32\clients\win32\disks\disk1\acmesetup.exe

and:

%system root%\system32\clients\win16\disks\disk1\acmesetup.exe

Set permissions on acmesetup.exe in both places to restrict its use to the Administrators group—or should you desire, to a particular administrator (namely you). While you’re at it, set permissions on some applications you can secure; tscc.msc, the client configuration applet, and tsadmin.exe, the Terminal Services manager. Both executables are found in:

%system root%\system32

Leave the administrators group and System to full control, but nix the others. For tighter control, you could give yourself full control and nix the Administrators group. I don’t recommend it; I have a strong preference for leaving a group, not a user, as sole control on any file. It’s anti-Windows to me to place a mere user in control, and I’m not a strong believer in the “I’ll be here forever” philosophy of some admins.

After doing the install, you’ll see one connection, for RDP. Remote Desktop Protocol, the protocol used for connections between clients and servers, is an industry standard. Microsoft RDP version 5.0 is installed with Win2K.

This connection can be used by the two allowed administrative connections. You can configure individual parameters for each from their individual user account properties. Also, you can add another connection if you wish to include another network interface, for example. Note that the transport required is TCP.

Secure each connection by doing the following.

Set Encryption Strength
Encryption strength can be low, medium, or high. Low means that only the data traveling from the client to the server is encrypted; server communications to the client aren’t. With this setting your password is protected, as are configuration keystrokes and mouse clicks. Displays of the server screens, which travel across the network to your desktop, aren’t encrypted. Conceivably, these could be captured and would allow an attacker to learn confidential information about the server’s configuration. Whatever you see, someone else can also see. Medium, the default, encrypts the data traveling in both directions. The encryption strength for both low and medium will use a 40-bit key for non-Win2K clients and a 56-bit key for Win2K clients. High-level encryption uses the 128-bit encryption key (if supported and allowed) to encrypt data traveling in both directions. All levels use the RSA RC4 encryption algorithm.

If another authentication package has been installed on the server, you can insist that terminal server connections default to standard Windows authentication by checking the “Use standard Windows authentication” check box.

Configure Logon
By default, no user account is selected. You can limit this connection to your account by checking the “Always use the following logon information” box and entering your user ID and domain (if the server is joined in a domain) information. Leave the password blank and check the “Always prompt for password” box.

Configure Sessions
When you connect to a terminal server, it’s called a connection, and when you successfully log on, it’s called a session. What happens when the connection is broken? By default, a session doesn’t end. Any running programs continue and no data is lost. The authorized user can reconnect, even from another computer.

What should happen if a session is idle? To secure sessions, I always recommend setting an idle time disconnect. This prevents the administrator—who may become distracted with the vagaries of the job—from walking away from a connected session and returning hours later to find the server trashed by a casual intruder. On the Sessions page, make sure “override user settings” is checked and set the “idle session limit” to a maximum of 15 minutes. You don’t want to shut yourself down while you’re reading the help screen, but even the best of us can be interrupted by some emergency that requires leaving the office. If you wish to further lock things down, set “end a disconnected session” to five minutes. If something minor happens, you can still reconnect quickly.

You’ll definitely want to set “When session limit is reached or connection is broken” to disconnect or end the session. After all, if you limit administrative sessions to one or leave the default at two, far better to kick off some masquerading intruder immediately than to give that person opportunities for hacking into the system, at least while you’re connected. It’ll also be a warning to you: If you can’t connect, is someone else pretending to be you?

Configure Network Adapters
You can choose between multiple adapters if present. In this way you can prevent connections from outside your network if the system is multi-homed, or configure it for the same. Be sure to check the radio button “Maximum connections” if you want to limit administrative connections to one instead of the two allowed, or if you’re like me—slightly paranoid—and want to make sure the two-connection limit is enforced.

Configure Server Settings
The second folder in the Terminal Services Configuration console is Server Settings. Open this to make sure the settings for “Delete temporary folders” and “Use temporary folders per session” are set to yes. By default, different temporary folders are used for each session, so users can store temporary information in a unique location. Also, by default these folders are deleted when the session ends. For security, these should remain in force. If temporary folders are the same for both sessions or if folders remain on the server, there’s a slight possibility of compromise if someone comes along and opens them. Better to be safe.

Finally, note the Permissions page setting. Full control is given by default to Administrators and the System. If you want to limit it further, create the group using normal tools and then change the permission setting here. Full control provides the following permissions:

  • Query information about a session.
  • Modify connection parameters. 
  • Reset (or end) a session.
  • Remotely control another user’s session.
  • Log on to a session on the server.
  • Log a user off from a session.
  • Send a message to another user’s session.
  • Connect to another session.
  • Disconnect a session.
  • Use virtual channels, which provides access from a server program to client devices.

Secure the Client
Clients are configured in two places. First, in the Terminal Services Client Configuration you can configure a secure connection. In that same applet, you lock down terminal services. Second, individual administrator settings can be made from the local user’s portion of the Computer Management console if the terminal server is stand-alone, or from the “Active Directory Users and Computers” console if it’s joined in the domain.

Got the connection settings locked down? Move on to the server-side clients’ profiles. Open your user account and make sure the Terminal Services Profile check box, “Allow logon to terminal server,” is checked for your account and for the account of any other administrators who should have access. If other terminal servers used for application servers aren’t present in your environment, no other user accounts should have this checked. On the sessions page you can make individual settings for “end a disconnected session,” “active session limit,” and “idle session limit.” You’ll override these settings by those you set in Terminal Services Configuration, but if there’s more than one administrator, you may wish to individualize settings here and loosen them on the server.

This is also where you can lock down the reconnection choices. Check “from originating client only” if you wish to make sure that a disconnected session can be reconnected only from the client that originated it. Then a wily hacker with your account and password information won’t be able to disconnect you and reconnect using another client. (Otherwise, you’d only be able to fume and fuss, while he continues the processing you started on the server that may have required other passwords and parameters above and beyond your user name and password.)

Check remote control settings. If you’re the only administrator allowed to use terminal services, this shouldn’t be a threat, but it could be otherwise. Disable that possibility here by unchecking “enable remote control.”

Now that you’ve got client connections and user accounts straightened out, don’t forget to check out the Terminal Services Manager. You don’t configure security settings here; rather, this is where you can see information on other users’ connections. When a user is connected, you can determine who the user is, what client that user is working at, the IP address of the client, and the encryption level. If someone’s messing with your server, go here to catch him in the act. Incidentally, to disconnect the intruder and end his connection, right-click the connection and either reset it (no warning given) or disconnect it. In the latter situation, the session doesn’t end. Programs continue to run and no data is lost, but the user must reconnect, first re-entering a password.

Additional Info

Call me Paranoid, But…

Here’s a final tip. If you really want to confuse your enemies and impress your friends, configure IP Security (IPSec). You’ll have a lot more configuration to do, and you may want to look into special industrial-strength network cards with onboard encryption processors to prevent your client processors and that of the server from bogging down. Not necessary, you say? Have more than one lock on the doors to your house? Use a burglar alarm? To double-bolt your admin session, IPSec allows you to encrypt all activity between your client and the server. More on that next month.

comments powered by Disqus
Most   Popular