Telnet Lives on in Seattle Lab’s SLnet 2.5
Telnet is an almost forgotten virtual terminal protocol that runs over the Internet. It has potential uses in the Windows NT environment, including remote system administration and multiuser access to text-based applications. Telnet gives system administrators a new way to deploy older terminal-style applications. The protocol also makes it possible to avoid buying and deploying Windows terminals when the target application can be executed from a command prompt.
SLnet 2.5 is Seattle Lab Inc.’s Telnet server. Installing SLnet on our Windows NT 4.0 Server, with Service Pack 5 installed, was a snap. SLnet runs as a service and requires about 2 MB of memory for each individual connected session. The product footprint on our installation was 1.4 MB. Out of the box we were able to authorize several Windows NT user accounts, customize the server and watch clients connect.
The documentation for SLnet is clear, but it is supplied as a Microsoft Word document. If software companies are going to distribute online documents as a way of saving money, they should provide well-crafted PDF files or a series of linked HTML pages. Moving back-and-forth through the 2-MB Word file prompted us to print it, losing any possible justification for online documentation.
When SLnet is running, it appears as a process entry in the Windows NT Task Manager but not in the system tray or on the taskbar. To configure and manage the Telnet server, a separate tabbed control panel is needed. The SLnet control panel looks complex at first, but only the first five tabs affect the operation of the server, and each tab has a limited number of controls.
When we tested SLnet, it was possible to significantly alter the performance of the server by adjusting the entries on the console tab. When a Telnet client is logged into the server, SLnet watches the video buffer of that console for changes. When the buffer changes SLnet sends new data to the Telnet client. SLnet apparently uses a strategy that has the server polling relatively often at the start, and polling progressively less when no screen activity is detected. In our tests we found the default values for the Telnet console worked well for our small number of simultaneous users.
One of the thorniest issues that will face organizations considering Telnet is security. Fortunately, SLnet does a good job providing the basic tools for implementing Telnet securely. Only users with a valid Windows user account -- created with User Manager or User Manager for domains -- can log onto the Telnet server. You can also tell SLnet to allow or deny access to the Telnet server from a range of IP addresses.
Authorizing users to access SLnet is straightforward, but the package’s default installation has a pair of features that are counterintuitive. When first installed, SLnet provides a default user that effectively allows any Windows NT user who has the ability to log in locally to use the Telnet service. After that, removing the default setup and authorizing individual users is easy, but we would have preferred being able to use User Manager to establish groups of users for Telnet access.
Logs are crucial to the security and operation of any Internet service. Rather than establishing a separate set of logs for the Telnet server, Seattle Labs integrated its logging into the Windows NT Event Log. That’s an unusual choice for Internet services on Windows NT, and we were surprised that we had no ability to limit or change the logging style. It would have been nice to direct the logs to simple text files and customize their output.
Anyone needing access to text-based applications will find SLnet an affordable, easy-to-manage method of enabling multiuser access to Windows NT. The product is light years ahead of the Telnet servers provided in the base Windows NT configuration and Microsoft’s NT Services for Unix package. SLnet is an excellent way to provide that access.
Seattle Lab Inc.
Pricing: $499 per server -- Windows NT 4.0, Intel platform only. A 14-day full-function free trial version is available on the Web site.
+ Easy to deploy
+ Integrated with Windows NT User Manager and Security
+ Minimal resources required for installation
+ Runs as a service, does not disturb user at the server console
- Documentation supplied in an inflexible format
- Unable to use Windows NT User Groups to authorize access
- Inflexible logging options
- Users with local login privileges have immediate access to Telnet by default