X
Tech

Enable Telnet services on Windows 2000 Server

Adding an archaic utility like Telnet to a modern operating system like Windows 2000 may seem strange, but installing Telnet allows administrators to manage environments that include both Unix and Windows servers. It also benefits remote management of Windows 2000 servers by using a low-bandwidth command line interface.
Written by Brien M. Posey, Contributor
Adding an archaic utility like Telnet to a modern operating system like Windows 2000 may seem strange, but installing Telnet allows administrators to manage environments that include both Unix and Windows servers. It also benefits remote management of Windows 2000 servers by using a low-bandwidth command line interface.

The Telnet services are part of a $149 package called Services For Unix, which also includes the Unix Korn shell, NFS, and some other utilities.

The Windows 2000 version of Telnet has been specifically designed to interact with Windows 2000 services, including NT LAN Manager (NTLM), the service that provides authentication into a Windows 2000 network. Because Telnet services supports NTLM logins, any login restrictions you've placed on your server still apply to Windows clients through the Telnet session—both the Windows 2000 server and Windows client are NTLM aware. This means that login restrictions, such as not allowing clear text passwords, still apply, even though the client isn't logging in via the normal method. If the same user attempts to log in through a Unix workstation, the login is allowed but the NTLM restrictions aren't applied because the Unix client isn't NTLM-aware.

Interacting with Windows 2000 through a Telnet session takes some getting used to. In a normal Windows environment, users can use network utilities to freely connect to any resource they have rights to. If a user is interacting with Server A and needs to access a resource on Server B, he doesn't have to enter a separate login for Server B. This isn't the case with Telnet services. In an NTLM environment, when users attach to a Windows 2000 server through Telnet, they are free to access resources they have permissions to, as long as those resources exist locally on the server they've attached to. If a user needs to access resources through Telnet on a different server, he can map a drive to the new server, but will have to re-enter login credentials when doing so.

Brien M. Posey is an MCSE and freelance writer. You may see Telnet services as a back door security threat into your system. Fortunately, it's possible to control Telnet Service's behavior and keep an eye on who's connecting through a Telnet session.

You configure and monitor Telnet via text menus through a program in the \Services For Unix root\Telnet directory called TLNTADMN.EXE. With this program, you can see who's attached to the server through Telnet and kill a connection if necessary. You can also use this utility to set parameters that control the Telnet Service's behavior.

The most important of these parameters is the option to use NTLM for authentication. The utility places the values you enter here directly into the Windows registry. There are three options:

  • 0 indicates that NTLM shouldn't be used.
  • 1 indicates that NTLM should be used if it's available; otherwise, the client will be presented with a standard login prompt.
  • 2 indicates that NTLM is the only accepted means of authentication.

Entering a value of 0 means that your clients can submit clear text passwords. A value of 2 is much more secure, but makes Telnet services lock out Unix users, since only Windows supports NTLM. In a mixed Unix/Windows environment, a value of 1 is the best choice.

There are a few other security-related settings you can control through this utility. You can allow users from a trusted domain to log in through a Telnet session. You can set the maximum number of failed login attempts the server should accept, and the number of Telnet clients that can connect to the server. The maximum number of connections is 63, but you won't be able to have that many Telnet sessions unless you also have at least 63 Windows 2000 Client Access Licenses.

Other settings on this menu are designed to make your users' lives easier. You can set a default domain name so users don't have to login by entering DOMAINusername. You can set a keyboard mapping that simulates the Alt key being pressed, and set the default shell for your clients. And you can enable login script processing through Telnet sessions (this option is disabled by default).

Once you have the Telnet server set up the way you like, you'll want to access it with a Telnet client. You've probably seen the HyperTerminal utility that's been included in every version of Windows since Windows 95. HyperTerminal is a basic terminal program that's capable of communicating through a Telnet session. While HyperTerminal gets the job done, Windows 2000 includes a second Telnet program, which you can access by simply entering TELNET at the command prompt. This Telnet terminal works in pure text mode and supports ANSI emulation, which allows it to display ANSI characters and correct display colors. It's also faster than HyperTerminal.

You can use all the normal Telnet commands with the Windows 2000 Telnet client, but there are a few specific commands that let you interact with the client itself:

  • Close: Closes the current session.

  • Display: Shows the Telnet client's current configuration.

  • Open [address]: Establishes a session with the machine with the specified name or IP address.

  • Quit: Closes the Telnet client.

  • Set: Configures the behavior of the Telnet client. You can view the various configuration options by entering SET ?.

  • Status: Displays the current connection status.

  • Unset: The Unset command clears any settings that you might have defined through the Set command and returns the Telnet client's configuration to its default settings.

