In-Depth
Remote Operator
Windows 2000 offers a number of ways to manage your servers and user applications when you aren’t, or can’t be, physically present. Come along for a guided tour, including a peek into the .NET future.
- By Bill Boswell
- 06/01/2002
Server rooms have a certain eeriness. Green, amber and red lights flash
from long lines of racks and cabinets. Casual conversation is blanketed
by the whirr of cooling fans. The glow from monitors gives the air a blue
sizzle that matches the meat-locker chill from the air conditioning units.
Visitors look respectful and a little nervous—even your mom (except she
wants to know why you could never keep your own room this tidy).
As striking in appearance as they might be, server rooms make poor work
environments. They’re noisy and cold. Work areas are cramped. You can’t
bring in food or coffee. And everyone thinks they own your time if you
work in there. It’s much more convenient to manage your server room from
your cubicle. Or better yet, from your home. Even better still, from a
cabana near a tropical beach. This requires a set of remote administration
tools and a very flexible manager.
Remote admin tools fall into two general categories. In-band tools connect
to your servers across the same network used by clients. Out-of-band tools
allow you to connect using a separate network or alternate data communications
paths. Of the two, in-band remote management tools generally provide a
richer environment, so let’s look at those first.
In-Band Remote Management Tools
You use in-band management all day without really thinking about
it. For example, I run Active Directory tools on my desktop that I use
to connect to domain controllers when I want to create or modify objects.
These are specialized features though. Windows 2000 comes with several
general-purpose, in-band tools designed to provide a more or less comprehensive
management interface. Each tool has its strengths and weaknesses. Let’s
look at them in ascending order of flexibility.
Telnet
As convenient as GUI-based tools can be, sometimes you just want
to do a quick chore at a command prompt without all the fuss of a full
Explorer session. For example, let’s say you get a phone call in the carpool
van on the way to work. A user’s forgotten his password right before the
start of a “critical business meeting that could net the company billions.”
You roll your eyes, then connect to the office via a wireless PDA, open
a console session on a domain controller, and kick off a script or use
the net user command to reset the user’s password. Total time? Maybe 15
seconds, and you didn’t even have to set down your espresso.
The most venerable command-line console is telnet. Win2K has a telnet
service already loaded. It’s simple enough to start. Just enter net start
tlntsvr at a command prompt. If you want the service to start automatically
at boot time, use the Service.vbs script in the Windows 2000 Resource
Kit with the syntax:
cscript service /n tlntsvr /m automatic
You can configure the telnet service by typing tlntadmn at a command
prompt. The operation of this utility differs in Windows XP compared with
Win2K. In Win2K, you get the following listing:
C:\>tlntadmn
Microsoft ® Win2K ™ (Build 2195)
Telnet Server Admin (Build 5.00.99201.1)
Select one of the following options:
0) Quit this application
1) List the current users
2) Terminate a user session ...
3) Display / change registry settings ...
4) Start the service
5) Stop the service Type an option number
Windows XP (and .NET) gives you a more informational listing:
C:>tlntadmn
The following are the settings on localhost
Alt Key Mapped to 'CTRL+A' : YES
Idle session timeout : 1 hours
Max connections : 2
Telnet port : 23
Max failed login attempts : 3
End tasks on disconnect : NO
Mode of Operation : Console
Authentication Mechanism : NTLM, Password
Default Domain : COMPANY
State : Running
You can use tlntadmn on XP to manage other machines as long as they’re
running XP or Windows .NET. The Win2K version only manages the local machine.
By default, Win2K telnet accepts only NTLM (NT LanMan) authentication
rather than the clear text authentication normally used by telnet. NTLM
appears to be superior, but as Joel Scambray and Stuart McClure point
out in their seminal security book, Hacking Windows 2000 Exposed, NTLM
authentication is vulnerable to man-in-the-middle exploits, especially
when exposed by a service such as telnet where it’s simple to grind through
passwords. Account lockout doesn’t work for failed telnet logons. One
solution would be to rewrite Windows telnet to use Kerberos, but Microsoft
hasn’t done this yet.
You can use tlntadmn to change the authentication method from NTLM to
both NTLM and standard password. If you do this, be sure to protect the
password exchange and the data stream by using a Secure Shell (SSH) product.
SSH creates an end-to-end encryption path that protects both the clear-text
authentication and the subsequent data transfers. This is similar to the
way basic Web authentication is protected by SSL/TLS. SSH also uses public
key technology to sign communications digitally for authentication and
nonrepudiation. Microsoft doesn’t provide an SSH implementation in Win2K.
A couple of third-party packages are available:
You can also enable IP security (IPSec) to protect authentication and
data streams between servers, but SSH can be targeted specifically to
telnet, ftp and other command-line options.
Once you’ve configured telnet to use standard authentication, you can
use alternate clients. For instance, you can use the Hyperterm utility
in virtually any version of Windows as a telnet client. Configure the
session to use TCP/IP (Winsock) and point the session at the DNS name
or IP address of the telnet server. Figure 1 shows an example.
 |
