Windows Services for Unix: There’s No Place Like /home

Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

System Requirements
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-nameshare-namedirectoryfilename. 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.

Continued on page 2: Active Directory Integration

Continued From Page 1

Active Directory Integration
Server for NIS stores NIS objects in the Active Directory, which integrates UNIX users, groups, and hosts into their Windows-based equivalents. Thus, UNIX users and groups are administered in an identical manner to Windows users and groups. NIS data can be managed by using Active Directory tools such as the Users and Computers snap-in. Plus, any users common to both UNIX and Windows networks can be represented uniquely in Active Directory.

SFU includes bidirectional Windows-to-UNIX and UNIX-to-Windows password synchronization that supports both local and domain account Windows password synchronization. Domain account synchronization requires that Password Synchronization be installed on Windows 2000 or Windows Server 2003 domain controllers. Password change requests are sent to only those computers or users that administrators select. For UNIX-to-Windows synchronization, the ssod.conf file controls the password synchronization behavior. Configuration of the Windows-to-UNIX synchronization uses the SFU Administration snap-in.

You can escape all this synchronization fun by implementing true single sign-on: migrate your UNIX NIS users into Active Directory, and disable your UNIX NIS servers. Microsoft provides some Korn scripts to do this, though be warned, you’ll probably still have a lot of manual tweaking to do. File permissions operate differently in UNIX and Windows. Also, UNIX is case-sensitive; Windows is not, so file and usernames present a potential case nightmare. And users that have multiple accounts will really increase the fun factor.

Adding SFU to an existing Windows network might be just the tool you need to integrate your UNIX users and resources. However, don’t assume it works by magic — you’re going to need UNIX knowledge to make it all work right, and not be a wide-open, insecure mess. Visit Windows Services for UNIX to find documentation and howtos.


Shuying Wang is a soon-to-be computer engineering graduate of the University
of New South Wales, Australia.
In another life, she was a system administrator and programmer at
Iman International
. She lives with 3 computers that run Linux, Mac OS X
and M$ Windows and can
be contacted at

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends, and analysis.

Latest Articles

Follow Us On Social Media

Explore More