Services for UNIX 3.5's Flair for Interoperability

Do-more-with-less IT environments are increasingly characterized by a hodgepodge of UNIX/Linux servers and Windows desktops. To enable multiplatform success, the typical administrator runs many computers, each running a different platform to provide full control over the separate environments. These extra computers are probably expensive and bulky, and they require multiple monitors and keyboard-video-mouse (KVM) equipment. More recently, administrators have been turning to virtual machines to accomplish similar functionality, minus the extra computers. However, virtual machines don't directly solve all interoperability concerns, such as single sign-on (SSO) via Windows-to-UNIX user-account mapping, file sharing, and efficiently managing multiple platforms from one computer.

Microsoft released the first version of Services for UNIX (SFU) in 1999 to help address such interoperability concerns. SFU helps ease UNIX developers' transition to Windows platforms and—through a myriad of tools—provides help to Windows administrators who need to concurrently support UNIX platforms. The most recent version—SFU 3.5—gives Windows users a toolkit of applications with which to create a true UNIX environment that blends impressively with the Windows OS. SFU also lets you run UNIX shell scripts and programs alongside your Windows applications. And its networking features provide Network Information Service (NIS) functionality and NFS tools, which let you use your Windows workstations to access UNIX systems. Let's take a look at this valuable free tool and explore its potential benefits in your environment.

SFU Overview
SFU's core—a POSIX-compliant and fully integrated Interix subsystem—lets you compile and natively run UNIX applications from your Windows platform. SFU 3.5 boasts dramatic performance improvements over earlier SFU versions because it's a true subsystem and not just a UNIX emulator. Therefore, your UNIX programs will run faster, use your hardware more efficiently, and avoid the requirement of a separate (and slower) software layer to emulate the UNIX environment.

By default, SFU installs its files into C:SFU. However, when you invoke a UNIX shell, the file system is single rooted—that is, all the files appear to UNIX programs in their traditional locations (e.g., /etc, /bin, /usr)—thereby simplifying the porting of UNIX programs to SFU because file locations might not need to change. You can still access your Windows files from the UNIX shell by changing directories to, for example, /dev/fs/C. Also, from the SFU UNIX shells, you can launch your native Win32 programs.

SFU provides an NFS client that lets you mount NFS exports. (Think of an NFS export as a Windows share.) Users of older versions of SFU will be happy to know that SFU 3.5 supports such common UNIX features as setuid, setgid, sticky bits, and symbolic links. Overall, Interix includes more than 300 UNIX utilities. You can add to this number by downloading other popular UNIX tools compiled for SFU 3.5—such as Apache, bind, bison, bzip2, GIMP, NEdit, OpenSSH, and OpenSSL—from the Interop Systems Tools Warehouse (http://www.interop
systems.com/tools/warehouse.htm). Linux users comfortable with the BASH shell will appreciate the ability to download and install a BASH shell compiled for SFU 3.5.

For developers, the Interix software development kit (SDK) supports more than 2000 UNIX APIs and includes C and Korn shells, as well as a Perl 5.6.1 interpreter. Programming languages include C, C++, Fortran 77, and Perl. SFU 3.5 also includes support for threading applications (pthreads).

SFU Networking Services
SFU 3.5 includes multifaceted support for NFS, including Gateway for NFS, NFS Server, and NFS Client applications that—together with the User Name Mapping service—let you use local or Active Directory (AD) user accounts to share files with UNIX systems. With these tools, you can access NFS exports from Windows workstations and even create actual NFS exports in Windows. These implementations leverage the Windows security model by using access control entries (ACEs) on a per-user basis through the User Name Mapping service. Therefore, through the User Name Mapping service, you can use a UNIX account name to access a Windows resource or a Windows account name to access a UNIX resource. The User Name Mapping service maps UNIX user ID (UID) or group ID (GID) entities to Windows local or AD user or group objects.

NIS provides a centralized network-logon database for UNIX that's similar to the Windows domain model. SFU provides an AD-integrated NIS server, so you can use your domain username and password to authenticate to a UNIX client configured to use NIS. SFU also includes tools for one-way or two-way password synchronization between Windows and UNIX systems, as well as a Windows Telnet server replacement.