| Figure 1. Windows’ Hyperterm is a common telnet
client. |
Text Editing Over Telnet
As convenient as telnet might be for making a connection to a server,
as a management tool it’s only as good as the command-line utilities available
at the server. Microsoft enhanced the Win2K command line quite a bit compared
to Windows NT, but a few touches are still lacking. The most glaring deficiency
is the lack of a good console editor, the emphasis here being on “good.”
Edit and edlin will work in a telnet console, but neither of them is exactly
a systems administrator’s best friend. (Note: If you use Edit in a telnet
console, use Ctrl-A as an alternative to the Alt key to access the menus.
You can change this shortcut key using tlntadmn. Windows .NET drops support
for edlin.)
A better console editor is available. It’s called vim, which stands for
VI iMproved. (You can learn more about this freeware at www.vim.org.)
If you haven’t worked with vi, it may take you a while to get used to
vim, but once you play around with the keystrokes, they feel natural.
If you want to get serious about using vim, I highly recommend Vi
Improved—VIM, a book by Steve Oualline (New Riders). (Note:
The Resource Kit has a version of vi but it requires running the posix
subsystem, which isn’t recommended because it wasn’t included in the C2
security evaluation. Windows .NET doesn’t include a posix subsystem.)
Remote Console
If you don’t want to run a telnet service on your servers, the Resource
Kit has a little utility called Remote Console that gives you approximately
the same working environment. Remote Console is simple to install. It
comes with rsetup, an installation utility that installs the service across
the network if you have administrator privileges on the target server.
Once the Remote Console service is running, you can connect to it using
rclient with the syntax:
rclient \\target_server/logon:domain\user _name [password]
If you don’t specify a user name, your current logon credentials are
used. If you don’t put the password on the command line, you’re prompted
for it.
You can add an /e switch to the rclient connection to encrypt traffic
between the client and server. This appears to make it more secure than
standard telnet, but Remote Console is a Server Message Block (SMB) utility
and using it across the Internet would require opening SMB ports on your
firewall. You should avoid doing this. If you have a VPN solution in place,
you can use Remote Control through the VPN.
Remote Control
If you want the convenience of a GUI to run your management tools,
the most obvious strategy is to use a remote control solution of some
sort to create a virtual console. There are as many remote control products
as there are brands of frozen pizza. Deciding which to use is more a matter
of taste than technology.
If you want maximum return on your software investment, you can’t do
much better than “works great” and “costs nothing,” and that’s what you
get with a remote control product called VNC (which stands for Virtual
Network Computing). VNC was developed by AT&T and can be downloaded for
free from www.uk.research.att.com/ vnc/download.html. There are binaries
for Windows, Linux and many flavors of Unix, along with a Java client.
VNC installs as a service and listens on port 5900 by default (The port
number can be changed). Passwords and data are passed in the clear, so
if you use VNC, you should install SSH or use IPSec. Commercial remote
control packages such as Symantec’s pcAnywhere, Previo’s ReachOut (part
of eSupport Essentials), NetOP Remote Control, Netopia’s Timbuktu Pro,
and Famatech’s Radmin all have secure password features and can encrypt
data streams.
Keep in mind that the reliability of your remote control utility is crucial
to your ability to manage your servers. It can be frustrating to lose
contact with a distant server because the remote control executable faults.
It’s even worse if the fault brings down the server, as some remote control
products are notorious for doing.
Admin-Mode Terminal Services
If the additional complexity and uncertainty of a remote control
product is not to your liking, you can enjoy the benefits of a full Explorer
interface without a third-party service by using the terminal services
built into Win2K. Terminal Services uses the Remote Desktop Protocol (RDP)
to connect you to a terminal session running on the server. Applications
run within that session rather than running at your desktop. Each session
has an allotment of memory and uses separate user profiles and configuration
files. You can use Task Manager to see the processes assigned to each
user. Select the Processes tab then, from the View menu, choose the Select
Columns option. Figure 2 shows an example.
 |