Implementing Telnet services is inexpensive, easy to do, and doesn't place much of a load on your server. It's useful for allowing communications between UNIX and Windows environments, and also provides a low overhead method of managing a server across a slow dial-up link.

Adding an archaic utility like Telnet to a modern operating system like Windows 2000 may seem strange, but installing Telnet allows administrators to manage environments that include both Unix and Windows servers. It also benefits remote management of Windows 2000 servers by using a low-bandwidth command line interface.

The Telnet services are part of a $149 package called Services For Unix, which also includes the Unix Korn shell, NFS, and some other utilities.

The Windows 2000 version of Telnet has been specifically designed to interact with Windows 2000 services, including NT LAN Manager (NTLM), the service that provides authentication into a Windows 2000 network. Because Telnet services supports NTLM logins, any login restrictions you've placed on your server still apply to Windows clients through the Telnet session—both the Windows 2000 server and Windows client are NTLM aware. This means that login restrictions, such as not allowing clear text passwords, still apply, even though the client isn't logging in via the normal method. If the same user attempts to log in through a Unix workstation, the login is allowed but the NTLM restrictions aren't applied because the Unix client isn't NTLM-aware.

Interacting with Windows 2000 through a Telnet session takes some getting used to. In a normal Windows environment, users can use network utilities to freely connect to any resource they have rights to. If a user is interacting with Server A and needs to access a resource on Server B, he doesn't have to enter a separate login for Server B. This isn't the case with Telnet services. In an NTLM environment, when users attach to a Windows 2000 server through Telnet, they are free to access resources they have permissions to, as long as those resources exist locally on the server they've attached to. If a user needs to access resources through Telnet on a different server, he can map a drive to the new server, but will have to re-enter login credentials when doing so.

Telnet security
You may see Telnet services as a back door security threat into your system. Fortunately, it's possible to control Telnet Service's behavior and keep an eye on who's connecting through a Telnet session.

You configure and monitor Telnet via text menus through a program in the \Services For Unix root\Telnet directory called TLNTADMN.EXE. With this program, you can see who's attached to the server through Telnet and kill a connection if necessary. You can also use this utility to set parameters that control the Telnet Service's behavior.

The most important of these parameters is the option to use NTLM for authentication. The utility places the values you enter here directly into the Windows registry. There are three options:

  • 0 indicates that NTLM shouldn't be used.
  • 1 indicates that NTLM should be used if it's available; otherwise, the client will be presented with a standard login prompt.
  • 2 indicates that NTLM is the only accepted means of authentication.

Entering a value of 0 means that your clients can submit clear text passwords. A value of 2 is much more secure, but makes Telnet services lock out Unix users, since only Windows supports NTLM. In a mixed Unix/Windows environment, a value of 1 is the best choice.

There are a few other security-related settings you can control through this utility. You can allow users from a trusted domain to log in through a Telnet session. You can set the maximum number of failed login attempts the server should accept, and the number of Telnet clients that can connect to the server. The maximum number of connections is 63, but you won't be able to have that many Telnet sessions unless you also have at least 63 Windows 2000 Client Access Licenses.

Other settings on this menu are designed to make your users' lives easier. You can set a default domain name so users don't have to login by entering DOMAINusername. You can set a keyboard mapping that simulates the Alt key being pressed, and set the default shell for your clients. And you can enable login script processing through Telnet sessions (this option is disabled by default).

The Telnet client
Once you have the Telnet server set up the way you like, you'll want to access it with a Telnet client. You've probably seen the HyperTerminal utility that's been included in every version of Windows since Windows 95. HyperTerminal is a basic terminal program that's capable of communicating through a Telnet session. While HyperTerminal gets the job done, Windows 2000 includes a second Telnet program, which you can access by simply entering TELNET at the command prompt. This Telnet terminal works in pure text mode and supports ANSI emulation, which allows it to display ANSI characters and correct display colors. It's also faster than HyperTerminal.

You can use all the normal Telnet commands with the Windows 2000 Telnet client, but there are a few specific commands that let you interact with the client itself:

Close — Closes the current session.

Display — Shows the Telnet client's current configuration.

Open [address] — Establishes a session with the machine with the specified name or IP address.

Quit — Closes the Telnet client.

Set — Configures the behavior of the Telnet client. You can view the various configuration options by entering SET ?.

Status — Displays the current connection status.

Unset — The Unset command clears any settings that you might have defined through the Set command and returns the Telnet client's configuration to its default settings.

Implementing Telnet services is inexpensive, easy to do, and doesn't place much of a load on your server. It's useful for allowing communications between UNIX and Windows environments, and also provides a low overhead method of managing a server across a slow dial-up link.

Brien M. Posey is an MCSE and freelance writer. He has been Director of Information Systems for a national chain of health care facilities and a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.

Editorial standards