Microsoft Windows NT Services for UNIX

Despite what many people claim, Windows NT simply can't replace UNIX in every situation. In addition, the cost of migrating from UNIX to NT is prohibitive and, in many cases, NT doesn't provide UNIX administrators with the necessary applications. Regardless of the reason, necessity has made integrating NT and UNIX—rather than replacing one with the other—the rule.

Since Microsoft introduced Windows, the company has fallen short in the number and functionality of Windows command-line tools—NT's interface is primarily graphics based. Although alternative sources (e.g., UNIX) have offered these tools for years, no integrated product exists.

The introduction of Microsoft Windows NT Services for UNIX (SFU) fills this hole. However, the name is misleading. SFU doesn't provide NT services on a UNIX machine. Instead, it provides what many people consider to be UNIX services on an NT machine. Understanding this distinction is vital to understanding what services SFU offers and to whom. SFU simplifies resource access, facilitates password synchronization, and eases administration in mixed NT and UNIX environments.

NFS
NFS, which Sun Microsystems originally developed, is one of the first protocols that lets you mount remote file systems and make them appear as if they were local. This functionality lets you have one set of resources available from several machines. NFS has been a staple of all UNIX dialects for many years and is available for NT, Windows 9x, Windows 3.x, and other OSs.

Server and client components. Like the Common Internet File System (CIFS) that Windows uses, NFS consists of a server and a client component. On UNIX, NFS is usually available as one package, so you need to explicitly configure a UNIX machine as a server or a client. However, vendors of Windows NFS products usually package the products as either clients or servers. Only a few vendors bundle the client and server product into one package.

Rather than create an NFS product from scratch, Microsoft integrated into SFU two existing NFS products from Intergraph: DiskShare, which is the NFS server, and DiskAccess, which is the NFS client. Microsoft provides SFU only for NT, but Intergraph offers its two products for NT and Win9x. Microsoft provides both server and client NFS products in SFU, so you can implement NFS in almost any environment.

Although both client and server versions are available, you don't need to install both versions. Deciding which components to install depends on which machines are providing resources and to whom. For example, if you have several UNIX machines that need to access files on one NT machine, installing the NFS server version on the NT machine makes the most sense. However, if several NT machines need to access files on several UNIX machines, installing NFS clients on the NT machines is more practical. By providing the server and client products, Microsoft lets administrators deploy SFU components as needed. Thus, administrators can configure SFU components on fewer machines, thereby decreasing the software cost and reducing the time necessary to administer SFU systems.

The NFS client is completely transparent to users. To access resources on an NFS server, clients use the same tools they use to access CIFS resources, such as Windows Explorer, Network Neighborhood, and File Manager.

Regardless of whether the SFU system acts as a server or a client, the system must convert the user information between NT and UNIX. UNIX tracks users by their user ID and one group ID (GID). NT user IDs have a different format from UNIX users' user IDs, and NT lets a user exist in multiple groups.

Authentication. NT's and UNIX's authentication methods are different, so SFU's NFS provides two authentication methods: pcnfsd and the Network Information Service (NIS). Pcnfsd lets users enter a username and password to gain access to an individual machine's resources. NIS provides a centralized mechanism for sharing user and password information across multiple machines, similar to the way machines share information within an NT domain. However, NIS provides a much finer level of control.

SFU's NFS server component acts as the intermediary between a UNIX client and NT file services, so the NFS server can access any file system type that both the UNIX and NT systems can access, such as FAT, High-Performance File System (HPFS), CD-ROM File System (CDFS), and NTFS. The NFS server performs translations on NT machines, so clients aren't aware of what file system their system is accessing. In addition, the NFS server performs the conversion between UNIX and NTFS permissions. UNIX usually offers only read, write, and execute permissions to the owner, group, and any other users. NT uses ACLs to handle permissions. The SFU NFS server must convert back and forth between NT and UNIX permissions. The NFS server maps the UNIX permissions to the NT Security Descriptor, based on rules that depend on which direction the NFS server is converting.

Licensing. An important distinction between the client and server versions is their licensing policies. The client version is valid only for the machine on which you install SFU, which means you have unlimited access to UNIX machines. SFU's server component licensing permits an unlimited number of clients access to the NFS server as long as each client has an NT Server Client Access License (CAL) for that server.

In addition, SFU licensing depends on the system you install SFU on. For example, the NT Workstation license limits you to 10 client connections, so the same applies to the NFS server component. However, NT Server limits you to the number of CALs you have. Table 1 outlines Microsoft's licensing policy for SFU components.

Gateway services. SFU 2.0 includes an NFS gateway that you install on a Windows 2000 (Win2K) or NT server. This gateway mounts NFS resources from UNIX machines. The resources appear as standard Windows shares. You can share these resources with other Windows machines, including NT Workstation and Win9x systems, without installing the SFU NFS client component on each machine.