| Figure 2. You can use Task Manager to see processes
for a user using Remote Desktop Protocol. |
Terminal Services comes in two flavors, called modes. Remote Administration
mode supports two simultaneous session connections and requires no additional
licensing. Application Server mode permits many simultaneous connections
but you must have licenses for each connection and a license server to
manage them after a 90-day grace period.
Terminal Services isn’t installed by default in Win2K. Use Add/Remove
Programs in the Control Panel to install the service. Be sure to select
Administration mode to avoid paying licensing fees for remote administration.
Installing the services requires a restart. (Admin mode terminal services
are installed by default in Windows .NET.)
In its default configuration, Admin-only terminal services permit connections
only by members of the Administrators local group on the server (or by
groups nested in the Administrators group). This can create a problem
because Active Directory delegation makes it possible to dole out admin
privileges to folks who aren’t “administrators” per se. If you want limited
administrators to have terminal services access, modify the permissions
assigned to the Remote Desktop Protocol (RDP) connection on the server
as follows:
- Open the Terminal Services Configuration console from Administrative
tools.
- Open the Properties window for the RDP-tcp connection object.
- Select the Permissions tab.
- Add the user or group to the permissions list and assign User permissions,
which should be sufficient to perform limited administrator functions.
Configuring Admin Mode Terminal Services
If you want to monitor and manage users and processes running on a terminal
server, use the Terminal Services Administration utility. This tool has
the look and feel of an MMC console, but is actually an executable called
Tsadmin.
Figure 3 shows a sample Tsadmin screen that displays a common problem
when using Admin mode terminal services. If administrators simply disconnect
from their sessions or walk away without logging off their session, they
can use up the two connection licenses and nobody else can manage the
server using terminal services. This forces you to connect to the server
using another method and disconnect one of the users with command-line
tools. For example, you could make a telnet connection to the server,
use the query user command to list the Session IDs for the two connections,
then use reset session # to close the session. This can cause data loss
if the user is connected to open files.
 |
| Figure 3. Failure to log off of a Terminal Services
session could result in another user being unintentionally kicked
off, like avguser in this example. (Click image to view larger version.) |
To avoid idle connections, you can set a short idle timeout and configure
sessions to shut down within a few minutes after a disconnect. Both of
these settings are exposed in the Properties window | Session tab of the
RDP connection object (see Figure 4.) Be sure to allow a little time following
a disconnect to permit a reconnect. You don’t want somebody to lose hours
of work just because the connection breaks.
 |
