What this guide will help you do: You will be able to access NFSv4 shares when logged onto a Linux client system with an Active Directory user account, your NFS traffic will no longer be clear-text and vulnerable to traffic snooping, both server and client will transparently verify each other’s identity and you will be able to map AD user and group permissions to your NFS shares.
Prerequisites:
All Linux machines involved must be joined to AD, see here for an example of a valid configuration.
They must have their hostnames in FQDN format
They must have valid A+PTR DNS records
Port 2049 on the server needs to be accessible
ALL of the below has to work:
getent group "Domain Users" id my.ad.account kinit my.ad.account@MY.DOMAIN nslookup my.domain chronyc sources (or another timesync client, should point towards your domain time sources)
NFSv4 server (RHEL/CENTOS 8.x) configuration:
First, we install the server binaries and enable require services:
yum install -y nfs-utils systemctl enable gssproxy.service systemctl enable nfs-server
Your /etc/idmapd.conf on the NFS server should have the following:
[General] Domain = my.domain Local-Realms = MY.DOMAIN [Translation] Method = nsswitch,static GSS-Methods = nsswitch,static
Let’s disable old protocol versions in /etc/nfs.conf:
[nfsd] vers2=n vers3=n
Now we disable unneeded pre-nfv4 services and start the server:
systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket systemctl start nfs-server
Let’s create a directory on the server to be shared:
mkdir /nfs-export chown aduser /nfs-export chgrp adgroup /nfs-export
Assuming you did not disable SELinux, we need to fix the security context:
yum install -y policycoreutils-python semanage fcontext -a -t nfs_t "/nfs-export(/.*)?" restorecon -Rv /nfs-export
Now we create our share via /etc/exports file on the server and allow clients from 192.168.1.0/24 access:
/nfs-export 192.168.1.0/24(sec=krb5p,rw,sync)
And export the newly created share with:
exportfs -rav
You can check for any current exports on the server with:
cat /var/lib/nfs/etab exportfs -v
We obtain a ticket for our AD admin account and create an NFS SPN for our server AD computer account:
kinit my.ad.account@MY.DOMAIN adcli update --service-name=nfs
You can check that a new keytab entry was created for the SPN in /etc/krb5.keytab on the server with:
klist -k
Having multiple new entries show up is normal to support a multitude of cipher suites. If you open the server’s computer account details in AD and look up servicePrincipalName in Attribute Editor, you should now see entries that look like nfs/hostname and nfs/fqdn.
NFSv4 client configuration:
This is the easy part. Assuming your client was joined to AD in the same fashion as the server via the method previously linked, mounting the share is simply a matter of having the tools installed and the correct service enabled on the client. No actual NFS configuration is required.
Redhat/CentOS 8.x (seemingly autoenabled the required nfs-client.target service):
yum install -y nfs-utils mount -vvv -t nfs4 -o vers=4.2,sec=krb5p,rw nfs.server.fqdn:/nfs-export /mnt/whatever
Ubuntu 20.04 LTS:
apt install nfs-common systemctl enable nfs-client.target systemctl start nfs-client.target mount -vvv -t nfs4 -o vers=4.2,sec=krb5p,rw nfs.server.fqdn:/nfs-export /mnt/whatever
Login via SSH to the Linux NFSv4 client using an AD user account that you granted access while creating the export directory on the server and MAGIC HAPPENED. The AD user logged on to the client has access to the files shared from the server to the client.
If you need to have local root user on multiple kerberized NFS clients to be able to access and manipulate files and directories created by each other, look here.