Second-Class Services for First-Class Interoperability

A challenging aspect of integrating Windows NT Server with UNIX is finding NT implementations of all the various TCP/IP client-side utilities and server-side services (daemons) that are available with UNIX. Microsoft delivers an anemic set of client and server services in the base NT Server 4.0 product. For example, you get the following client-side utilities when you install support for TCP/IP:

  • FTP and Trivial FTP (TFTP) programs
  • Telnet for VT52, or VT100/ANSI terminal access
  • Finger for remote user lookups
  • Remote Execute (REXEC) and Remote Shell (RSH) for remote program execution
  • Network-oriented commands such as ping, netstat, route, and ipconfig

The Simple TCP/IP network service offers additional client-side utilities. When you add this service, you get utilities for character generation (chargen), echo, daytime, and quote of the day (quotd).

Server-side Services
By default, no server-side services install with TCP/IP. If you want to let your NT Server system offer TCP/IP services to other systems in the network, you can install the following options from the NT Server 4.0 distribution CD-ROM (via the Network option in the Control Panel):

  • Microsoft TCP/IP printing: Provides the client-side Line Print Remote (LPR) interface to send print files from NT to UNIX-based (or network-based) printers and the server-side Line Print Daemon (LPD) interface to receive print files from UNIX (or other) systems.
  • Internet Information Server (IIS): Adds support for HTTP (Web serving), FTP (file transfer), and Gopher (text search, display, and retrieval).
  • Dynamic Host Configuration Protocol (DHCP): NT Server can provide dynamic IP address assignments to systems supporting bootp or DHCP. Service Pack 2 (SP2) or later is required for bootp support.
  • Domain Name System (DNS): NT Server can perform IP-name-to-IP-address (and vice versa) resolution in your network. An NT DNS server can work in cooperation with UNIX-based DNS servers (as long as you don't implement WINS integration).

Although these services clearly accommodate a degree of interoperability between UNIX and NT, they are hardly everything you need. On the high end of interoperability, you often need support for NFS and Simple Mail Transfer Protocol (SMTP)-based mail. And on the low end of interoperability, you may need server-side services for Telnet, Finger, RSH, TFTP, and UNIX to UNIX Copy (UUCP).

The need for the high-end services is pretty clear: They accommodate file sharing and mail exchange between NT and UNIX. But what about the low-end services? Can these simple services contribute value to a mixed NT-UNIX environment? Let's investigate.

I covered the first service, Telnet, in detail in my February column, "Stupid Telnet Tricks," so I won't spend much time on it here. In brief, you can use Telnet to let non-PC devices run character-mode DOS programs, let an NT administrator troubleshoot an NT Server system from anywhere in the network, and provide a simple user interface for users to manage their files and file space. See my February column and the review of Pragma's Telnet server on page 99 for more information about running a Telnet server under NT.

Remote Shell
You can use the next service--RSH--to accept character-mode commands issued via the RSH utility from a remote UNIX (or other) workstation. For example, if a client issues the command

rsh enckmain dir

the RSH server on enckmain will execute a dir command and return the results to the client, as shown in Screen 1. RSH provides a simple way to run character-mode NT commands and programs from a remote workstation or a remote batch job.

Be warned that you need to con-sider RSH as a potential security risk. The RSH specifications call for the originating system to authenticate the user and for the RSH server to trust that authentication. Most implementations of RSH server software do not revalidate the user or password of the requesting client. RSH, however, provides a way of limiting which systems and which users can use the RSH server (but again, the server does not authenticate those users).

Although Microsoft does not in-clude an RSH server service in NT, this service is on the Microsoft Win-dows NT Server Resource Kit for NT 4.0 CD-ROM. This service is easy to miss because it has no automated install aids--you must manually copy a set of files, perform a simple command-line installation task to add the service, and configure a .rhosts file to set the security environment. The online documentation that comes with the resource kit describes this process.

Although the Finger server is not as powerful as Telnet or RSH, this server makes an interesting contribution to NT. In brief, the Finger service works with a Finger client, a command-line utility that requests information about a user account on a specific computer. The Finger server returns basic user information if the requested user has an account on that machine.

Most of the information comes from the NT user account definition (e.g., Name, Domain, Type, Full name, Comment, and Home directory). However, if the Finger server finds a text file named plan.txt in the user's default directory, the Finger server will read that file and send the con-tents at the end of the request. For example, the command

[email protected]

sends a Finger request to the encklab system. If a Finger server is running on encklab, it will look up that user in the local accounts database and return the results to the client, as shown in Screen 2.

Finger is a handy tool that lets administrators verify the presence of user accounts from UNIX systems. Of course, Finger is also a potential security problem because it lets you probe a system to find which user accounts are defined.

Although most implementations of Finger follow the intent and design of Finger as a user account verification system, I have run into an interesting variation of Finger. Specifically, the Hummingbird implementation (included in Hummingbird's NFS Maestro product) returns system environment information instead of user information. As shown in Screen 3, the returned information includes NT version, screen resolution, memory allocation, and who is currently logged on to the console. This approach lets Finger serve as a useful remote diagnostic tool.

The final two services, TFTP and UUCP, are data transfer functions that you can use as alternatives to FTP. TFTP is a simple, command-line implementation of anonymous FTP. UNIX users often employ TFTP to download the operating code for X Terminals--thus, the ability to run TFTP on an NT Server system lets you use NT instead of a UNIX system to initialize X Terminals.

UUCP is a batch-oriented protocol that can transfer files and mail between two systems. You often use UUCP with a dial-up connection to initiate a link from a remote UNIX system to a central UNIX system and send or receive queued files and mail.

The Tip of the Iceberg
These low-end interoperability services--Telnet, RSH, Finger, TFTP, and UUCP--are only the tip of the TCP/IP services iceberg. If you are interested in deploying any of these services, please see the sidebar, "Sources for RSH, Finger, TFTP, and UUCP," for information about where to get them.

When you deploy these low-end services with high-end services such as NFS and SMTP mail, you can create an NT environment that is very UNIX-friendly. And who knows where that friendship may lead.

TAGS: Windows 8
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.