The Freedom of Telnet

The bases are loaded, it's the top of the seventh inning, and the ball game is tied. You're at one of those nail-biting, edge-of-your-seat type games; the kind that you absolutely, positively must watch until the very end. Unless, of course, your office pages you with a support problem.

My pager goes off at some of the most inconvenient times—when I'm in a crowded movie theater or in the dentist's chair. I don't mind so much that I'm being interrupted; my job is to stop what I'm doing to fix a critical problem for a client. However, when I'm out of the office, I shed as much technology as possible, so I'm usually far away from remote support tools and an Internet connection. So, what do you do when you need powerful remote access but you don't have good bandwidth available? Simply use Telnet.

Telnet 101
Telnet is a TCP/IP-based protocol that started out in the IBM world and became a key part of most UNIX systems. In the days before GUI environments existed, UNIX systems were command-line based, like DOS systems. To submit a command to a UNIX system, you either entered the command at a console (i.e., a screen and keyboard) that was attached directly to the UNIX system or through a console session through the network, which meant you used Telnet to establish the console session across the network.

To understand Telnet in DOS terms, imagine sitting at a DOS-based computer keyboard and typing commands that appear on screen. This setup is equivalent to console access. If someone at another screen and keyboard could access your computer over the network and start a separate DOS session, the session would be equivalent to Telnet access to your system. Telnet lets UNIX administrators remotely manage their systems as if they were sitting at the system and had full console access.

Microsoft Jumps on the Bandwagon
Telnet has been around since the early days of networking, but for years Microsoft didn't include UNIX-based tools with Windows. Microsoft designed Windows systems thinking that users would want to use Microsoft's GUIs to manage Windows systems. Over time, Microsoft recognized that many administrators manage their systems from the command prompt and want the ability to do so remotely. This capability comes with the Telnet server included with Windows 2000 Server and Win2K Professional.

Installing and Configuring Telnet
Telnet server lets you maintain two concurrent connections to any Win2K system. (If you need more than two connections, you must purchase Microsoft Services for UNIX—SFU. For information about SFU, see Jim Mohr, "Microsoft Windows NT Services for UNIX," February 2000.) When you connect to the Telnet server and authenticate yourself, the server presents you with a command prompt for the target system. From this prompt, you can issue commands to a Win2K system as if you were sitting at the system's command prompt.

By default, Microsoft has disabled the Telnet capability in Win2K because having the Telnet service running without an administrator's awareness presents a security problem. Therefore, you must start the service, and you can change the startup parameters for the Telnet service so that the service starts every time the server boots. To start the Telnet service, go to Start, Programs, Administrative Tools, Computer Management. In the resulting Computer Management window, which Figure 1 shows, expand the Services and Applications subtree in the left pane, select Services, and select Telnet in the right pane. To configure the Telnet service to start when the server boots, modify the Startup Type from Manual to Automatic.

To ensure that Telnet is working after you start it, go to a command prompt and type

telnet localhost

If you've properly configured the Telnet service, you'll see either a Telnet command prompt or an authentication prompt.

Halt! Who Goes There?
Telnet is inherently an insecure protocol. By default, Telnet handles authentication over the network in clear text, which means that anyone who happens to be snooping on your network when you log on to the Telnet server can see your username and password. This shortcoming can be quite a problem—particularly if you're logging on as Administrator.

To address this weakness, Microsoft modified the Telnet implementation that the company includes in Win2K. Win2K's Telnet server can handle not only clear-text authentication but also NT LAN Manager (NTLM) authentication. NTLM encrypts usernames and passwords as they cross the network so that they can't be discovered.

However, there's a catch. To use NTLM to authenticate to the Telnet server, you must have a Telnet client that supports NTLM. The only client that supports NTLM authentication is Microsoft's Telnet client. So, if you intend to telnet into your systems only from Win2K's Telnet client, you can secure your Telnet service by restricting it to support only NTLM authentication. If you plan to accept Telnet sessions from clients that don't support NTLM authentication, you'll need to step down your security.

To modify the authentication parameters for the Telnet service, launch the Telnet administration program, tlntadmn.exe, from a command prompt. From the main menu of the administration program, which Figure 2 shows, select the Display / change registry settings option to modify the Telnet service parameters. In the resulting menu, select the NTLM option to modify the authentication parameters. This selection results in a prompt that asks you to provide a value for the NTLM authentication. You can choose 0, 1, or 2. These configuration options aren't intuitive, so here's an explanation of your options: If you know that you never want to use NTLM authentication, choose a value of 0, which tells the Telnet service not to even try NTLM. If you want the Telnet service to try NTLM first but fall back to clear-text authentication if NTLM fails, choose a value of 1. This setting is the best value to use if non-Win2K clients will be connecting to your server. If you want to support only NTLM authentication (hence, only Win2K Telnet clients), choose a value of 2, which tells the Telnet service to never use clear-text authentication.

Securing Your Telnet Service
Before you implement the Telnet service on your system, consider the abundant availability of Telnet clients; almost every modern Windows, UNIX, and Macintosh system that has TCP/IP support probably has a Telnet client. If your system is connected to the Internet, many clients might try to connect to your system. If requiring NTLM authentication to gain access is insufficient security for you, consider additional preventive measures.

First, secure your systems behind a firewall. This setup lets you define rules that specify who can connect to your Telnet service, what time of day they can connect, and from which IP addresses. Second, change the port that your Telnet service uses to communicate. By default, Telnet uses port 23. By moving the Telnet service to another port, you can still remotely administer, but you'll make gaining Telnet access to your system more difficult. To change the Telnet service port, run tlntadm, select the Display / change registry settings option, then choose the Telnet Port option.

Bottom of the Seventh Inning
So how did I manage to get back into my seat at the game before the bottom of the seventh inning? Simple: I used a wireless Personal Digital Assistant (PDA) that has a Telnet client on it. The support problem was a result of a locked-up spooler service. Restarting the service solved my client's problem, and I didn't have to walk more than 100 feet from my seat.

You can perform this type of remote management with any type of connection (Internet or a private dial-up connection), from any system that has a Telnet client. Because Telnet is such a universal protocol, you can find it on almost all systems—even on public Internet terminals in Internet cafes and libraries. Telnet requires little bandwidth, which makes it a great remote-administration tool.

   Previous  [1]  2  Next