Windows/Unix Interop: HA NFS on Windows Server 2003

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

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.

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.

Article courtesy of ServerWatch

Latest Articles

Follow Us On Social Media

Explore More