Windows Services for Unix: There's No Place Like /home
Though far from perfect, Windows Services for Unix makes it a little easier to intermingle platforms. Bring your Unix chops, though, unless you want to point and click your way to an insecure mess.
Windows Services for UNIX (SFU) is yet another entry in the UNIX/Linux/Windows Interoperability Sweepstakes. SFU attempts to ease the mingling of Windows and UNIX systems for authentication and resource sharing, and to ease the migration of UNIX applications to Windows servers. It’s been around for five years or so. It used to cost $99 per client (as if!) but now it’s free. Though free is a relative concept, as you’ll see in the system requirements.
SFU consist of an Interix environment installed as a native subsystem on Windows. It comes with the Korn and C shells, and the familiar, essential GNU tool chain. It also comes with the antique services telnet and Sendmail. Directory and file-system integration are handled via NFS (network filesystem) and NIS (network information services). Other shells and programs, like bash, SSH and Apache, are available from the Interop Systems website.
This article covers the basics of how SFU works; thank you to co-author Shuying Wang for putting SFU through its paces, and sorting out reality from the hype.
SFU 3.5 will only run on Windows 2000/XP Professional and Server 2000/2003. NIS must be installed on a server with Active Directory enabled. If you already have these things, SFU could be a useful tool. If you don’t, you’re looking at a significant investment in server and client access licenses. (And for gosh sakes, why do users pay client access licenses? You’re already paying for the server, and for Windows desktop licenses. Serving clients is the whole idea of running a server, isn’t it?)
Your Windows 95/98/ME clients are out of luck; SFU will not work for them. Windows 95/98/ME use the FAT16/FAT32 filesystems, which have no support for access controls like NTFS and UNIX filesystems do. (By the way, both UNIX and Linux support a wide variety of excellent filesystems, so you can use whatever you like without replacing the entire operating system.)
You’ll need about 20—360 megabytes of hard drive space, depending on what you want to install, and an additional 16 megabytes of RAM. And — I am not making this up — Internet Explorer. Yes, this is a requirement for installing SFU. Secure Computing, here we come.
Coordinating Services And Users
Let’s take a look under the hood of SFU. The User Name Mapping service is the primary tool for knitting your Windows and UNIX services together. This is what allows users to access either Windows or UNIX resources, without migrating existing NIS users into Windows, or Windows users into NIS. All the NFS components of SFU utilize the User Name Mapping service. It provides bidirectional, one-to-one, and many-to-one mapping between UNIX UIDs/GIDs, and Windows user and group identities (SID). The many-to-one mapping allows many UNIX identities to map to a single Windows identity. (The converse is not true, you cannot map multiple Windows identities to a single UNIX identity.)
User Name Mapping administration is managed through the graphical user interface or a command-line tool, mapadmin. By default, User Name Mapping equates Windows domain users and UNIX users with the same names. Or, administrators can elect to map users with different Windows and UNIX names.
File And Resource Sharing
SFU supports UNIX NFS versions 2 and 3. SFU comes with a NFS client, server and gateway. The gateway allows systems that don’t have a NFS client installed to access NFS shares. The Windows-based Server for NFS only supports NFS exports from CDFS (compact disk filesystem) and NTFS (NT filesystem), which means your Windows shares can only be on compact disks, or Windows’ NTFS filesystem. This is not a bad thing, as NTFS is the only Windows filesystem that provides any meaningful data integrity and access controls. Both graphical and command-line administration tools are available. The NFS Sharing tab is a GUI interface accessible by right-clicking the directory in Windows Explorer. The command-line utility, nfsshare, allows scripted share management from either Windows or Unix shells.
For the user, accessing an NFS export is the same as accessing a Windows share. Users browse the NFS network by using Windows Explorer. Users can access NFS exports by either mapping them to a drive letter, or by using Universal Naming Convention (UNC) names, which look like UNIX filepaths, only with backslashes: \server-name\share-name\directory\filename. NFS exports can also be accessed by using the net or mount commands. Users with accounts on both UNIX and Windows receive the same privileges, whether accessing files from a UNIX NFS client or from a Windows NFS client.
Gateway for NFS also uses the User Name Mapping service to map Windows credentials to UNIX UIDs or GIDs before forwarding file access requests to NFS servers. Each gateway request from a user is properly identified, then Windows user names are mapped to corresponding UNIX users before being forwarded to the NFS server. This process ensures that clients accessing NFS servers either directly from machines with Client for NFS, or indirectly through Gateway for NFS, get the same privileges that they would get from UNIX NFS clients. Because access to Gateway for NFS shares is provided by Windows-based networking, these requests are authenticated using Windows credentials, and then mapped to the corresponding UNIX UID/GID pair through User Name Mapping.