In-Depth

Mission Interoperate: Windows 2000 and Unix

Administering two platforms is tough. Microsoft Services for Unix 2.0 provides a practical set of tools for making sure Windows and Unix users get along—and that your job gets easier.

• By Greg Neilson
• 05/01/2001

The rapid growth of Linux translates to a major resurgence in Unix usage. This means more of us are in the position of having to integrate Unix systems with Windows NT/2000 systems. Microsoft Services for Unix 2.0 (which I’ll abbreviate as SFU here) is a collection of tools we can use to connect these two platforms in a myriad of ways. Like a smorgasbord, there’s plenty here to pick and choose from to get what you need. SFU originally surfaced from Microsoft in 1999. Version 2.0, released last year, costs a modest $149, which I consider an absolute bargain. With SFU 2.0 you can share files between Unix and Windows environments, access telnet on your Windows servers, run Perl and Korn shell scripts on Windows, and perform two-way password synchronization between Windows domain and Unix hosts.

How can you make use of this product? Here are a few scenarios:

• You could install the NFS Gateway feature on a Windows server that connects to NFS shares from Unix hosts and then reshare them again for Windows clients. Thus, the clients wouldn’t need to have NFS client software installed.
• You could install the NFS server feature on your Windows file servers and then be able to share files with Unix hosts.
• You could install the Telnet Server feature on your Windows servers to allow users to establish text sessions remotely on your server.
• You could install the Server for NIS feature to move your NIS user information into the Windows 2000 Active Directory database and then be able to manage these users using the AD Users and Computers snap-in.
• You could install Perl and the Korn shell features on your local workstation to be able to leverage your extensive Unix scripting skills on the Windows platform.

More on each of these shortly.

Although there’s a lot here that’s supported, one area isn’t. You won’t be able to work with X Windows, the windowing system developed for Unix. Such support would have been useful. The Microsoft marketing material is inconsistent about the purpose of the product, but when the company starts talking about this product as “protecting your investment” in Unix technologies, the unwritten rule is that it’s intended more as a migration tool (from Unix variants to Windows, of course!), and not just as an interoperability toolkit. This helps to explain the lack of X support. This means, of course, that you can’t establish a local graphical terminal session from a Unix host.

Several features new to this version will be of interest to anyone involved in integrating the two environments, particularly the gateway for NFS, the PCNFS server, NIS Server, user name mapping and a number of Unix command-line utilities.

SFU can be administered by a Microsoft Management Console (MMC) snap-in, as seen in Figure 1, or via command-line utilities. Surprisingly, the MMC only manages a small subset of functionality. That’s a limitation. So, more often than not, you’ll need to use the command-line utilities to work with the component parts of the product.

Figure 1. Administration of Microsoft Services for Unix 2.0 via Microsoft Management Console. (Click image for larger version.)

In this article I’ll cover what’s possible in integrating the Windows and Unix environments using the features of SFU and give some insights about how these features work. I’m assuming you already know Windows NT, that you’re working on learning Win2K, and that you possess a smattering of knowledge about Unix networking concepts. We’ll cover the details about the Unix side as we go.

Installation
You can install SFU on workstations and servers running either NT 4.0 with Service Pack 4 or greater or Win2K. It also requires Internet Explorer 4.01 or later. The installation program uses a Microsoft Installer file which means —in a Win2K environment—you could potentially install it using Group Policy. Keep in mind one limitation when installing on an NT platform: You must install it first via Windows rather than the command line.

Installation is straightforward. After launching sfusetup.msi, select the installation directory and the features to install. Once you’ve done that, the chosen features are installed on the local NT or Win2K workstation or server. Only when using the password synchronization feature (described later) do you need to install anything on the Unix hosts.

If you install the NIS Server component of the product (described in the next section), the NIS database will be integrated into the AD database. In order to extend the AD schema, you need to use an account that’s a member of the Schema Admins group.

You can selectively install product services from the set-up GUI or by selecting the appropriate keyword from the command line. One limitation is that you can’t install both the NFS gateway and NFS client on the same machine. This isn’t likely to be a huge problem since the NFS client is a subset of the features of the NFS gateway. More on this shortly. Also, NIS can only be installed on Win2K domain controllers and the NFS gateway on a server, not a workstation.

