NFSv4 with Kerberos against Active Directory

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.

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"
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:

Domain = my.domain
Local-Realms = MY.DOMAIN

Method = nsswitch,static
GSS-Methods = nsswitch,static

Let’s disable old protocol versions in /etc/nfs.conf:


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 access:


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:

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 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
systemctl start
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.