Identity and Identity Mapping

The methods Windows and NFS use to represent user and group identities are different and are not necessarily directly interchangeable. Identity Mapping is the process of converting from an NFS identity representation to a Windows representation and vice-versa. The following sections briefly describe some representations of identity and then how they are used by the NFS authentication methods.

Identity Representations

Windows

Windows uses a Security Identifier (SID) to represent an account. This applies to both user and group accounts. A SID can be converted to an account name and vice-versa directly.

NFS

The representation used by NFS can take many forms depending upon the authentication method and the protocol version.

The most widely used method is to represent an identity using a 32bit unsigned integer, for both users (UID) and groups (GID). This method can be used both by NFS V3 and NFS V4.1. Client for NFS and Server for NFS can convert to or from these identities and a Windows account using a mapping store which is populated with suitable mapping information.

For NFS version V4.1, user and group identities can take the form of “account@dns_domain” or “numeric_id” where the numeric id is a string form of a UID or GID 32bit unsigned integer expressed as a decimal number (See RFC 5661 - http://tools.ietf.org/html/rfc5661, section 5.9). For the “account@dns_domain” format, Server for NFS can use this form of identity directly without any mapping. For the “numeric_id” format, Server for NFS uses the configured mapping store to convert this to a Windows account.  Client for NFS does not support NFS V4.1 in Windows 8 or Windows Server 2012.

For both NFS V3 and V4.1, identities can also be encoded in a Kerberos ticket. Although the accessing account can be accurately represented and retrieved from the ticket, this form of identity is only used for authentication of requests and not as a general representation of an identity. So for example, for a READDIR request, the identity of the account making the request may well be encoded as part of the Kerberos mechanism to authenticate the request. However, the ownership of the objects in the reply will make use of UID, GID or “account@dns_domain” depending on the protocol and mapping information.

 

Authentication Methods

NFS protocols allow for several different authentication mechanisms. The most commonly encountered, and those supported by the Windows Server 2012 Server for NFS are

• AUTH_NONE
• AUTH_SYS (also known as AUTH_UNIX)
• RPCSEC_GSS

The AUTH_NONE mechanism is an anonymous method of authentication and has no means of identifying either user or group. Server for NFS will treat all accesses using AUTH_NONE as anonymous access attempts which may or may not succeed depending upon whether the export is configured to allow them.

The AUTH_SYS mechanism is the most commonly used method and involves identifying both the user and the group by means of a 32bit unsigned integers known as UID and GID respectively. Special meaning is attached to a UID value of ‘0’ (zero) and is used to indicate the “root” superuser.

The RPCSEC_GSS mechanism is a Kerberos V5 based protocol which uses Kerberos credentials to identify the user. It provides several levels of protection to the connection between an NFS client and an NFS server, namely

• RPC_GSS_SVC_NONE where the request identifies the user, and sessions between the client and server are mutually authenticated. This identification is not based on UIDs and GIDs as provided by AUTH_SYS.
• RPC_GSS_SVC_INTEGRITY where not only the client and server mutually authenticated, but the messages have their integrity validated.
• RPC_GSS_SVC_PRIVACY where not only are the client and server mutually authenticated, but the message integrity is enforced and the message payloads are encrypted.

This paper is only concerned with identity and identity mapping. For further details on how to use RPCSEC_GSS with the Windows Server 2012 Server for NFS see “NFS Kerberos Configuration with Linux Client”.

Identity Mapping with RPCSEC_GSS

When using RPCSEC_GSS to provide authentication, the Windows form of the identity of the user making the request can be obtained directly from the information in the request itself. And for some NFS operations that is sufficient. However for NFS V3 based accesses, the NFS protocol itself along with the companion NLM and NSM protocols makes explicit use of UID and GID values in requests (SETATTR), the explicit body of the replies (e.g. READDIR) and in the post-op attributes in replies to many requests. For example, when processing a GETATTR request, the reply contains the UID and GID for the object, so the Windows Server for NFS needs to convert the Windows style identity associated with the file from the file system and convert it to a UID/GID pair to send back to the client. Similarly, for NFS V4.1 based access, the protocol uses “account@dns_domain” or “numeric_id” strings ass account identifiers. So although the use of RPCSEC_GSS provides for better security on the connection between the NFS client and server, it does not replace the need for identity mapping.

Identity Mapping Mechanisms

In order to use the UID and GID values used in NFS requests, they need to be converted, or mapped, to identities that the underlying Windows platform can use. The Microsoft Server for NFS and Client for NFS provide several options to map identities from NFS requests each of which have a set of advantages and disadvantages

• Active Directory

Best used where established procedures are in use to manage user accounts, where there are many machines using a common set of users and groups and/or configurations where common files are shared using both NFS and SMB protocols (SMB is the standard Windows file sharing protocol)

• Active Directory Lightweight Directory Services (AD LDS) or other RFC 2307 compliant identity store

Best used where centralized management of machine local accounts is being used and identity mapping for multiple non-domain joined machines is required.

• Username Mapping Protocol store (MS-UNMP)

Legacy (deprecated) mapping solution available as a feature within Windows Server 2003 R2 and the Services for UNIX product. The mapping server itself is no longer supplied but Client for NFS and Server for NFS can be configured to use an existing mapping server. Information on the configuration and use of UNMP based mapping solutions can be found in the Microsoft TechNet article “User Name Mapping and Services for UNIX NFS Support” at http://technet.microsoft.com/en-us/library/bb463218.aspx.

• Local passwd and group files

Best used for standalone Client for NFS or standalone Server for NFS configurations where file sharing is performed using both NFS and SMB, and Windows domains are not readily available. Can be used for domain joined machines if required.

• Unmapped UNIX Username Access (UUUA) (applies to Server for NFS using AUTH_SYS only).

Best used for standalone Server for NFS configurations where there are no files being shared by both NFS and SMB and where little to no management of Windows identities is required. Can also be used for domain joined servers if files made available via an NFS export are only going to be accessed by  Server for NFS.

There are a number of tools which are involved in managing this mapping information. They include

• Server Manager UI.
• Services for Network File System (NFS).
• Server for NFS PowerShell cmdlets.
• Command line utility nfsadmin (superseded by Server for NFS PowerShell cmdlets).
• Standard Windows domain account management and scripting tools.

PowerShell Cmdlets

As part of Windows Server 2012, the Server for NFS sub-role has introduced a collection of cmdlets, several of which are used to manage the identity mapping information used by NFS. The cmdlets used to manage identity mapping include

• Set-NfsMappingStore
• Get-NfsMappingStore
• Install-NfsMappingStore
• Test-NfsMappingStore
• Set-NfsMappedIdentity
• Get-NfsMappedIdentity
• New-NfsMappedIdentity
• Remove-NfsMappedIdentity
• Resolve-NfsMappedIdentity
• Test-NfsMappedIdentity

 

Active Directory

This mechanism is only available to domain joined machines, both clients and servers and provides for common identities across a large number of machines and where files can be accessed by both NFS and SMB file sharing protocols.

The mechanism makes use of the Active Directory schema updates to include the “uidNumber” and “gidNumber” attributes to user and group accounts for domains running at a functional level of Windows Server 2003 R2 or higher.

Since these are standard fields in the account records any standard management tools and scripting methods can be used to manipulate these fields.

The schema for account records in domains running at a functional level of Windows Server 2003 R2 or higher includes the fields “uidNumber” and “gidNumber” for user accounts and “gidNumber” for group accounts. If these fields are defined then the NFS client and server will automatically use the values as the UID and GID fields in NFS request operations and map those values to the associated Windows user and group accounts. Note that in user records, the assigned UID number must be unique for each user account, and similarly, for group account, the assigned gidNumber must be unique across all group accounts. Multiple user records can have the same value for gidNumber. If the PowerShell cmdlets are used to set mapping information for an account then the cmdlets will ensure there are no duplicate UIDs or GIDs. If other methods are used then the administrator should take care to ensure there is no improper duplication.

Managing the mapping information will require domain level administrator privileges, namely those required to manage account attributes.

To set the machine to use domain based mapping a PowerShell command can be used

 

 

or the Server Manager can be used. This starts the “Services for Network File System” window, and right-clicking on the “Services for NFS” node the properties dialog can be activated.

To enable Active Directory based mapping, activate the Active Directory mapping source.

 

Active Directory Lightweight Directory Services (AD LDS) or Other RFC 2307 Compliant Identity Store.

This mechanism can be used with both domain and non-domain joined machines where the source of identity maps is stored in an RFC 2307 compliant store accessed via LDAP requests. This provides for a method of managing user identities and mapping information where access to files is going to be shared by non-NFS applications or file sharing methods, and either centralized management is required or preferred and there are too many machines to manage individually using local passwd and group files.

A typical configuration would be where a number of Windows machines running Client for NFS and/or Server for NFS are arranged as a group of machines which share a set of common non-domain based identities. Using AD LDS these can be managed as a single set of identities, much like Active Directory, but without the need for a domain. This makes it simpler to manage identities than using local passwd and group files for any changes to identities and their mappings, since there is just a single location to manage rather than multiple sets of passwd and group files to maintain.

The mechanism makes use of the RFC2307 schema for accounts where the uidNumber and gidNumber attributes are used to manage the user and group identity maps respectively.

Managing the mapping information will require the privileges required to manage user and group accounts and their attributes. The specific privileges required will depend on the solution used.

Note that although AD LDS can be used in a domain environment, there is little advantage in doing so and using the normal Active Directory mapping mechanism will probably prove to be easier to manage. However, using an AD LDS mapping store for domain joined machines can be useful in configurations where the central domain cannot be used as a mapping store for some reason. For example only a limited number of domain accounts require a mapping to be set and the central domain would require elevated permissions to modify the domain accounts directly (i.e. the administrator managing the NFS identity mappings is not the same as the domain administrator). Also, the account name cannot have a “domain\” prefix and so the name must make sense on the machine using the mapping. In practical terms this means that a non-domain joined machine must have a matching machine local account and a domain joined machine must have a matching domain account.

To install Active Directory Lightweight Directory Services, a PowerShell command can be used

 

 

This command will install and configure an AD LDS instance for use by NFS. This can be located on any Windows Server 2012 machine and need not be co-located with any Windows NFS client or server. When the command completes, if successful it will display output similar to the following

 

 

To set the NFS client or server to use AD LDS based mapping, the following PowerShell command can be used

 

 

Note that the “LdapNamingContext”  should be set to the value returned as the partition when the AD LDS instance was created. The “LdapServer” should be set to the machine name and port which to be used to contact the AD LDS instance.

Alternatively the Server Manager  can be used to set the NFS client or server to use AD LDS based mapping.

 

Username Mapping Protocol Server.

This is a deprecated method of obtaining mapping information but may still be in use in existing environments. The UNMP Server was a feature in the separately installed Services for UNIX product, and in the Services for NFS feature of Windows Server 2003 R2 release.

The UNMP server provided a source of UID/GID to Windows account mappings which could be used by domain joined machines running Client for NFS and/or Server for NFS. This feature has been largely superseded by the use of Active Directory which provides for better management and scaling.

 

Local PASSWD and GROUP files.

In simple configurations where mapping between UID/GID and Windows accounts is still required, the mapping information can be provided in UNIX style passwd and group files. These have the same fields and format as conventional UNIX passwd and group files with the exception that the account name can optionally make use of the standard Windows account names <domain>\<name>, where the "<domain>\" portion is optional and if absent, the “name” portion indicates a domain account for domain joined machines, or a machine local account for non-domain joined machines. If the machine is domain joined and the account to be mapped is a machine local account, the “domain” portion should be set to either “localhost” or to the name of the machine.

The use of local passwd and group files is enabled by placing both files in the %SystemRoot%\system32\drivers\etc directory. That is, the local files mapping feature is enabled if both the following files exist

• %SystemRoot%\system32\drivers\etc\passwd
• %SystemRoot%\system32\drivers\etc\group

 

This mapping method creates an independent mapping store for each machine and is typically used for

• domain joined machines where a limited number of machines are making use of NFS
• for standalone machines where a simple identity mapping mechanism is preferred, for example a single workstation accessing existing UNIX NFS servers
• a set of UNIX workstations accessing a standalone Windows Server for NFS.

Managing the mapping information will require the privileges needed to create and modify the passwd and group files in the %SystemRoot%\system32\drivers\etc directory. By default the members of the “BUILTIN\Administrators” group have sufficient privileges. It is recommended that these privilege requirements are not changed without a clear understanding of the consequences.

Note that by default, files created in the %SystemRoot%\system32\drivers\etc directory will be readable by all members of the “BUILTIN\Users” group for the computer. If this is considered to be too great a degree of information disclosure then access can be restricted by adding read access permissions for the virtual accounts for the NFS services “NT Service\NfsService” and “NT Service\NfsClnt” to both the passwd and group files and then removing access permissions for the “BUILTIN\Users” group. This can be achieved as follows

From a CMD or PowerShell prompt

 

 

Or, via the Properties dialog Security tab for both the passwd and group files.

To verify that the server is using file based mapping, the “Event Viewer” utility can be used to examine the ServicesForNfs-Server\IdentityMapping channel where the server will write messages to indicate the status of the mapping files.

 

Unmapped UNIX User Access (UUUA)

The UUUA identity mapping mechanism is only available to Server for NFS and can only be used when the AUTH_SYS authentication method is being used.

In situations where there is no requirement to share files accessed by NFS with any other sharing mechanism (e.g. SMB) or local application, then Server for NFS can be configured to directly use the supplied UID/GID identifiers and attach them to files in such a way that the identity information is preserved and is available to an NFS client, but no mapping to any Windows account is required. This is particularly useful for turn-key installations where very little administration is required to set up Server for NFS.

Server for NFS does this by recording the UNIX style UID, GID and mode information in the Windows file system security fields directly[1]. However, a consequence of this is that access to those files by other Windows applications can be problematic since the security information does not identify any Windows account and so standard Windows access mechanisms are not available.

As the methods used by Server for NFS to capture the UID, GID and mode information result in the generation of valid security descriptor, there should be no impact for backup applications provided those applications just copy the data and do not try to interpret or manipulate it in any way.

This method is typically used for standalone Windows Server for NFS installations where little to no configuration is required, such as a turnkey Windows Server 2012 Server for NFS where the only administration required is the creation of the NFS exports. It should be considered a convenience mechanism only as it provides no security (a consequence of the AUTH_SYS authentication method) and is effectively equivalent to access by an anonymous Windows user. The behavior is similar to many standard UNIX NFS server implementations.

No privileges are required as there are no mappings to administer.

Setting a Mapping for an Identity

Active Directory and Active Directory Lightweight Directory Services

As account objects are standard Windows Active Directory objects, any of the standard tools or scripting methods can be used. The account attributes used are “uidNumber” and “gidNumber” for user account type and “gidNumber” for group account types.

These fields can be manipulated several utilities shipped with Windows Server 2012.

The recommended method is to use the Server for NFS PowerShell cmdlets. These cmdlets can be used to query mappings for one or more existing accounts, modify mappings, test mappings and even create new accounts with mappings as a single operation. One of the advantages of using the PowerShell cmdlets to set mapping information is that they help ensure there are no duplicate UIDs or GIDs. Note that the following examples assume that an Active Directory or AD LDS mapping store has already been configured.

To query the mapping for an existing account

 

 

Or to bulk query all the group accounts

 

 

A bulk query for all the user accounts is performed in a similar manner, except that the AccountType is set to User. Simple wildcarding of account names can also be used, for example the following will return all the user accounts with names beginning with the prefix “nfs”.

 

 

To set a mapping for an existing user account

 

 

Or to set the mapping for an existing group account

 

 

 

To create a set of new accounts and with their AUTH_SYS UID/GID mappings

 

 

 

An alternative and more  basic method is to use “adsiedit.msc” to manipulate the Active Directory objects directly. However there are few if any safeguards and extreme caution should be used for this method. This is not the preferred method of setting a mapping.

 

Username Mapping Protocol Server

Refer to the Windows Server 2003 R2 documentation ([NFSAUTH] Russel, C., "NFS Authentication", http://www.microsoft.com/technet/interopmigration/unix/sfu/nfsauth.mspx) for configuring mapping information for the identities being used.

Local PASSWD and GROUP files

As these are standard ANSI text files, any ANSI text editor can be used. The file format is the standard UNIX equivalents and the only active fields are the username, uid, and gid for the passwd file and the group name, gid and group list for the group file.

Note that some of the PowerShell cmdlets can get used to query and test identity mappings set this way, but attempts to set or modify local file based mappings with the PowerShell cmdlets will fail. Note the following example assume that the local file-based mapping store has already been configured.

For examples, to query the current mapping for a user account “root”

 

Or to query for the account name with the UID value of 500 

 

Bulk queries to fetch all the mappings in a single command can also be used but the wildcarding options available with the LDAP based mapping stores cannot be used directly but any standard PowerShell pipe based filters can be used as an alternative.

How to Select a Mapping Method

Generally there is no single mapping solution that is “correct” for any set of circumstances. Instead, many of the mechanism can be used based on a set of tradeoffs leading to a prioritized list drawn up from the available methods.

Considerations

• Is the machine Windows domain joined?
• For servers, is file access going to be shared by both NFS and non-NFS methods (e.g. files also accessed via SMB shares, or other local applications)?
• How many Windows machines are making use of NFS services (both client and server)?
• How many individual users and groups are involved on the Windows machines making use of NFS services?
• Security
  • Access control – Which NFS authentication protocol is in use? For example, RPCSEC_GSS implies a centrally managed account store and so an identity mapping store would be need to map the same accounts. Using the same store would remove the need for synchronization between the stores that would exist if an alternate mapping method were used.
  • Auditing – is an account identity required to monitor access?
• NFS authentication method(s) used (e.g. AUTH_SYS etc)?
• Organizational issues such as availability of the privileges needed to manage identities?
• Network architecture and user environment? For example, are the connections between NFS clients and NFS server machines placed within a controlled environment (machine room, ipsec etc.)? Are NFS servers visible to machines on which users can run applications?

To determine which solution is appropriate for a given situation requires the administrator to select from the available mechanisms according to the tradeoffs applicable to the expected environment. Typically, solutions should be considered in the following order:

1. Active Directory
2. Active Directory Lightweight Directory Services (AD LDS)
3. Local passwd and group mapping files
4. Unmapped UNIX User Access (UUUA)

 

NFS Authentication Method

Using AUTH_NONE as the authentication method has no security whatsoever and is equivalent to using anonymous access with AUTH_SYS.

Using AUTH_SYS as the authentication method places no particular restrictions on the mapping method, consideration should be given to the ease with which this method can be spoofed and as such it provides no real security.

If the environment requires that NFS be authenticated by RPCSEC_GSS then standard Windows accounts will be required. This excludes the use of Unmapped UNIX User Access. Although using RPCSEC_GSS directly provides the necessary rights to access files, a mapping solution is generally required since many NFS procedures identify users and groups via their UID and GID values even though access to those files is authenticated by RPCSEC_GSS. For example, using a Windows Server 2012 Server for NFS processing a READDIR request, the ability to read the directory is determined by the user identified through RPCSEC_GSS, but the ownership of the items in that directory are described by UID and GID values. Without a mapping solution, the server is unable to determine the proper UID and GID values and so will indicate the files are all owned by the configured anonymous user account, typically with UID and GID values of 0xfffffffe (or -2).

Domain Joined Machines

Generally the most convenient solution for domain joined machines is to use Active Directory as the mapping store. This is particularly the case if a large fraction of the domain joined machines and / or users will be making use of either or both of the NFS client and server. Using Active Directory helps ensure that there are none of the synchronization issues that occur if there are separate account stores and identity mapping stores.

A possible problem is that if NFS is used by a small fraction of the accounts or machines, then in large organizations it may be organizationally difficult to manage the identities if for example a single department uses NFS and the departmental level administrators do not have the domain level privileges required to modify the centrally managed user accounts.

If using Active Directory for mapping information is problematic but domain based identities are still desired then alternative solutions are either Active Directory Lightweight Directory Services (AD LDS) or local mapping files.

Using AD LDS has the advantage of a centrally managed mapping store which is particularly useful if there are many user and/or group accounts, or if the valid accounts change frequently. The accounts being mapped must be domain accounts. However, there needs to be a machine available which can host the AD LDS services. This can be a machine hosting the Windows NFS services.

Using local mapping files requires only machine local administrator level privileges rather than domain level privileges and provides all the functionality available for a single machine as that available through Active Directory. In addition, they can also allow machine local accounts to be successfully mapped. However, consideration should be given to the number of machines to be managed.

Both AD LDS and local mapping files suffer from the need to maintain synchronization between the primary account store (Active Directory) and the mapping store (AD LDS or local files). For example, if a new NFS user account is added or deleted, then a change will need to be made to the mapping store. The AD LDS mapping store only needs changes to be applied in the one location for all machines using that mapping store to see the updates. However, if local mapping files are in use, then a change will need to be made in all of the copies of the local mapping files that contain a mapping for that account. 

For machines with Server for NFS, if no domain or machine local identities are required and there will be no sharing of the files exported by NFS with any other application or file sharing protocol, and access is via the NFS AUTH_SYS authentication mechanism, then UUUA based access might be a good solution. This method has the advantage of minimal administration load, and there is no co-ordination with any other machine however it has the potentially significant disadvantage of providing essentially no security.

Non-Domain Joined Machines

The choices for non-domain joined machines are similar to those for domain joined machine with the exception that Active Directory is no longer available.

Using Active Directory Lightweight Directory Services (AD LDS) provides a single centrally managed mapping store which is particularly useful if there are many user and/or group accounts, or if the valid accounts change frequently. The accounts being mapped must be machine local accounts and if care is taken over the naming of the account, the same mapping can be used by several machines.  However, there needs to be a machine available which can host the AD LDS services but this can be a machine hosting the Windows NFS services.

Using local mapping files requires only machine local administrator level privileges and provides all the functionality available for a single machine as that available through AD LDS. As long as all the account names do not have a domain prefix, then machine local accounts are assumed so the same passwd/group file pair can be used on each machine. Consideration should be given to the number of machines to be managed and the amount of changes to the accounts being mapped to determine if the administrative costs are acceptable.

Both AD LDS and local mapping files suffer from the need to maintain synchronization between the primary account store (machine local accounts) and the mapping store (AD LDS or local files). For example, if a new NFS user account is added or deleted, then a change will need to be made to the mapping store. The AD LDS mapping store only needs changes to be applied in the one location for all machines using that mapping store to see the updates. However, if local mapping files are in use, then a change will need to be made in all of the copies of the local mapping files that might be used by that account. Alternatively with local mapping files each machine can have individual passwd and group files with accounts specific to that machine; however this is likely to present administrative problems in terms of ensuring the appropriate uniqueness amongst the UID and GID values being used.

For machines with configured with Server for NFS, if there is no sharing of the files exported by Server for NFS with any other application or file sharing protocol, and access is via the NFS AUTH_SYS authentication mechanism, then UUUA based access might be a good solution. This method has the advantage of minimal administration load, and there is no requirement for co-ordination with any other machine, however as with all AUTH_SYS based mechanisms, it has the potentially significant disadvantage of providing essentially no security.

Troubleshooting

To list all the NFS PowerShell cmdlets

To locate all the NFS related PowerShell commands, start a PowerShell session and use the command

 

The alias “help” can be used in place of “Get-Help”.

Get-help can then be used on individual items to get additional details on that item.

• Get-NfsMappingStore will return the currently configured mapping solution for the machine.
• Test-NfsMappingStore will test the mapping store to confirm that the machine can access the mapping store
• Get-NfsMappedIdentity is used to retrieve one or more mapped identity records from the configured mapping store.
• Test-NfsMappedIdentity is used to verify the configured mapping store can be reached from the machine on which the query is run and that the queried mapping is present in that store.
• Resolve-NfsMappedIdentity is used to determine the mapping being used by Server for NFS. If the mapping is cached then the cached values are used, otherwise Server for NFS will make a request to the configured mapping store to retrieve the mapping.

To Verify That a Particular Identity Mapping is Active

Although the identity mapping can be set in an identity mapping store, there is no guarantee that machines with either Client for NFS and\or Server for NFS can make queries of that store. To determine if the store is accessible from the machine of interest, log on to the machine in question and using the PowerShell cmdlet “Test-NfsMappedIdentity”, the cmdlet will make a request to the store for the mapping information needed to satisfy the request. For example, to test the account mapping for UID value 0

 

Or to test the mapping for the group “specgroup”

 

There will only be output from the command if the test operation fails.

Using the “Test-NfsMappedIdentity” cmdlet will also verify that the mapping information for the account in question does not use any improper duplicate values. That is, the UID value for a user account is unique and the GID value for a group account is unique.

The Server for NFS also keeps a cache of recently used identity mappings. To determine the mapping as currently being used by, or failing that is available to Server for NFS, the Resolve-NfsMappedIdentity cmdlet can be used. This causes the Server for NFS to search the locally cached mapping information, or if there is no local value, to query the configured mapping store for the mapping. In both cases the currently active mapping as known to Server for NFS is returned.

For example, to query for the account mapped to the UID 500

 

 

Or to query for the UID mapped to the user account “root”

  

To Verify The Windows NFS Client or Server Is Using Local File Based Mapping.

The NFS services write messages to the ServicesForNfs-Server\IdentityMapping channel to indicate whether or not the local files have been found and if the format is correct. These messages can be examined using the “Event Viewer” utility. If both group and passwd files have been found and are being used there are two messages, one for each file

For the group file

and for the passwd file.

If there are any issues with either file an appropriate message will indicate which file contains the problem.

Correcting Identity Problems on Files and Directories Using The nfsfile.exe Utility

The Services for NFS Administration Tools feature contains a command line utility, nfsfile.exe, which can be used to correct a number of NFS related identity and access permission related issues for both files and directories. It can also be used to convert files between the UUUA style mapping and Windows style mappings.

For example, to set all the directories and files stored at v:\Shares to be owned by the user account “root” and group account “rootgroup” with UNIX style permissions 755 (rwxr-xr-x) use the command

 

or if all the files under an export were originally created using UUUA mapping, but there is now a domain based mapping solution available, all the file mappings can be converted using the command

 

 

which converts the export and all the files and directories to a Windows style mapping based on standard Windows accounts.

See the MSDN article at http://technet.microsoft.com/en-us/library/hh509022(v=WS.10).aspx and in particular the section titled “Using Nfsfile.exe to Manage User and Group Access”.

Note that currently the nfsfile.exe cannot obtain mapping information from local file based mappings. This means it cannot do the automatic identity conversion between Windows style mapped files and UUUA style mapped files where the utility obtains the mapping information appropriate to the files being processed. Instead the account information must be supplied via the “/r” option, whether that is a UID/GID pair or a Windows user and group accounts on a file by file or single directory sub-tree basis. That is, all the files in a single directory sub-tree can be converted to a single identity in one command, but different users will require multiple commands to be used.

Note also that the utility can also be used to manipulate non-NFS related file permissions. This is not recommended as there are several features of Windows file security and access control that the utility is not designed to process. Instead, the standard Windows file system permission management tools and utilities should be used (e.g. the “icacls.exe” utility).

Feedback

Please send feedback you might have to nfsfeed@microsoft.com