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?
- By Roberta Bragg
- July 01, 2000
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.
- From Control Panel | Add/Remove Programs double-click
on “Add/Remove Windows Components.”
- Click the Terminal Services checkbox.
- Click next.
- On the Terminal Services page select “Remote Administration
Mode.”
- 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.
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.