Microsoft takes a highly competitive stance regarding other contenders. In practice, that usually involves increasing the presence of Windows in corporate data centers (dominated in the past by Unix and increasingly welcoming Linux in new implementations) and encouraging migration of Unix-based applications. But sometimes it also involves efforts to improve interoperability and streamlined coexistence of heterogeneous environments.
Windows Services for Unix can be considered as one of the most prominent examples in this category. In this article, we will take a closer look at clustered implementation of Network File System, presenting it within the context of Windows Services for Unix (starting with its approach to cross-platform authentication).
The current version of Windows Services for Unix is available from two distinct sources. The first, in the form of a stand-alone installation posted on the Download Center on the Microsoft Web site was released in 2004.
The other, integrated with the Windows 2003 Server R2 (released in December 2005) can be installed via Add/Remove Windows Components wizard. It requires access to the second disk of the operating system media. Both provide interoperability between Unix or Linux and Windows (Windows 2000 Server SP3 or later, Windows XP Professional, and Windows 2003 Server) and a wide range of Unix-compatible tools and services. They also off bidirectional file sharing based on Network File System (NFS) protocol and integration of variety of authentication methods specific to both platforms. In both cases, user and group accounts are stored in Active Directory, SAM database, Network Information Service, or password and group files, associated via customizable mappings between them.
The offerings differ, however, when it comes to interface and configuration options. This article will concentrate on the functionality built into Windows 2003 Server R2 and point out some of the features that differentiate it from the downloadable version throughout our discussion.
One of the most critical prerequisites to delivering NFS capabilities on Windows servers is support for cross-platform authentication. Its implementation relies on the ability to associate Windows user and group accounts with their equivalents defined on the Unix side. Windows computers providing NFS services to Unix clients must be able to recognize their credentials and grant them appropriate file and folder access level. The recommended approach to resolving this challenge depends primarily on the way security principals are managed in their respective environments. Just as Windows can use either local (SAM) databases on individual servers or NTDIS database distributed across Active Directory domain controllers, Unix can either maintain separate user IDs (UIDs) and group IDs (GIDs) on each computer or unify log-on information in the form of Network Information System (NIS) domain. The NIS domain can contain one or more NIS servers with a single, write able master and any number of read-only subordinates, known also as slaves. Multiple Unix installations can share their accounts. Depending on these factors, three options that facilitate the integration of Windows and Unix authentication required for Microsoft implementation of NFS Server:
Active Directory Lookup Functionality
Implement Active Directory lookup functionality (available in Windows 2003 Server R2 implementation of Services for Unix but not in the downloadable version), which requires configuring a Windows 2003 Server R2 based Active Directory domain controller as part of NIS infrastructure in the master role, since a Windows system cannot operate as a subordinate to a Unix-based master. This allows Windows domain member servers hosting NFS (as long as they are on Windows 2003 Server R2 level) locating relevant information about security principals accessing local shares simply by referencing their domain controllers.
Making Active Directory NIS-aware requires extending the forest
schema using ldf files located on the Windows 2003 Server R2
installation media. If, however, your forest was set up at that
operating system level, in which case, the extensions have already
been applied during original DCPROMO). This is done by logging on
to the forest schema master using an account with Schema Admin
privileges and running
ADPREP /FORESTPREP from the
CMPNENTS/R2/ADPREP folder on the second disk of the R2 installation
media. To take advantage of the schema changes, which support NIS
by introducing several new attributes for user, computer, and group
classes, and configure your domain controllers as NIS servers, you
must also install Identity Management Services for Unix. This is
done from the Windows Component Wizard (part of Add or Remove
Programs Control Panel applet in Windows 2003 Server R2) by
selecting the appropriate subcomponent of the Active Directory
Services feature set. The choices are Administration Components,
Password Synchronization and Server for NIS. Once again, you will
be prompted for the Windows 2003 R2 Disk 2 source files. As the
result of installation, the Unix Attributes tab gets added to the
Properties dialog boxes of user, group, and computer objects in
Active Directory Users and Computers administrative console. Its
entries can be used to assign mapping to corresponding Unix
accounts by filling out their UID and GID values.
Once these steps are complete, you can proceed with importing NIS database files (maps) into Active Directory using NIS Data Migration Wizard, available from Microsoft Identity Management for Unix console. The wizard identifies matches between Unix and Active Directory accounts by comparing entries in the Unix password and group files against sAMAccountName and cn attributes of Windows users and groups. It updates Unix attributes exposed through schema extensions. Non-matches result in new (initially disabled) accounts. Unfortunately, the migration process does not allow you to use custom mappings, hence you might have to resort to renaming (at least temporarily) existing accounts if you do not want to end up with duplicates for users whose Unix and Windows credentials differ. These can be identified by running a trial migration and reviewing its logs. Following the successful migration of NIS maps to your Windows 2003 Server R2 domain controller, you must designate it as a master in the NIS domain from which the files were imported, by starting its NIS service and setting up all other NIS servers as its subordinates. Furthermore, by setting up Password Synchronization subcomponent on each of Windows domain controllers not operating as NIS Servers, the automatic propagation of new passwords changed by Active Directory users to NIS database files is enabled.