The Holy Grail: How to Authenticate NFSv4 against Active Directory with Kerberos

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.

What this guide will not help you with: Docker in it’s default configuration as well as Kubernetes both run as root. You will NOT be able to access an NFS share as local root user on a client. This CAN be done, but I haven’t yet cracked the process of creating a Kerberos context for local root on NFSv4 clients and the NFSv4 ACLs which look like they should be able to grant file/dir access to Kerberos principals instead of an AD user account.

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 [email protected]
• 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 [email protected]
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

While the mount will succeed as local root and you will be able to browse the share contents, reading or editing files will fail due to a lack of Kerberos ticket for the local root user (as well as incorrect file/dir permissions). 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.