| Figure 4. Setting a short idle timeout, configured
in the RDP-Tcp Properties menu, can avoid data loss. |
Special Terminal Service Client Features
When you install Terminal Services on a Win2K server, the Setup
routine installs the client files in the folder %systemroot%\System32\Clients\Ts
client. The files are divvied between two folders. This makes it simpler
to construct setup floppies for your home users.
You can also install the Terminal Services client using a Windows Installer
package (.msi). Download the most current .msi package from www.microsoft.com/windows2000/downloads/recommended/TSAC.
(The .msi package is also available on the Service Pack 2 CD as one of
three “advanced” terminal server clients located in the Valueadd folder.)
Use the .msi package to deploy the client to your Win2K desktops using
group policies or distribute them using your standard deployment options.
The user must have Administrator or Power User privileges to install the
package if it isn’t deployed as part of a group policy. XP desktops already
have a Terminal Services client, called the Remote Desktop client, located
at Start | Programs | Accessories | Communications.
User-side group policies (that is, group policies under the User Configuration
node in the group policy editor) can’t be used to deploy software to terminal
server users. If you want to have a terminal server client available for
use from within a terminal server session, use Computer-side group policies
to deploy the client to the terminal server itself.
The Web-based terminal server client, also available for download or
on the SP2 CD, simplifies client deployment further by placing an ActiveX
control called Msrdp.ocx and script called Connect.asp on a server running
IIS 5.0 or higher. The Web server doesn’t need to be a terminal server.
The installer creates a virtual directory on the Web server called TsWeb
and populates it with the client files. When a client points an Internet
Explorer browser at the Web server with the syntax http:///tsWeb,
the Connect.asp script downloads the ActiveX control and installs it on
the client unless you’ve configured IE to reject such actions. The default
Web page contains a server selection and logon form for the user to select
a terminal server.
The Web client doesn’t provide HTTP access to a terminal server. Instead,
it brokers an RDP connection to the selected server, passes over the user
credentials, then provides a frame for the terminal session. This means
that if you load the Web client on an IIS server in your DMZ, you must
open RDP port 3389 through your firewall if the terminal server is on
the private network.
The third advanced client is my favorite for remote administration. This
client comes packaged as Tsmmc setup.exe. It installs a snap-in, Mstsmmc.dll,
and a console file, Tsmmc.msc. The Tsmmc console permits you to make RDP
sessions to multiple terminal servers. Once you’ve authenticated on the
various servers, you can switch between the sessions as easily as switching
between Friends and Seinfeld on a boring night of TV.
Non-Windows Terminal Server Clients
If you run operating systems other than Windows, you don’t necessarily
need to abandon RDP. There are a couple of great Java clients on the market
with binaries for Linux, Solaris, Macintosh, and other operating systems.
The first of these clients, HOBLink JWT (for Java Windows Terminal),
has a price tag of $140. A trial version can be downloaded from www.hobsoft.com.
The second client, rdesktop, is free under the GNU General Public License
(GPL). The rdesktop source code can be downloaded from www.rdesktop.org.
Compile the source by running make on your platform to get the executable.
Linux binaries can be downloaded from www.sourceforge.com.
If you run Citrix MetaFrame on your terminal servers (See “MetaFrame:
Enterprise-Class Remote Administration”), you can take advantage of
the wide variety of non-Windows ICA clients provided by Citrix.
RDP and Firewalls
RDP uses TCP port 3389. Terminal servers are a highly desirable plum for
intruders, so you may not want to open this port on your firewall. Use
port translation to change the external port. If you want to discourage
connection attempts by internal users, change the RDP port used by the
terminal servers. This involves a quick Registry hack. Use Registry Editor
to locate this entry:
Key:HKLM | System | CurrentControlSet | Control
| Terminal Server | WinStations Value: Port Number
Data: d3d (hex for 3389, REG_DWORD)
Change the PortNumber entry to another port well above the standard port
ranges. Restart the server then use netstat -a to verify that the server
is listening at the new port and not listening at port 3389. Then modify
your clients to use the new port number as follows:
- Win2K clients: Export the Connection Manager entry to a text
file (.cns extension) using File | Export. Change the Server Port entry
from 3389 to the new port number then import the file back into Connection
Manager.
- XP clients: Launch the Mstsc client executable then specify
the server name, followed by a colon then the port number. For example,
S1.company.com:6500.
- TsWeb client: Change the Visual Basic code in the ASP page
that makes the connection. Go to %system root%\Web\TsWeb. Locate the
file called Connect.asp and edit it with Notepad or vim. Look for a
series of entries starting with MsTsc.AdvancedSettings2. Add the following
line right after these entries:
MsTsc.AdvancedSettings2.RDPPort =
Test to make sure that you can connect with the new setting.
RDP in XP and Windows .NET
Windows XP and the upcoming Windows .NET servers use a new and improved
version of RDP, version 5.1. This version has a long list of enhancements,
including:
- 24-bit color depth, compared to 256 colors in RDP 5.0.
- Audio and video redirection.
- Client drive mapping (users at PC-based clients see their local drives
within the terminal server session).
- True printer redirection, compared to the kludge in Win2K.
- LPT and COM port redirection that doesn’t require the NET USE command.
- Seamless Clipboard sharing be- tween the client desktop and the terminal
server session, including the ability to cut and paste entire files
and folders.
The RDP 5.1 client can also interact directly with the server console.
Direct console access also works with XP desktops if you enable the Remote
Desktop option in System properties. Select the Remote tab and check the
Allow Users to Connect Remotely box to this Computer (see Figure 5). This
feature is different from Remote Assistance, which requires the user to
send an “invitation” that contains a digital certificate identifying a
specific person permitted to make a remote desktop connection.
 |