Password Synchronization
A major problem in a mixed environment is the need for different passwords on different systems. In a pure NT environment, you can use the NT domain architecture's features to provide one user account and password, creating a single sign-on (SSO) that is valid throughout your company. In a UNIX environment, you can use NIS to synchronize passwords across multiple UNIX machines. However, in the past, synchronizing passwords between NT and UNIX has been difficult.

In SFU 1.0, Microsoft provides an intermediate step to synchronize NT and UNIX passwords rather than fully integrate NT into the UNIX NIS system. SFU 1.0's password-synchronization method works in only one direction—SFU automatically propagates changes you make on an NT machine to a UNIX machine. You can designate a group of UNIX machines (i.e., a pod) that will receive the synchronized password. Passwords must comply with the password rules you define for the NT machine, ensuring a consistent password policy.

SFU 2.0 includes several command-line tools (e.g., ypcat, yppush) that let you directly manage NIS. This functionality includes the ability for an NT server to be a master NIS server in your NIS domain. In addition, a Win2K machine can serve as both an NIS domain master and a Win2K domain master. This capability is partly a result of SFU's inclusion of an NIS source-file migration wizard, which lets you integrate NIS information into Win2K's Active Directory (AD). After you integrate NIS information into AD, you can manage all users through AD.

However, if your UNIX machines don't support NIS or don't have it configured, SFU 2.0 lets you use the SFU 1.0 method to synchronize passwords. You can synchronize passwords by sending them in clear text or encrypted. Sending clear-text passwords lets you synchronize with most UNIX versions because clear-text passwords require only that you properly configure the .rhosts file on the UNIX machine. Sending encrypted passwords requires you to install the single sign-on daemon (SSOD) on the UNIX machines. The SSOD isn't available for all UNIX versions, so sending encrypted passwords is a limiting factor. As of this writing, the SSOD is available in executable format for only HP-UX, Sun Solaris, and Digital UNIX. However, Microsoft plans to support other UNIX versions, including Linux.

Easier Administration
Although the current versions of various UNIX dialects provide a graphical interface for administrative functions, most UNIX administrators are more comfortable using a command line than using graphical tools. The command line is not only faster for many tasks but lets you perform actions that you can't perform using the graphical tools. Microsoft designed NT primarily for access through the GUI, and NT's inherent inability to remotely administer machines from the command line severely limits administrators.

Telnet server and client. Microsoft's inclusion of a Telnet server in SFU eliminates this limitation. All NT versions include a Telnet client that lets you connect to a remote machine and gives you a command-line window from which you can perform tasks as if you were local. The difference is that SFU's Telnet server lets you connect to an NT machine from any system that has a Telnet client.

SFU's Telnet server includes several configuration options that make it different from its UNIX counterpart. For example, you can use SFU's Telnet server tlntadmn.exe utility to configure the default shell, a specific logon script, the maximum number of connections, and other connection characteristics. SFU also includes graphical and command-line versions of the Telnet client.

MMC administration. Microsoft further simplifies SFU administration by integrating SFU into the Microsoft Management Instrumentation architecture. This integration lets you administer SFU's various components from the Microsoft Management Console (MMC) and the command line.

UNIX Scripting Tools
SFU includes several powerful tools and command-line utilities. Although you get only a handful of the well-known UNIX utilities, the tools that SFU includes make up the bulk of any good UNIX administrator's toolkit. Table 2 outlines the UNIX tools that SFU includes.

One of SFU's most significant tools is the Korn shell command-line interpreter. (UNIX shells are usually more powerful than NT's command prompt.) Microsoft included this tool because the company realizes the advantage of a UNIX shell and goes so far as to call it a command and programming language. I agree that the UNIX shell is more than just a command-line interpreter. The shell's programming constructs, which are available directly from the command line, make it extremely powerful. In addition to complex programming constructs, the Korn shell lets you recall and edit previous commands to a much greater extent than the NT command line does. No wonder the shell scripts handle most of the administrative functions involved with starting a UNIX system, such as setting up environment variables, ensuring directories exist, and starting and stopping system services in the right order. As with many aspects of the system, SFU provides users with the choice of what shell they use. Each shell has unique characteristics and features, but all have the same basic functionality.

SFU lets users run many UNIX scripts on NT systems. Microsoft has licensed more than 30 UNIX scripting commands from Mortice Kern Systems (MKS). These commands let users automate common processes and administrative tasks across NT and UNIX platforms.

Another significant aspect of SFU 2.0 is the inclusion of ActiveState Tool's ActivePerl scripting engine. ActivePerl includes PerlScript, which is an ActiveX scripting engine that lets you use Perl with any ActiveX scripting host, such as Microsoft Internet Information Server (IIS) and Windows Scripting Host (WSH). ActivePerl also contains the Perl Package Manager (PPM), which simplifies the management of Perl modules (i.e., extensions and additions to existing modules).

The Best of Both Worlds
If you're interested only in adding command-line and scripting tools to NT, SFU might be overkill—especially when you consider that SFU provides only about one-tenth the tools that the full MKS toolkit offers for about the same price. However, if you're looking for additional command-line capability combined with NT and UNIX integration, SFU is worth a look.