While you’re more likely to be familiar with accessing network file shares via Server Message Block (SMB), or the Windows implementation of SMB (CIFS), the Network File System (NFS) is still prevalent in modern production environments, such as on Unix servers like NetApp ONTAP and Dell EMC Isilon/PowerScale OneFS.
Originally designed in 1984 at Sun Microsystems with roots in Unix, NFS is an open standard for distributing a file system across a network for multi-client access. Currently at version 4.2, NFS has grown to include many authentication methods at both the share (known as an “export” in NFS terms) and file system levels, including client IP/hostname, auth_sys (Unix auth), Kerberos, and NFSv4.x ACLs.
NFS is a powerful protocol, however it traditionally has not played well with environments that mix Windows with Unix. To enable Windows client access to NFS exports, each NFS export would also need a Samba share equivalent (an SMB implementation for Unix).
However, this changed when Microsoft implemented NFS client and server tools. As of the time of this blog, Microsoft’s NFS documentation lists the following operating system support:
NFS Server Versions
NFS Client Versions
Windows 7, Windows 8.1 Windows 10
Windows Server 2008, Windows Server 2008 R2
Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
NFSv2, NFSv3, NFSv4.1
How to Configure Windows as an NFS Client
First, we need to enable certain features within Windows in order to perform NFS client operations. The easiest way to do so is in an elevated PowerShell session, and the command differs depending on if our client environment is running Windows 10 or Windows Server.
That’s it! Now we’re ready to mount NFS exports from a Unix server. However, we’re likely to only have read access (assuming our IP is granted access to the NFS export in the first place) due to how UID/GID mapping works between Windows and Unix.
To solve this, there are a few ways we can perform identity mapping (Windows user vs. Unix UID/GID). There’s also a useful PowerShell command we can run at any time that will check the current Windows user’s UID/GID mapping configuration:
Before we go over identity mapping methods, let’s first discuss what Unix UIDs and GIDs are and how they relate to Windows users when mounting NFS exports.
What Are Unix UIDs & GIDs?
In Unix-like operating systems, such as Linux, users and groups are identified by user identifiers (UID) and group identifiers (GID) respectively. From an operating system perspective, UIDs and GIDs are what give users and groups access to resources on the system, such as files and folders.
For both UIDs and GIDs, 0 is reserved for root, 1-999 are reserved for system accounts and services, and 1000+ are for user accounts. If you were to run the id command on the command line as the first user configured on a new Linux host, you’d probably notice both the UID and GID are 1000.
uid=1000(danp) gid=1000(danp) ...
As users get created, UIDs and GIDs should continue to match. 1001 (UID) / 1001 (GID), 1002 (UID) / 1002 (GID), etc.
So why is this important to mounting NFS exports on Windows clients? Well, Windows uses entirely different mechanisms for identifying users and groups (Security Identifiers, aka SIDs). UIDs and GIDs are not a concept on Windows, at least not until recently when NFS client functionality was added to that operating system.
In order to properly authenticate to a Unix server providing NFS exports, we’ll need to perform identity mapping on our Windows client in order to convert a user’s Windows representation of its identity to a Unix identity representation. Essentially, we need to map Windows users to Unix UIDs and GIDs, so when an NFS export is requested the Unix server is able to properly understand which user is making the request.
There are a few different ways we can achieve this, which we’ll go over next.
Identity Mapping Methods for Windows NFS Users & Unix UID/GIDs
1. Active Directory (AD)
If both the Unix NFS server and Windows NFS client are joined to the same Active Directory domain, then we can handle identity mapping in Active Directory. This is the preferred method for security purposes when possible.
NOTE:This method is not available if method #2 (below) is in use, as the presence of a local \etc\passwd file will take precedence for identity mapping.
By default, our NFS client won’t look up identity mapping in Active Directory, however we can change that with the following command in an elevated PowerShell session on the NFS client:
Next, we’ll need to configure our identity mapping in Active Directory Users and Computers.
To view uidNumber and gidNumber attributes for each user, make sure you have Advanced Features enabled under the View dropdown:
You’ll then be able to view and edit those fields in a user or group’s Properties menu, on the Attribute Editor tab.
It can be cumbersome to manually map UIDs and GIDs for many Active Directory users, however there are PowerShell commands that help script/automate this process based on a UID/GID CSV export from an AD-joined Unix NFS server.
With UID/GID data for many users imported to the PowerShell session from a CSV, this command can be looped through to set the appropriate attribute values for each desired user.
NOTE: In the Set-ADUser command, “add” should be changed to “replace” if a user already has a value for either uidNumber or gidNumber.
Using this approach, we can now mount an NFS export to an available drive letter via Command Prompt, and the UID/GID will be mapped per the current Active Directory user’s uidNumber and gidNumber attribute values.
» mount \\<nfs_server_ip_address>\path\to\nfs\export Z:
The path after the NFS server’s IP is the local path to the NFS export on the NFS server, and the drive letter is any available drive letter on the Windows NFS client.
Of course, the Unix rights given to the user we’ve mapped to ultimately decide what kind of access we have to the export, such as read/write or read-only.
2. Local \etc\passwd file
The previous method utilizing Active Directory is preferred, so we won’t go into detail for this approach. However, it’s worth stating that Windows can perform local identity mapping using Unix-style passwd and group files, located in %SYSTEMROOT%\system32\drivers\etc.
If the passwd file is present and has identity mapping information for the current Windows user, then the mappings specified in the passwd and group files will be used for the client’s NFS mount requests rather than UID/GID mappings in Active Directory or the AnonymousUid/AnonymousGid Windows registry settings outlined below.
When running the Get-NfsMappingStore PowerShell command, you’ll notice PasswdFileLookupEnabled is True whenever this workflow is in effect for the current Windows user.
This approach uses the same mount syntax as the Active Directory identity mapping approach above:
» mount \\<nfs_server_ip_address>\path\to\nfs\export Z:
3. AnonymousUid/AnonymousGid Windows registry settings
This final method is simple but potentially allows any local user to mount the target NFS export(s) with read/write access, as opposed to securing write permissions to specific local Windows users via the methods above. For this reason, this is considered an insecure approach and is not recommended.
To map the local Windows client to the UID and GID of the Unix user that owns the desired export(s), we’ll run the following in an elevated PowerShell:
After adding these keys to the Windows registry, reboot to have them take effect.
After, the following Command Prompt command will mount the desired NFS export with read/write access (assuming the client’s IP has permission to mount the export, and that the UID/GID mapping is correct for each desired export):
» mount -o anon \\<nfs_server_ip_address>\path\to\nfs\export Z:
Stealthbits – Now Part of Netwrix
IDENTIFY THREATS. SECURE DATA. REDUCE RISK.
Stealthbits – now part of Netwrix – is a customer-driven cybersecurity software company focused on protecting an organization’s sensitive data and the credentials attackers use to steal that data. By removing inappropriate data access, enforcing security policy, and detecting advanced threats, our highly innovative and infinitely flexible platform delivers real protection that reduces security risk, fulfills compliance requirements, and decreases operational expense.
Dan Piazza is a Technical Product Manager at Stealthbits, now part of Netwrix, responsible for PAM, file systems auditing and sensitive data auditing solutions. He has worked in technical roles since 2013, with a passion for cybersecurity, data protection, automation, and code. Prior to his current role he worked as a Product Manager and Systems Engineer for a data storage software company, managing and implementing both software and hardware B2B solutions.
Adopting a Data Access Governance strategy will help any organization achieve stronger security and control over their unstructured data. Use this free guide to help choose the best available solution available today!
To achieve what you’re looking for I recommend identity mapping in order to convert the user’s Windows representation to a Unix identity representation, rather than taking the approach of authentication via anonymous UID/GID.
In the blog I outline three approaches for Identity Mapping Methods for Windows NFS Users & Unix UID/GIDs, and methods #1 and #2 should work for your needs (#1 if your Windows User is an Active Directory User; #2 if you’re not joined to an Active Directory domain).