| Figure 5. Remote Desktop in Windows XP can put
you in direct contact with the server console. |
To connect to the console of an XP desktop or .NET server using the Mstsc
client in XP, use the /console switch with the syntax: mstsc
/console. The MMC client in Windows .NET has a connection property that
permits interacting directly with the server console.
Terminal Service Security
In a terminal server environment, everyone plays in the same pool. Bad
hygiene can make life very uncomfortable. You need to be extremely diligent
in protecting operating system files and other sensitive areas of the
server from negligence or deliberate acts of vandalism. Admin-mode terminal
services assume that the individuals making connections know what they’re
doing. If you give Terminal Services access to limited administrators,
be especially watchful. It’s a tremendous mistake to permit such users
to have anything approaching full administrator privileges.
Consider blocking Internet access at the server unless you’ve locked
down every possible way for downloading and installing files. Running
Outlook on a terminal server is also something you should approach with
caution because of mail-borne viruses that could affect dozens, even hundreds,
of users. The National Security Agency (NSA) has a white paper with explicit
guidelines for securing a Win2K terminal server. Download it from nsa1.www.conxion.com/
win2k/guides/w2k-19.pdf.
Another terminal server risk involves exposing what is essentially a
console logon to the network where bad guys can guess passwords all day
long. Don’t expose your terminal servers to the Internet unless you’re
confident that every account can withstand constant pummeling by uncounted
thousands of assailants. Never install application-mode terminal services
on a domain controller.
Terminal session data streams are visible to prying eyes. Both RDP and
ICA support 128-bit encryption but clients can request something less
strong. A little GUI-based utility in the Resource Kit called Tsver helps
by letting you select the terminal service clients to which the server
will respond. Clients in Tsver are listed by build number. In recent releases,
the client build number matches the OS build number. Figure 6 shows an
example. You can enter a build number if one isn’t shown on the list.
 |