Installing SFU 3.5
SFU 3.5 runs on Windows Server 2003, Windows XP, and Windows 2000. (Microsoft tested SFU 3.5 UNIX interoperability against Solaris 7 and Solaris 8 HP-UX 11i, AIX 5L 5.2, and Red Hat Linux 8.0.) To begin installation, download SFU 3.5 from Microsoft (http://www.microsoft.com/windows/sfu/downloads/default.asp) and extract the 220MB installation files.

SFU includes several client and server features, so before you run the setup program you need to decide which components you want to install and where you want to install them. For example, you can install the SFU 3.5 Interix subsystem and NFS Client application on a Windows workstation to take advantage of the Interix environment and tools to mount UNIX NFS exports. For broader functionality, install the Gateway for NFS or NIS Server applications to provide SFU interoperability services to a larger number of cross-platform systems. In the next few sections, I walk you through the configuration of some of these services on both servers and workstations.

First, we'll install and configure the NFS and NIS services on a Windows 2003 domain controller (DC). Then, we'll look at installing and using the Interix environment on a Windows XP workstation. All the components require an NTFS file system.

The Server Components
To achieve NIS integration with AD, you must install SFU on a Windows 2003 or Win2K DC. On the DC, navigate to the extracted SFU 3.5 files and run setup.exe. Select a Custom installation to review the various installable services. This server will function as the SFU network-services server, so choose to install only the network-interoperability services: Gateway for NFS, Server for NIS, Password Synchronization, User Name Mapping, and Server for NFS Authentication. (When you later install the client workstation, you'll point to this DC for the NIS and User Name Mapping services.)

After you select which components to install, the system will prompt you for information about the User Name Mapping service. This system will be the only User Name Mapping server, so select Local User Name Mapping Server. (In larger environments, you can install User Name Mapping on multiple computers, in a pool of servers, or on a Windows cluster.) The User Name Mapping service supports pulling user and group account data from either NIS or a UNIX-type construction of password and group text files. Because you're configuring NIS, when prompted, select to use NIS instead of Password and group files. Doing so causes the User Name Mapping service to use the NIS server instead of searching for text files for user account information. Next, specify the Windows domain name and type the name of an existing NIS domain, which will be the name that your UNIX clients use. Essentially, you're importing the NIS data into AD so that you can use Windows-based, centrally managed tools to manage it. If you have an existing NIS domain hosted on UNIX servers, you can enter that domain name here; otherwise, leave the NIS Domain name blank and choose to create a new master NIS server, which I show you how to configure in the next section. Remember that the NIS installation upgrades the AD schema, which is irreversible.

To complete the SFU installation, accept or change the default installation location of C:SFU, then click Next to begin copying files. The process finishes with a system restart. After the installation, open the Microsoft Management Console (MMC) Services for UNIX Administration snap-in by clicking Start, All Programs, Windows Services for UNIX, Services for UNIX Administration. Use this snap-in to configure the remaining services, beginning with the Server for NIS service.

Configuring the SFU NIS Server
Now, let's configure the SFU NIS server. This component lets you centrally manage a domain of UNIX users through AD. Using NIS means you don't have to create individual user accounts for every UNIX system. NIS has a hierarchical design and supports master and slave servers. The SFU NIS server must be the master NIS server; however, if your organization prefers to run additional NIS servers on UNIX systems, you can specify a UNIX-based NIS server as its slave. Both Windows clients running SFU and UNIX clients can use the SFU NIS server for user authentication. If you're already using NIS (a traditional UNIX service), SFU includes a domain-migration tool to help you migrate an existing NIS domain to an SFU-homed domain. You can now use a Windows computer running SFU to host your NIS environment.

To manage the servers and nodes in your NIS domain, open the Services for UNIX Administration snap-in, expand the Server for NIS node, and click the name of your NIS domain. Here, you can add additional NIS servers to increase your level of redundancy or scalability. When you finish the SFU NIS installation, you'll see the name of the SFU server you installed in the Server for NIS node. Before you can configure User Name Mapping, you'll need to add at least one user account to NIS, which we'll do next. When you add a user account to NIS, it will automatically be available to log in to any UNIX server configured to use the SFU NIS server. You don't have to add user accounts locally on every UNIX server. Also, if you run mostly Windows and use AD, SFU NIS lets you use your AD tools to manage these accounts.

Open the Active Directory Users and Computers snap-in, and bring up the properties of the user for whom you want to enable UNIX access. Click the newly added UNIX Attributes tab, which Figure A shows, and enter the appropriate values for the user. For a new user, enter the Primary group name/GID—for example, the Linux group named users typically corresponds to GID=100.

Now, log in as root (or other privileged user) to your UNIX host, create the home directory for the new user (e.g., /home/username), and assign the user read/write permissions to the directory. This step is important: Your NIS login test might silently fail if a home directory doesn't already exist when the NIS user first logs on.

Now that you have a NIS server configured on the DC, you need to point your UNIX clients to it so that users can use credentials stored in AD to log on to these clients. To do so, on each UNIX client, you generally use the UNIX command ypbind —broadcast or edit the /etc/yp.conf and /etc/defaultdomain files, specifying the domain and NIS server. Depending on the UNIX variant, you might also need to modify the /etc/passwd and /etc/group files by appending +:::::: and +:::, respectively. For detailed instructions about how to configure your UNIX variant to use NIS, consult your system documentation. After this configuration, restart the UNIX NIS daemon and you should now be able to log in to this UNIX client by using the modified AD user account.

If you run into problems authenticating a newly created user, try resetting the user's password in the Active Directory Users and Computers snap-in. Configure your remaining UNIX clients similarly by creating the home directory, and configure the NIS client to point to the Windows SFU NIS domain and server. Also, you'll still be able to use local accounts to log in to your NIS-enabled UNIX workstations.

After you set up the NIS server, you'll be able to manage the user attributes of your UNIX systems directly through AD. For example, you can change the Login Shell from /bin/sh to /bin/bash in Active Directory Users and Computers, then simply log out and back on to a UNIX workstation for the new shell. However, any logged-in NIS UNIX users might experience problems if your NIS server goes down, so redundant NIS servers are a good idea.

User Name Mapping
SFU uses the User Name Mapping service to map between UNIX and Windows user and group names. The other SFU services require the User Name Mapping service to ensure that when a user on a certain platform requests a resource, the system uses user credentials known by that platform. For example, NFS exports are accessed using UNIX user account information, and Windows file shares are accessed using Windows account information. The User Name Mapping service lets you tie Windows and UNIX accounts together. You'll still create file-level access control lists (ACLs) on either a UNIX or Windows system by using the native permission syntax for users native to that system. User accounts from the alternate platform that map to appropriate, allowed Windows user accounts would be able to access those files by using the mapped identity. Suppose John Public uses the Windows user account John.Public and the UNIX account JohnP. With User Name Mapping, John could tie John.Public and JohnP together so that he can access a UNIX NFS export permissible for JohnP while logged on to a Windows computer as John.Public. The User Name Mapping service permits 1:1 mappings between UNIX and Windows users and groups, or many UNIX identities to a single Windows identity.

Use the MMC Microsoft Windows Services for UNIX snap-in or the SFU command tool mapadmin.exe to configure the User Name Mapping service. From the MMC console, select the User Name Mapping node and go to the Maps tab. If your UNIX names match your Windows domain user names (e.g., the Windows username jeff equals the UNIX username jeff) select the Simple Maps check box. However, to map differently named users or groups, click Show User Maps or Show Group Maps to configure these custom relationships. For example, if you want to map the UNIX group operators to the Windows group Server Admins, select both groups and click Add, as Figure 1 shows.

Gateway for NFS
The SFU Gateway for NFS service provides a mapping from UNIX-hosted NFS exports to regular Windows shares. Windows clients that aren't running SFU can access NFS export data. The following example shows how to configure a UNIX NFS export and make that data available as a Windows share on the Gateway for NFS server.

On a UNIX system, exporting a directory is straightforward. First, make sure NFS is installed and operational. Next, depending on your UNIX variant, edit the /exports file (typically /etc/exports) so that it includes the name of the folder you want to export, the read/write permissions you want to set, and the server (or network) you want to export it to. Set the UNIX folder permissions to allow an NIS user or group Read or Write access to the folder. Execute the UNIX command

exportfs -a

or restart the NFS service to reread the NFS configuration file and host the new export.

Next, on the Gateway for NFS server, you can optionally define an NFS network. Open My Network Places and select Entire Network. You'll notice a new Network type called NFS Network. Right-click NFS Network and click Add new network. Enter the IP address and subnet of the network that contains your NFS server(s). Click OK, then drill down into the NFS network you just created. You should see your UNIX computer hosting the NFS export. Double-click the UNIX computer name to see your UNIX export and the folders it contains.

Finally, configure the Gateway for NFS server to share this UNIX-based NFS export. Click Start, All Programs, Windows Services for UNIX, and launch Gateway for NFS Shares. Use this application to create and configure the Windows share that will map to the NFS export. Name the share, select the drive that you want to assign to that share, specify the NFS export in the Network Resources tree, and choose the encoding (typically ANSI), as you see in Figure 2. Click the Permissions button to set share-level permissions for the newly created share.

The Client Components
So far, I've described the features of SFU 3.5 and walked you through the configuration of Server for NIS, User Name Mapping, and Gateway for NFS. Now, let's take a look at SFU 3.5's main client components. On an XP client, repeat the SFU 3.5 installation but this time, during the custom component selection, accept the defaults to install the SFU Utilities, NFS Client, NFS Server, Windows Remote Shell Service, and Server for NFS Authentication services. You won't install the User Name Mapping service on the client systems because you'll instead leverage the centralized User Name Mapping service previously installed on the network server. After you select the components to install, click Next and answer a few questions specific to your installation choices. First, specify whether the Interix programs will support setuid behavior. When a program enabled for setuid is executed, it will run under its own UID instead of the UID of the account that started it.

When prompted, specify the Remote User Name Mapping Server as the server that you previously configured. (Alternately, if you're installing SFU independently, you can choose to set up a Local User Name Mapping Server, which will perform logon mapping for the local system. After the installation is complete, you must restart the computer. Upon reboot, you'll be able to access SFU features.

The Shell
The UNIX shell provides the input mechanism to the kernel—similar to the Windows command prompt. SFU includes two shells: the C Shell (csh) and the Korn Shell (ksh). Use these shells to launch the SFU UNIX applications. Click Start, All Programs, Windows Services for UNIX, and launch your preferred shell. From the shell, issue the commands

cd /ls -la

to change directory to the root directory and list its contents. If you're familiar with UNIX systems, you'll recognize the single-rooted file structure. In a single-rooted file structure, all the SFU UNIX files and directories are located relative to a single root (e.g., hosts is located at /etc/hosts). However, Windows and Interix file structures are separate. From the Windows perspective, the UNIX files reside in the C:SFU directory. From the SFU UNIX perspective, the C drive is located at /dev/fs/C.

Next, in the SFU shell, issue the command

tree

This command presents a text representation of the folder hierarchy and gives you an idea of the SFU file system structure. Also, notice that this Windows program runs within the Interix shell—useful functionality if you're writing a shell script in UNIX but need to quickly execute a Windows command. You'll find that some (but not all) of the UNIX utilities will also run in the Windows shell and visa versa.

Many popular UNIX programs have already been ported to SFU 3.5 and are available for download and installation. If you manage Linux systems, you're likely familiar with the BASH shell, which offers more features than the C or KORN shells. My next example walks you through the installation of the BASH shell on an SFU client. The BASH client, along with other SFU 3.5—compiled tools, are available on the InteropSystems Tools Web site. InteropSystems uses a Berkeley Software Design (BSD)-type program to package the utilities, thereby ensuring that all the files for a given program are copied into the correct locations.

First, download the packager program (ftp://ftp.interopsystems.com/pkgs/3.5/pkg-1.6-bin35.sh). Launch an SFU shell, navigate to the location to which you downloaded the file, and use the command

./pkg-1.6-bin35.sh

to install the packager. Next, use this packager program to download and install the BASH package directly from InteropSystems:

pkg_add ftp://ftp.interopsystems.com/pkgs/  3.5/bash-2.05.2.2-bin.tgz

(Alternately, you can download the package separately and, when you run pkg_add, point to the local copy of the file.)

You can now execute the BASH shell from an existing shell by typing

bash

or modify the shortcut to the Korn Shell or C Shell to point to the newly installed BASH shell. The package program copies the BASH program to /usr/local/bin/bash, so you'll want to point your shortcut there or create a symlink to the file at the traditional location /bin/bash by using the command:

ln-s  /usr/local/bin/  bash /bin/bash

Another useful add-on program available for SFU 3.5 is the OpenSSH package, which provides Secure Shell (SSH) server and client tools. A wealth of useful programs are available at the InteropSystems site, letting you easily extend your SFU installation.

Client for NFS
Using SFU 3.5, you can connect to NFS exports directly from Windows Explorer after you install the SFU Client for NFS service. To access an export, you can browse to the export by launching Start, My Network Places, then drilling into Entire Network, NFS Network, Default LAN. Find the name of the UNIX server computer and the listed export. Alternatively, you can access the export directly by entering the resource's UNC path (e.g., \servernameshare) from Start, Run or from Windows Explorer.

Server for NFS
You can also use the Server for NFS service to make Windows folders available to other NFS clients over the network. In the following example, I show you how to share the SFU computer's C:download directory as an NFS export.

On the Windows host, install the Server for NFS and Server for NFS Authentication services. Server for NFS Authentication uses local or domain accounts as a source for mapped user permissions, depending on where it's installed. It uses local accounts if it's installed only on a workstation or member server, and it uses domain accounts if domain functionality is set to Windows 2003 or if it's installed on every DC.

Creating an NFS export is similar to creating a Windows share. Right-click the folder you want to export, and click Properties. Go to the NFS Sharing tab and complete the share details, as Figure 3 shows. Click Permissions to change the NFS Share Permissions from the default setting of ALL MACHINES, Read-Only. You set NFS export permissions by machine name or IP address, but you must also specify user-based permissions. User-based permission checking occurs when a user attempts to actually access the file or folder that the export exposed. Go to the Security tab and set NTFS security to allow access to a UNIX mapped domain user. Doing so will let the UNIX user running on a specified computer access the shared resource.

If you've installed the User Name Mapping service on a separate computer from your NFS server, you'll need to configure the .maphosts file to permit access. On the User Name Mapping server, open the file SFUMapper.maphosts, add a plus sign (+) to the bottom of the file, and save it. Doing so allows any computer to use the User Name Mapping server. After you work out all the kinks with the SFU installation and identify who will rely on the User Name Mapping server, you can restrict access to only the hosts that require access. To effect the changes, you'll need to restart the User Name Mapping service on the User Name Mapping server and Server for NFS on the host server.

Use the traditional mount.exe command to access the export from your UNIX computer. For example,

mount -o rw 192.168.0.201:/download/mnt/windows

where rw is read/write privilege, 192.168.0.201 is the IP address of the SFU host, and /mnt/windows is the name of the UNIX folder to which you want to mount the /download export.

Generally, only the root user can use the mount.exe command, so remember to switch the user (e.g., su username) on your UNIX computer to that of the user you granted permissions. With this new user, you should be able to use the command

cd /mnt/windows

to access your new windows NFS export.

Quite a Package
SFU 3.5 packs a lot of functionality into a free package. If you routinely work in both the UNIX and Windows worlds, you should consider it carefully. Although the functionality doesn't match that of a true UNIX host and it doesn't come with an X Server to display graphical UNIX programs, its NFS and NIS services and Interix subsystem help bridge the gap and ease the support of these platforms. Plus, UNIX addicts who use Windows might find comfort in the Interix subsystem—especially after installing some of the third-party UNIX tools compiled for SFU 3.5.