Export (0) Print
Expand All

NFS Account Mapping Overview

Published: October 5, 2011

Applies To: Windows Server 2008, Windows Storage Server 2008 R2

NFS account mapping involves mapping UNIX identities to Windows identities stored in AD DS or AD LDS. To provide seamless access to NFS shares, the appropriate UNIX user and group accounts must be associated with the corresponding Windows user and group accounts.

For more information about account mapping between Windows and UNIX operating systems, see User Name Mapping and Services for UNIX NFS Support.

When an NFS client requests access to a file stored on Windows Storage°Server°2008, the account used for accessing the file must first be authenticated and then access to the file must be granted. The following figure illustrates the sequence of events that occur on a NFS client on a computer running a Linux operating system.

helpful alt text

The following sequence describes how authentication and authorization works in Server for NFS, as depicted in the previous figure:

  1. Request from user. The user, unix_user_1, attempts to access the file named F1, which is stored in an NFS shared folder. Server for NFS determines if the client computer has the privilege to access the server. If the client computer does not have access, then Server for NFS returns an error condition to the NFS client.

  2. Map user. Server for NFS attempts to map the UNIX user account to a Windows account using the NFS account mapping methods configured for the server. Authentication is performed by mapping the UID of the unix_user_1 account to a Windows account, user_1, with the same value in the uidNumber object attribute. If no mapped user access methods are configured, then Server for NFS will attempt to use an unmapped user access method.

  3. Mapped user is authenticated. After the account mapping is performed, the corresponding SID of the Windows account is authenticated, If the SID is valid, an access token is generated for the SID, including any group memberships.

  4. User access is authorized. Server for NFS checks the access permissions on the file named F1. The server checks the discretionary access control list (DACL) in the file security descriptor to determine if the specified user and the groups to which the user belongs are permitted the requested access. If access is denied, the server returns an error to Server for NFS, which, in turn, sends an error message to the NFS client.

  5. Data is accessed. Server for NFS reads, or writes, the contents of the file on behalf of the NFS client.

  6. Response sent to NFS client. Server for NFS sends the response to the request in the first step. If the action was to read the contents of the file, then the file contents are returned. If the action was to write, a status code is returned indicating a successful write operation.

UNIX and Windows operating systems have different methods of representing identities and for uniquely identifying users and groups. The following sections describe the identity management features for UNIX and Windows, and the concept of reserved accounts. This is followed by a brief overview of the various NFS account mapping methods that you can use on computers running Windows Server.

The following table lists terminology that is commonly associated with identity management on UNIX operating systems.

Table 1. Terminology associated with UNIX Identity Management

Term

Description

passwd file

This file contains the user account information for UNIX operating systems. The key components for each user account in the file include:

  • User name. This is the user name used during logon and is similar to the SamAccountName attribute of the user object in Windows operating systems.

  • UID. This is an unsigned integer used by UNIX operating systems to identify users and must be unique in the passwd file. Conceptually, the UID is similar to the unique Security Identifier (SID) assigned to a user account in Windows operating systems.

  • GID. This is the identifier for the group to which the user belongs and is similar to the primary group for user accounts in Windows operating systems.

For more information about the passwd file, see the MAN pages for the UNIX operating system you are running.

group file

This file contains the group account information for UNIX operating systems. The key components for each group account in the file include:

  • Group name. This is the name of the group that the user account used during logon belongs to and is similar to the SamAccountName attribute of the group object in Windows operating systems.

  • GID. This is an unsigned integer used by the UNIX kernel to identify groups and must be unique in the group file. The GID is similar to the group account SID in Windows operating systems.

For more information about the group file, see the MAN pages for the UNIX operating system you are running.

Network Information Services (NIS)

NIS is a client–server directory service protocol for distributing system configuration data, such as user and host names between computers on a computer network. You can export the identity information in NIS to a comma separated variable (.csv) format file using tools such as ypcat.

For more information about NIS and exporting identity information in NIS to a .csv file, see the MAN pages for the UNIX operating system you are running.

The following table lists terminology that is commonly associated with identity management on Windows operating systems.

Table 2. Terminology associated with Windows Identity Management

Term

Description

SamAccountName

This object attribute is commonly used to uniquely identify a user or group object in Windows. This value is used when logging in as the user name. This object attribute is most closely related to the user name or group name for UNIX user and group accounts respectively.

SID

This object attribute is used when accessing resources on Windows operating systems. Each user and group object has a unique SID that is presented to the Windows operating system. This object attribute is closest to the UID and GID for UNIX user and group identities respectively.

uidNumber

This user object attribute is added to all user objects in AD DS or after the AD LDS schema is modified. The purpose of this attribute is to map a UNIX UID with a specific user account in AD DS or AD LDS

noteNote
The uidNumber user object attribute exists only if the domain functional level is Windows Server 2008 or later or if the corresponding schema extensions have been applied.

gidNumber

This object attribute exists for all user and group objects in AD DS or is added after the AD LDS schema is modified. For user objects, the purpose of this object attribute is to specify the UNIX mapped group to which the user belongs. For group objects, the purpose of this object attribute is to map a UNIX GID to a specific group account in AD DS or AD ADS.