| Figure 6. Using the Tsver utility can enhance
the security of a Terminal Services session. (Click image to view
larger version.) |
Out-of-Band Management
All the remote administration solutions discussed so far assume
that you can connect to a server across the Internet from home via a VPN.
But what happens if a construction worker with a backhoe turns the 600-pair
bundle containing your company’s T1 line into a special effect for the
next Matrix? In this situation, you need an alternate way to connect to
your server room.
The simplest method for bypassing the main network entry point is to
have a dial-up server, suitably configured for security, sitting inside
your server room. From there you can use a terminal server client or telnet
to connect to your servers. But what if a critical piece of network plumbing
internal to your server room goes to the rings of Saturn? This requires
an Out-Of-Band (OOB) method for making connection to your servers.
KVM Switches
One approach to OOB server management is to use KVM (Keyboard-Video-Mouse)
switches. I’m sure you probably already use analog KVM switches in your
server room, but the newer crop of digital switches go beyond simply aggregating
input and output devices. They’re central management units capable of
handling hundreds of servers with simultaneous access by dozens of administrators.
These switches incorporate high-end security measures as well, such as
SSL connections and RADIUS authentication, along with the ability to restrict
access for each switch port to specific administrators.
Here are three vendors that sell high-end digital KVM switches:
OOB Management Adapters
KVM switches give you the same access to a server that you would get if
you were standing at the console, but what happens if a server crashes
or hangs or otherwise becomes unavailable? If you were physically present
in the server room, you could do a diagnostic assessment of the equipment
then initiate a restart. Harvesting this kind of low-level hardware information
from a remote location requires a special adapter or management interface
at the server. These adapters feature separate network access and secure
remote dial-in; most have Web interfaces for simplicity of operation.
A server with an on-board management adapter can yell for help in situations
such as an overheated CPU, a hard drive or predictive failure, or a failure
of a redundant power supply. The cards can dial preset numbers and deliver
SNMP traps to network management utilities such as HP OpenView, Intel
LanDesk, and Microsoft Operations Manager (MOM).
Every server platform has different equipment, so remote management adapters
are coupled to particular server models. The generic management adapter
Intel once sold has been discontinued. However, several server vendors
still offer remote management capabilities, including:
OOB Management Features in Windows .NET
Microsoft has heard the clamor for lights-out server management, and Windows
.NET servers (due for release late in 2002) will include OOB features.
These features are grouped under an umbrella called Emergency Management
Services, or EMS. Using EMS, you can connect to the serial port of a server
and perform a limited set of functions, such as listing the running processes,
killing a process and restarting a hung server. The menu of functions
is displayed via a Special Administration Console, or SAC.
If a server crashes with a bugcheck (a.k.a. Blue Screen of Death), EMS
displays the contents of the blue screen via the serial port. If you’ve
configured the server not to restart following a bugcheck, then you can
jot down the information then use another EMS console, !SAC, to restart
the server. You can even use EMS in combination with the Remote Installation
Service (RIS) to install the operating system remotely on a machine with
no input or output devices.
For remote management via EMS, you can install a serial port concentrator
in your server room and attach a port of the concentrator to each Windows
.NET server. The more advanced concentrators have their own secure dial-up
connections so you don’t leave an unguarded back door. Look for products
like the TS Series from Cyclades (www.cyclades.com)
and the MuxMaster from Able Communications (www.able.com).
Where’s Waldo? On His Way…
Ideally, it should be possible to manage an entire server room
from a single remote console anywhere in the world. The functionality
provided by such a console would mimic exactly the operations you’d perform
if you were physically in the server room, with the possible exception
of picking up a screwdriver to install a new adapter. Such a console would
give views of every server with real-time inputs and provide control of
all hardware, OS services, and applications without regard for bandwidth,
latency, or the failure of a single network interface anywhere along the
connection path.
In his 1942 short novel, Waldo,
the late Robert Heinlein wrote about special gloves with highly sensitive
sensors that gave users with average dexterity and strength the ability
to control mighty machines or perform delicate microscopic operations.
The current crop of remote admin tools has not quite reached the stage
of being true Waldos—they lack a certain finesse—but they’re on the right
track. When we can relax in some secluded cabana on a beach in Guam with
full confidence that we can handle any emergency back home, then we’ll
truly have remote administration.