Server for NIS
Network Information Service (NIS), also known as yellow pages, is a technology from Sun Microsystems sometimes used by Unix machines to share directory information, such as users and groups. This is similar to the way that a single accounts database in NT 4.0 is shared within a domain. The Server for NIS feature allows the NIS database to be stored within the AD database on a Win2K domain controller. A wizard is available to migrate existing NIS domains to Win2K.

Once the NIS user information is stored within AD, you use the regular Active Directory Users and Computers snap-in to manage your user accounts. A new property page called Unix Attributes for each user appears and is shown in Figure 2. Here you have the option to configure the user’s NIS domain; his or her numeric user ID; home directory; and, optionally, primary group name or ID.

Figure 2. Managing Unix user details in Active Directory.

Authentication
It’s one thing to be able to connect Windows with your Unix environment, but doing this securely is another matter. With SFU we have two options for authenticating Windows and Unix users on a Windows network: user name mapping and Server for PCNFS.

With user name mapping, you match up the user and group names between the two platforms. This can be a simple map that matches a Windows domain with an NIS domain. For the simple map to work, the user or group names need to be identical, that is, a “gneilson” account name in Windows that maps directly to a “gneilson” account in NIS.

An advanced map is an explicit list of accounts from each environment mapped together. In this case you can list each user and its equivalent in the other environment or you can map many or all users against one account. For example, you could create a special user in NIS called WindowsUsers and map all users from the Windows domain to this account. Then—on the Unix side—you could set permissions for this type of user, which then effectively grants all Windows users these rights.

SFU makes use of user name mapping in both ways—to map incoming requests from Unix hosts against Windows domain users. Also, when a Windows user attempts to access a Unix resource, SFU automatically supplies the user and group information to that Unix machine.

You can configure user name mapping using the MMC snap-in or the MAPADMIN command.

The Server for PCNFS feature works for DOS. Mac and Windows client machines that can’t make use of user name mapping that are able to query a PCNFSD server. It provides the Unix user and group ID information for these clients when they’re accessing drives on a Unix host using NFS.

Using the MMC snap-in, you define the various Unix groups and users, including the user password. When a user sends the account name and password to the Server for PCNFS service, it returns the numeric user ID and group ID that can be used to connect to a Unix server. (See Figure 3 for an explanation of the process.)

Figure 3. When a user sends the account name and password to the Server for PCNFS service (step 1), it locates (step 2) and returns (step 3) the numeric user ID and group ID that can be used to connect to a Unix server. The client feeds that information to the Unix server (step 4), which allows the client to mount the requested resource (step 5).

SFU also offers a two-way password synchronization feature. This propagates password changes between accounts on your Windows domain and the accounts on a number of configured Unix hosts and vice versa. SFU comes with daemons to install on Solaris, Red Hat Linux, HP-UX or Tru64 Unix to facilitate the password changes on the Unix side. This password synchronization SFU feature then needs to be installed on each DC within the domain. The MMC snap-in allows you to specify the Unix hosts to contact to exchange password information, what TCP/IP port to use and also debugging options such as retries and whether to enable detailed logging.

File Sharing
The essence of Unix file sharing is the NFS (Network File Share) protocol. SFU offers a range of options here: an NFS server, NFS client and NFS gateway. The NFS server option makes available shared directories from Windows to Unix hosts. The NFS client allows a Windows machine to attach to a shared directory from a Unix host. The NFS gateway allows you to connect to a shared directory from a Unix host and then reshare that directory to Windows clients.

These installed NFS components can be stopped or started through the SFU MMC snap-in. Select the component, right click, and select to either start or stop it. Also, the NFSADMIN command-line utility can be used to start or stop each of these components. All of these are standard Windows services and can be managed via the Services applet or the NET START and NET STOP commands.

The NFS client makes it possible to use Windows Explorer to mount an NFS share on your local machine. You can specify the machine you wish to connect to or browse the NFS Network folder under the Entire Network in Network Neighborhood/My Network Places to find NFS resources. From the command line, use the MOUNT command to mount an NFS drive to your local machine. Once you make an NFS mount, you can use the SHOWMOUNT –D command to view the list of NFS mounts on the machine. You can query an NFS server with the SHOWMOUNT –E command to view what directories have been exported and available to be mounted by an NFS client. Figure 4 shows the My Network Places GUI in action. The UNMOUNT command is used to unmount NFS network drives.

Figure 4. You can use My Network Places to view NFS exported directories on the network.

After installing the NFS Server, you can share directories either via the Windows GUI or the command line. When you select a directory in Windows Explorer, right click and choose the Sharing option. A new properties page for NFS Sharing allows you to share that directory and optionally set permissions. NFSSHARE works on the command line in the same way that the regular NET SHARE command works. You can use it without parameters to view the exported NFS directories or to export a given directory. For example:

NFSSHARE shared=f:\shared
SHOWMOUNT -A

SHOWMOUNT –A shows what clients have mounted NFS drives from this machine. The NFS Gateway performs a similar function as NT’s Gateway Services for NetWare. It allows a machine to make an NFS mount of an exported directory and share it again on the network to clients using Windows networking. Therefore, the clients don’t need any NFS software on their machines.

You can set up a redirected NFS share via Windows Explorer or by using the GWSHARE command. GWSHARE without parameters lists all NFS shares.

Admin Tools
SFU includes a telnet server and telnet client. The telnet protocol lets you run a text mode remote terminal session on the server from your client machine. It’s like opening a CMD window at the server without actually having to be at the server.

Win2K Server comes with a telnet server that allows a maximum of two clients at a time. The version included with SFU allows as many client connections as there are server client-access licenses. In keeping with the licensing limitations of NT 4.0 Workstation and Win2K Professional, you can have a maximum of 10 connections.

Although the telnet feature in SFU is the same as in Win2K, it’s worth noting that NTLM security can be used between the Win2K telnet server and Win2K telnet client. This is an improvement over the regular telnet protocols that use plain text to pass account and password information across the network.

You can use either the MMC snap-in or the TNADMIN command to set the configuration of the telnet server.

Also nice is that SFU includes Active State Perl 5.6. Although you can download this for free from the ActiveState Web site, it’s convenient to have on CD already. Perl has rapidly become a main scripting language on Unix platforms, and ActiveState allows Perl scripts to be run on a Windows machine. Although there’s a learning curve for Perl, it’s extremely powerful and contains much more functionality than would be available from either regular batch file programming or the more recent Windows Script Host technology. For example, the text-matching features in Perl are remarkable. In addition, modules in Perl can work with NT event logs or installed NT services.

SFU also includes a demo version of MKS Software’s MKS Toolkit (www.mks.com), which provides a Korn Shell command processor for Windows. This theoretically allows shell scripts written for a Korn shell on a Unix platform to be run “as is” on a Windows machine. For example, a recent client’s Oracle DBAs were Unix folk running NT as their server platform. They used the MKS Toolkit to ensure that their Korn scripts could run now on NT and later (as they hoped) on a Unix server without alteration.

Last, the product includes a group of around 80 Unix-like command-line tools. While many have Windows equivalents, others don’t. A couple of tools I rely on are the “which” command and the vi editor.

The which command searches through the PATH environment variable to find the location of the executable that would be run if the command were executed. For example, if I issued the command:

which which

the software would search through each directory listed in the PATH environment variable and return the first instance of which.exe found:

c:\sfu\which.exe

Without trying to start a religious war about text editors, I consider the vi editor quite potent. Just knowing a few commands could cause you to leave Notepad forever. These command-line tools are useful when added to the power of being able to run a telnet session on a Windows server. For example, in preparing for this article I needed to edit the HOSTS file on my Win2K server from my Linux machine. (Due to reasons that still hurt too much to mention, I only have one working monitor at home at the moment.) I was able to telnet from Linux to the Win2K server, then launch vi to edit the HOSTS file. Then, while still in my telnet session, I could ping my Linux server by name to check that the update was successful.

Let’s Get Along
In this article, I’ve covered the main features of SFU and discussed their implementation. If you need to integrate Windows and Unix networks, I think you’ll find plenty here of value. And that’s the whole advantage of considering a product like SFU. Although other tools offer NFS services, I know of no other product with such a grab bag of features. Even better, the price is right.