The Freedom of Telnet

Remotely administer from the bleachers

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.

Perform 5 Common Administrative Functions
Although Microsoft's OSs offer many GUI-based administrative tools, the company improved the command-line capabilities of Windows in Win2K. For example, you can perform the following common administrative functions from a command prompt.

Reset a user's password. Users forget passwords all the time. Until biometric authentication devices become commonplace, resetting passwords will be part of administrators' jobs. To reset a user's password from the command line, connect through a Telnet session to the appropriate server, and type at the command prompt

net user   

inputting the user's new username and password. If you've connected to a member server, this command changes the password in the local accounts database of that server. If you've connected to an Active Directory (AD) domain controller (DC), this command changes the user's password in the AD domain. To change the password for a domain user account, you must specify the /DOMAIN parameter and include the name of your domain.

Kill a print job. Printers that aren't printing are usually plagued by one of two problems (assuming they have enough paper): either a print job is stuck or the spooler service has locked on the system. You can release a stuck print job by using its print job number. To list the print jobs in a queue, run the following command at a command prompt from any machine within the domain:

net print \

This command lists the print jobs in a specific queue. After you've found the queue that includes the print job that you want to release, issue the following command at a command prompt to release the job:

net print \ /RELEASE

This command will release the print job referenced by the job number you've provided. If the /RELEASE command doesn't purge the stuck print job, try using the /DELETE command. You might need to wait a minute or so for jobs to be released or deleted from the print queue.

Restart a hung service. Win2K services crash for various reasons. Although the best course of action is to troubleshoot the service to learn why it crashed, sometimes your first priority is to get the service running again. To stop and start Win2K Server services, issue the Net Start command through a telnet session with the server on which the service is hung. If you issue the Net Start command without any parameters, the system presents a list of all the services that are already started on the system, and you can use the list to determine whether your crucial services are still online. You can restart a failed service by issuing the Net Start command with the service name:

net start 

However, you must use the short service name (e.g., W3SVC for the Web Publishing Service or SPOOLER for the Print Spooler). You can find the short names for all the services on your system by looking at the properties for each service and noting the service name. For future reference, I recommend that you make a list of the short names of the most crucial services in your organization and keep the list in a PDA.

To stop a service, you can use the Net Stop command. The syntax for this command is similar to the syntax for the Net Start command:

net stop 

To stop a service and start it again, use the short service name to issue a Net Stop command, then issue a Net Start command.

Change ACLs on a file or directory. During the course of administering a network, you must grant and deny users access to files. Usually, you perform this task by modifying the file permissions in the GUI. But you can also do it using the cacls.exe command-line utility. Through Telnet, connect to the server that you want to change permissions for and use the following syntax:

cacls  <<>> /T /E /G:permissions

The parameters at the end of this command control how the command applies permissions to the system's files. For example, the /T command instructs Cacls to apply the command to the files in the current directory and any subdirectories. The /E command instructs Cacls to edit the existing ACLs on the file or directory, rather than overwrite them. The /G command tells Cacls which permission to grant: R for Read, W for Write, C for Change, and F for Full Control. Cacls offers many more parameters; to get more information about these parameters, use the Cacls /? command.

Restart a server. As a last resort, you sometimes have to restart a server. However, restarting a server remotely isn't the best practice. If a problem arises during the reboot process, the server might not come up without hands-on intervention. If it's absolutely necessary, you can use the Microsoft Windows 2000 Resource Kit shutdown.exe tool to remotely reboot a server through a Telnet connection.

Home Stretch
Telnet is a great tool for remotely managing Win2K systems. Although you can't do everything from a command prompt, you can use Win2K commands to perform many administrative tasks. If you need easy remote administration for your systems—even during the middle of a baseball game—the Telnet service is definitely worth a look.