Seattle Lab has tied its wagon to Windows NT, and by and large it’s been a comfortable marriage between Windows NT and Seattle Lab products of all sorts. That marriage continues with SLnet, a telnet server that runs exclusively on Windows NT — but it will be up to you to decide whether the linkage between the two is liberating or confining.
If you’re an experienced Windows NT system administrator, you’ll encounter few problems when installing and configuring SLnet. It works as a Windows NT service and integrates closely with Windows NT conventions. Since Microsoft doesn’t include a telnet server with Windows NT Server or Workstation (only a telnet client is provided), there’s a need for SLnet if you want to remotely administer a Windows NT installation via the Internet or RAS.
Seattle Lab has tied its wagon to Windows NT, and by and large it’s been a comfortable marriage between Windows NT and Seattle Lab products of all sorts. That marriage continues with SLnet, a telnet server that runs exclusively on Windows NT — but it will be up to you to decide whether the linkage between the two is liberating or confining.
SLnet’s security features are closely meshed with the Windows NT security mechanisms. On its own, SLnet cannot override any security settings or privilege levels set by normal Windows NT mechanisms. Telnet users must have a valid user ID set by a system administrator (either using the Windows NT User Manager or User Manager for Domains), and the user has the same permissions as if they were seated at the Windows NT box. In addition, SLnet uses the Windows NT/Windows Explorer mechanism for setting privileges on a user-by-user basis for each object on the system.
One potential problem with the SLnet security scheme is that your users must use Seattle Lab’s telnet client, SLclient32, in order to establish a secure logon. This client encrypts passwords and ID, thereby providing a secure connection. SLnet supports actual data encryption using a 40-bit Point-to-Point Tunneling Protocol (PPTP) wrapper; stronger encryption is used only for user authentication. Anyone using the older 16-bit SLclient or other telnet clients — including any telnet tools from other operating systems, including Linux and UNIX — won’t have encrypted passwords or user IDs.
If you’re coming from a UNIX environment and are trying to integrate SLnet into a mixed-OS environment, you will run into a few problems. The heavy reliance on Windows NT security mechanisms means that you’ll need to set up a separate set of permissions if you’re using both UNIX and Windows NT machines for telnet access. It also means that you’ll need to learn Windows NT conventions of all kinds. Telnet access is really not an area where you want to be mixing operating systems.
Still, for Windows NT network administrators, SLnet can be a valuable tool. Using RAS services, you can telnet into any Windows NT server — including those not running as Web servers — and remotely administer the server as well as any running applications using the NT Common Command Shell.
The SLnet service itself requires 2MB of RAM per user logon and a megabyte of hard-disk space. However, each individual SLnet users will require an additional megabyte of system memory. One other item of note: SLnet is verified as being Y2K compliant by Seattle Lab. Dates are 32-bit offsets from an epoch date and not stored as two-digit fields.
If you’re working solely with Windows NT and are in need of a telnet server, then SLnet should be at the top of your list. If you’re working in a mixed-OS environment, then you may want to consider using another telnet server that offers better support for multiple operating systems, both on the client side and the server side.
Pros: Closely tied to Windows NT permissions and authentication schemes
Cons: Security measures fall short when working with non-NT OSes
New: This is the initial review for SLnet
Version Reviewed: 2.5 Build 1803 Reviewed by: Kevin Reichard |
Last Updated: 4/12/01 Date of Original Review: 5/5/99 |