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
• June 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 Possibilities Also on this topic: MetaFrame Canaveral iQ Server Management in Your Pocket

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:

• SSH Communications (www. ssh.com) provides a package called SSH Secure Shell for Windows Servers.
• Van Dyke Software (www.vandykesoftware.com) has a package called VShell.

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:

1. Open the Terminal Services Configuration console from Administrative tools.
2. Open the Properties window for the RDP-tcp connection object.
3. Select the Permissions tab.
4. 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:

• Raritan Paragon switches, www.raritan.com.
• Avocent DS Series switches, www.avocent.com (reviewed in the August 2001 issue).
• Arula Systems Cerebus switches, www.arula.com.

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:

• Compaq, Remote Insights Lights-Out, www.compaq.com/manage/remotelightsout.html.
• Dell, Remote Assistant Card (DRAC II), www.dell.com/us/en/biz /learnmore/
  learnmore_drac_servers_popup_pedge.htm.
• Hewlett-Packard, TopTools Remote Control Card, http://netserver. hp.com/products/highlights_remote_ card.asp.

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.