Problem solve Get help with specific problems with your technologies, process and projects.

NFS role eases account mapping across Unix and Windows

Admins can keep closer tabs on user permissions over networks running various server platforms via a new service for Windows Server 2008 R2.

Most of what’s in Windows Server 2008 R2 revolves around Windows itself, of course, but a few of the less-sung features involve Windows Server’s UNIX services. These don’t receive much attention unless you’re in an environment with a mix of Unix and Windows Server, where these features become pretty crucial.

One important element of any Unix environment is the Network File System (NFS), a remote-access protocol that allows files and directories to be shared over a network. For years, Windows has supported NFS in the form of its Services for Unix add-on, but Windows Server 2008 R2 adds NFS support as a core component -- a role service named, appropriately enough, Services for NFS. (For a general overview of what’s new to NFS in Windows Server 2008 R2, Microsoft has a TechNet document that briefly breaks down the new features.)

A common problem with implementing NFS in a heterogeneous environment involves how the different systems handle permissions and user accounts. To explain the way Windows Server 2008 R2 implements NFS in this regard, Microsoft has posted an article entitled NFS Account Mapping in Windows Server 2008 R2. It’s useful for those who are new to both Windows Server and Unix/NFS since it shows how elements in each (specifically user and group objects) interact with and complement each other through Windows Server’s support for NFS.

Services for NFS can check user access to Network File System shares in two basic ways:

  1. Mapped user access creates distinct links between Unix user/group identities to Windows identities via either Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AS LDS). This is useful if you have an existing AD installation and want to authenticate your users’ access against that.
  2. Unmapped user access doesn’t make direct links between Unix and Windows IDs. Instead it can automatically generate Windows security IDs from Unix identities or simply provide anonymous access from unverified clients. This approach is appropriate if you’re not depending on an existing cache of user/group identities in Windows Server.

The Microsoft article walks the reader through explanations of both methods, along with their sub-iterations, and describes in fair detail how to set each one up. The document also contains a good deal of discussion about Unix and Windows identity management functions and how they correspond (or don’t correspond) to each other.

Many of the explanations are accompanied with graphical examples of how the process in question works, such as how custom SIDs in Windows Server can be automatically generated when using unmapped Unix user access. An interesting touch is revealed here: the permissions bitmask for the Unix account is incorporated into the name of the auto-generated SID, so one can look at the SID and its permissions assignments from a glance.

Finally, one of the most time-consuming tasks described in the document involves setting up all the individual user/group mappings. Thankfully, there are several ways to speed up the job, such as importing .CSV lists of the mappings and using cmdlets in Windows PowerShell to automate the process.

You can follow on Twitter @WindowsTT.

Serdar Yegulalp has been writing about computers and information technology for more than 15 years for a variety of publications, including InformationWeek and Windows Magazine.

Dig Deeper on Windows Server storage management