The initial articles of Microsoft Windows 2003 High Availability Solutions series describe principles on which Server Clustering is based and provide an overview of its most essential concepts. More recently, we have been discussing resource types, focusing in particular on those that relate to storage. To conclude this topic, 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).
Microsoft has a long-lasting reputation of being one of the most dynamic forces in the midrange operating system software market, frequently employing highly competitive practices against its main contenders. Although most of them are geared toward increasing 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, they also simplify efforts leading to improved interoperability and streamlined coexistence of heterogeneous environments. Windows Services for Unix can be considered as one of the most prominent examples in this category.
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.
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, writeable 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.
Mapping Active Directory Users to Unix Users
Perform mapping between Active Directory and Unix user and group accounts without introducing forest schema changes or setting up Windows domain controllers as NIS Servers. This can be accomplished by installing User Name Mapping (UNM) service on a Windows 2003 Server R2 computer, which is responsible for associating corresponding accounts across both platforms. It extracts them from its Active Directory domain and either an NIS server or local copies of Unix user and group files (etc/passwd and etc/group, respectively). With the default configuration, the NFS component searches for mapping information on the local host. For this to work properly, both UNM and NFS must reside on the same system. This is not a requirement, however.
It is possible to set up a centralized pool of identically configured servers. You can easily replicate their content with Backup Maps... and Restore Maps... menu commands in the UNM node of Microsoft Services for NFS administrative console. These servers leverage a DNS round-robin mechanism to load balance mapping-related network traffic, which not only offers the benefit of redundancy but also leads to improved performance. This involves generating a DNS alias record that references individual IP addresses of Windows servers with identically configured UNM components and pointing to it each NFS server.
In addition, since, by default, the UNM service accepts only local requests, you must modify content of the .maphost file (located by default in the %windir%msnfs folder on the UNM server), by creating an access list specifying remote computers that are either denied or allowed access. The file contains detailed description of the access list syntax. Mappings between Unix and Windows accounts with matching names (referred to as simple) are automatic, once enabled. In case of different naming conventions across platforms, you have an option of defining advanced mappings. This capability also comes in handy if you must introduce many-to-one associations, in situations where several Windows users need to share the same Unix UID.
This approach might necessitate extra maintenance activities. For example, when relying on password and group files to generate mappings, you will need to keep them synchronized between Unix and Windows UNM servers. With multiple, identical installations of UNM component (in redundant arrangements based on DNS round-robin), you not only have more file copies to deal with, but also must ensure mappings on all of them remain consistent. This might be somehow simplified by applying updates on each server via batch files running MAPADMIN command, which is capable of generating new user and group maps from the command line.
Mapping Local Windows Server SAM database Users to Unix Accounts
Perform mapping between local Windows Server SAM database (rather than Active Directory domain) and Unix accounts. This approach requires Services for NFS Authentication component (part of Windows Services for Unix, included in both Windows 2003 Server R2 and the downloadable version) and the User Name Mapping service operating locally on the server hosting NFS shares. This way, local Windows accounts can be associated with their equivalents in a remote NIS database or local copies of Unix password and group files. Similar to the second option, you can employ simple or advanced mappings with a one-to-one or many-to-one relationship between Windows and Unix platforms. Since both UNM and NFS reside on the same computer, no modifications to .maphosts file are needed. This arrangement is not relevant within the context of this article because it is not suitable for clustered installations due to its dependency on local Windows accounts.
Once you have selected the authentication mechanism that best suits your needs, you are ready to review characteristics and implementation of Windows-based Network File System. This will be the focus of our next article, which will present basic features of Microsoft Services for NSF (included in the Windows 2003 Server R2) as well as step through its installation and configuration process on a Windows server cluster.