noteNote
The gidNumber object attribute exists only if the domain functional level is Windows Server 2008 or later or if the corresponding schema extensions have been applied.

There are reserved or built-in user and group accounts in UNIX and Windows that have elevated privileges. As a security best practice, these accounts should not be included in any of the NFS account mapping. This helps ensure the appropriate administrative boundaries are maintained. For example, allowing a root user in UNIX to be a member of the Domain Admins global security group in a domain would allow the root user to have full administrative control over all the computers in the domain.

Windows operating systems exclude the following reserved accounts from NFS account mapping:

  • Members of the Domain Admins global security group.

  • Members of the local Administrators security group on domain controllers.

  • Members of the local Administrators security group on computers with sensitive permissions.

For UNIX operating systems, consider mapping the Root user reserved account on a limited basis. Restrict the use of the Root user account for administrative purposes.

Services for NFS provide a number of methods for performing NFS user account mapping. These methods can be divided into the following categories:

  • Mapped user access. This method is typically used when files and folders are shared using both the NFS and SMB protocols.

  • Unmapped access. This method is typically used when the files and folders are shared using only the NFS protocol.

noteNote
Depending on your NFS solution, you may need to use a combination of the methods listed in the previous table. For example, you may require a combination of mapped user access using AD LDS and unmapped UNIX user access. Select the correct combination of user account mapping methods based on your requirements.

The following table lists the NFS mapped user access methods and provides a description of each method, including when the method might be appropriate in your solution.

Table 3. NFS Mapped User Access Methods

Method

Description

Account mapping using AD DS

In this method, Services for NFS sends LDAP queries to the configured AD DS mapping source to locate user and group objects in AD DS that match the UID and GID provided by the UNIX operating system when users access files on the NFS share. The corresponding mapped Windows account is used for accessing NFS shares.

This method is appropriate in instances when:

  • Your organization has an existing AD DS infrastructure or plans to deploy an AD DS infrastructure.

  • The computers running Services for NFS can access the AD DS infrastructure.

  • UNIX UIDs and GIDs need to be mapped to specific domain user accounts.

noteNote
AD DS cannot be used to map UNIX UIDs or GIDs to local Windows user or group accounts on the computer running Services for NFS, such as the BUILTIN\Administrator account. This is because these accounts do not exist in AD DS. Only user and group accounts belonging to an AD DS domain can be mapped.

For more information about implementing this method, see Configure NFS Account Mapping Using AD DS. For more information about AD DS, see Active Directory Doman Services.

Account mapping using AD LDS

In this method, Services for NFS sends LDAP queries to AD LDS to locate Windows user and group objects in AD LDS that match the UID and GID provided by the UNIX operating system. The corresponding mapped Windows account is used for accessing NFS shares.

This method is appropriate in instances when:

  • You do not have an existing AD DS infrastructure and do not plan to deploy an AD DS infrastructure.

  • The computers running Services for NFS are unable to access the AD DS infrastructure.

  • UNIX UIDs and GIDs need to be mapped to specific user accounts.

  • You have multiple computers running Services for NFS that need to share the same mapping information, such as computers that are members of a workgroup.

For more information about implementing this method, see Configure NFS Account Mapping Using AD LDS. For more information about AD LDS, see Active Directory Lightweight Directory Services.

Account mapping using User Name Mapping (UNM) service

The User Name Mapping (UNM) server in Windows Server 2003 R2 can be used to provide NFS account mapping. Windows Server 2008 or later can be configured to use the account mappings that have been created in the User Name Mapping server running on Windows Server 2003 R2.

Use this method:

  • When you already have the User Name Mapping services running in your environment.

  • To provide temporary backward compatibility, while you migrate your identity mapping information to either an AD DS or AD LDS based mapping source.

  • As a short term solution. For a long term solution, use one of other methods for providing NFS account mapping.

noteNote
The User Name Mapping service can only be administered on Windows Server 2003 R2 using mapadmin.exe or the Services for Network File System snap-in.

For more information about implementing this method, see Configuring Services for Network File System to Use User Name Mapping Service.

The following table lists the NFS unmapped user access methods and provides a description of each method, including when the method might be appropriate in your solution.

Table 4. NFS Unmapped User Access Methods

Method

Description

Anonymous access

This method allows users to access NFS shares without providing any credentials.

This method is appropriate in instances where user authentication is not necessary, such as providing read-only access to document templates or for quickly provisioning scratch shares that host non-sensitive or temporary data.

noteNote
Configuring shares for anonymous access is not recommended due to the lack of security this configuration option provides.

For more information about implementing this method, see Configure NFS Shares for Anonymous Access.

Unmapped UNIX User Access

In this method, Server for NFS automatically generates custom SIDs corresponding to the UIDs and GIDs of the UNIX account requesting access to NFS shares.

Use this method:

  • When you want to grant user access to NFS shares without requiring the administrative overhead of administering user account mapping.

  • When you have a largely UNIX environment and the same share is not shared out over both SMB and NFS protocols.

For more information about implementing this method, see Configure Unmapped UNIX User Access.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft