How To
Summary
This document will cover setup of NFSv4 + Kerberos in an environment where the three key components (NFS client, NFS server, and Kerberos KDC) are all AIX systems. This document will assume that these are going to be three separate LPARs, although it is possible that you could have the Kerberos KDC running on either the NFS client or server LPAR.
Steps
This document assumes the following system names:
netlab34.austinlab.com: NFS client
netlab35.austinlab.com: NFS server
netlab59.austinlab.com: Kerberos KDC
All of the involved systems must be synced up with the correct time, or else Kerberos operations will fail if there is too much time skew between them.
Use the traceroute command to see which IP addresses each of these systems use to communicate with each other, and then the 'host <IP addr>' command to make sure all of the IP addresses resolve to the expected hostnames and domains on all systems. If there are inconsistencies, you must resolve them or it will cause failure.
Filesets needed
1) IBM NAS (Network Authentication Service) Kerberos software
Install the latest version found here:
As of the time of this writing, 1.16.1.6 is the latest version.
The Kerberos KDC will need krb5.client, krb5.server, and krb5.lic.
The NFS client and server will need krb5.client and krb5.lic.
The NFS client and server will need krb5.client and krb5.lic.
2) modcrypt.base
This is found on AIX Expansion Pack media, and should be found on the ESS (Entitled Systems Support) site also:
The Readme for the NAS software notes the version of modcrypt.base that is needed for use with NFSv4 + Kerberos. At the time of this writing, 6.1.0.4 is the compatible version, and the latest version available.
This fileset needs to be installed on the NFS client and server; it is not needed on the KDC. If there had been a previous version of modcrypt.base installed, then when you upgrade it to the latest version, you must reboot. If you are doing a first-time install of modcrypt.base, a reboot should not be necessary.
Configuration of the Kerberos KDC
1) Install krb5.client, krb5.server, and krb5.lic.
2) Modify your PATH so that /usr/krb5/bin and /usr/krb5/sbin are located BEFORE any Java-related paths. The reason is that Java ships some Kerberos-related commands (kinit, klist) also, and you don't want to accidentally use those.
3) Decide on a Kerberos realm name. Your Kerberos realm name needs to be in all upper case. It can be the same as your domain if you like, or you can be creative and call it something else - but always have it in all upper case. For this document, I will use the realm NFSV4LAB.
4) Make sure IP to name resolution is working as expected. Run this to ensure that the IP address of the KDC resolves correctly to its hostname:
host <IP address of this KDC>
5) Perform initial KDC configuration. All that is needed is the realm name you have chosen, and the domain of your systems:
mkkrb5srv -r NFSV4LAB -d austinlab.com
You will need to specify a password for the KDC database master key, and for the admin/admin principal; be sure to remember these.
6) Use the kadmin tool to create a user principal and an NFS principal for your NFS server. The user principal I'll create is 'mynfsuser' with password 'myuser123'. The NFS principal needs to be called 'nfs/netlab35.austinlab.com' so that it contains my NFS server's fully qualified domain name. When creating the NFS principal, we will assign it a random password, and then will export it to a keytab file. These are the commands to run:
Start up the kadmin tool -
/usr/krb5/sbin/kadmin -p admin/admin
Then from the kadmin command prompt -
addprinc -pw myuser123 mynfsuser
addprinc -randkey nfs/netlab35.austinlab.com
ktadd -k /tmp/netlab35.keytab nfs/netlab35.austinlab.com
quit
This creates a file /tmp/netlab35.keytab that will then be copied to the NFS server. Please note - every time you run the ktadd command to create a keytab for a specific principal, it increases the KVNO associated with the keytab. This has the effect of invalidating any previous keytab that had been created - only the latest KVNO is considered valid. Be aware of that and only run the ktadd command if you are planning to replace any existing keytabs for a given principal.
7) Use the kinit and klist commands to confirm that the 'mynfsuser' credential is obtainable, and that they keytab file allows you to obtain the NFS principal credential as well:
# /usr/krb5/bin/kinit mynfsuser
Password for mynfsuser@NFSV4LAB:
# /usr/krb5/bin/klist
Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0
Default principal: mynfsuser@NFSV4LAB
Valid starting Expires Service principal
06/04/24 12:22:17 06/05/24 12:22:17 krbtgt/NFSV4LAB@NFSV4LAB
If the kinit command showed no errors, and the klist command shows the 'Valid starting' time as the current time, then this worked as expected.
The keytab can be tested with:
/usr/krb5/bin/kinit -kt /tmp/netlab35.keytab nfs/netlab35.austinlab.com
/usr/krb5/bin/klist
klist should now show the NFS principal.
If you want to destroy the existing credential cache file after you've obtained a principal credential with kinit, run:
/usr/krb5/bin/kdestroy
After doing that, running klist will show 'no credentials found'.
8) Copy the /tmp/netlab35.keytab to the NFS server, which in this example will be netlab35.austinlab.com.
The setup of the KDC is complete for now.
Configuration of the NFS server
1) Install krb5.client and krb5.lic from the NAS package. Install modcrypt.base from the Expansion Pack; if a previous version of modcrypt.base had been installed, a reboot must be performed after upgrading it.
2) Configure this system as a Kerberos client of the KDC:
mkkrb5clnt -r NFSV4LAB -c netlab59.austinlab.com -s netlab59.austinlab.com -d austinlab.com
The -c and -s arguments should be the same, as shown.
3) Test to ensure the mynfsuser principal credentials can be obtained:
/usr/krb5/bin/kinit mynfsuser
/usr/krb5/bin/klist
/usr/krb5/bin/kdestroy
4) The /tmp/netlab35.keytab file should be copied over from the KDC; add this to the default keytab (/etc/krb5/krb5.keytab) using the ktutil tool:
/usr/krb5/sbin/ktutil
At the ktutil command prompt:
rkt /tmp/netlab35.keytab (this reads in the keytab we created)
wkt /etc/krb5/krb5.keytab (this writes those entries into the /etc/krb5/krb5.keytab file)
quit
5) Verify the contents of /etc/krb5/krb5.keytab, use kinit to verify the credential can be obtained, list the credential cache file, and then destroy the credential cache file when done:
/usr/krb5/bin/klist -kte
/usr/krb5/bin/kinit -kt /etc/krb5/krb5.keytab nfs/netlab35.austinlab.com
/usr/krb5/bin/klist
/usr/krb5/bin/kdestroy
6) Set the NFS domain of this system. You can use the actual domain of the systems involved, or create a unique name. For this example, I'll choose 'nfsv4lab_domain':
chnfsdom nfsv4lab_domain
Use 'chnfsdom' with no arguments to verify what it is currently set to.
7) Set the NFS realm-to-domain mapping using the Kerberos realm that was created on the KDC and the NFS domain used in the prior step:
chnfsrtd -a NFSV4LAB nfsv4lab_domain
Use 'chnfsrtd' with no arguments to verify the current setting; it will convert the Kerberos realm to lowercase. Do not worry about that despite the earlier note to always use upper case for the realm.
8) Use the 'nfshostkey' command to specify where the NFS principal keytab is located:
nfshostkey -p nfs/netlab35.austinlab.com -f /etc/krb5/krb5.keytab
Use 'nfshostkey -l' to dispaly the current setting.
9) Start up the NFS services:
startsrc -g nfs
lssrc -g nfs
The nfsrgyd service is specific to NFSv4, and the gssd service is specific to adding Kerberos authentication to it. If nfsrgyd is shown as inactive after trying to start it up, a common reason is that 'chnfsdom' has not been used to set the NFS domain name. If gssd is shown as inactive, a common reason is that the modcrypt.base fileset has not been installed yet.
10) Create a version 4 NFS mount point, that has krb5, krb5i, and krb5p security enabled. For this test, I'll export a directory called /nfsexp that has 777 permissions. I'll set the access list to allow only netlab34 to access it; the /etc/exports entry looks like:
/nfsexp -vers=4,sec=krb5p:krb5i:krb5,rw,access=netlab34.austinlab.com,root=netlab34.austinlab.com
If making modifications to the /etc/exports file, be sure to run 'exportfs -av' afterwards.
11) Modify /etc/rc.nfs to ensure that this section is uncommented, so that gssd and nfsrgyd will be started on system boot:
# Begin nfsrgyd startup
if [ -s /usr/sbin/nfsrgyd -a -f /etc/nfs/local_domain ]; then
nfsrgyd_pid=`ps -e | awk '$NF == "nfsrgyd" {print $1}'`
if [ -x /usr/sbin/gssd ] ; then
start gssd /usr/sbin/gssd
fi
[ -z "$nfsrgyd_pid" ] && start nfsrgyd /usr/sbin/nfsrgyd
fi
# End nfsrgyd startup
The NFS server setup is now complete.
Configuration of the NFS client
1) Install krb5.client and krb5.lic from the NAS package. Install modcrypt.base from the Expansion Pack; if a previous version of modcrypt.base had been installed, a reboot must be performed after upgrading it.
2) Configure this system as a Kerberos client of the KDC:
mkkrb5clnt -r NFSV4LAB -c netlab59.austinlab.com -s netlab59.austinlab.com -d austinlab.com
The -c and -s arguments should be the same, as shown.
3) Test to ensure the mynfsuser principal credentials can be obtained:
/usr/krb5/bin/kinit mynfsuser
/usr/krb5/bin/klist
/usr/krb5/bin/kdestroy
4) Set the NFS domain of this system the same as on the NFS server:
chnfsdom nfsv4lab_domain
5) Set the NFS realm-to-domain mapping the same as on the NFS server:
chnfsrtd -a NFSV4LAB nfsv4lab_domain
6) Start up the NFS services:
startsrc -g nfs
lssrc -g nfs
7) Obtain the mynfsuser principal:
/usr/krb5/bin/kinit mynfsuser
8) Mount the filesystem. The krb5 security method will use Kerberos only for authentication when mounting. The krb5i method adds in data integrity, to prevent data from being modified in-flight. The krb5p includes both of those and adds in encryption of the data being sent.
mount -o vers=4,sec=krb5p netlab35.austinlab.com:/nfsexp /mnt
9) Test access and writability:
echo "new test file" > /mnt/newtestfile
cat /mnt/newtestfile
10) Modify /etc/rc.nfs to ensure that this section is uncommented, so that gssd and nfsrgyd will be started on system boot:
# Begin nfsrgyd startup
if [ -s /usr/sbin/nfsrgyd -a -f /etc/nfs/local_domain ]; then
nfsrgyd_pid=`ps -e | awk '$NF == "nfsrgyd" {print $1}'`
if [ -x /usr/sbin/gssd ] ; then
start gssd /usr/sbin/gssd
fi
[ -z "$nfsrgyd_pid" ] && start nfsrgyd /usr/sbin/nfsrgyd
fi
# End nfsrgyd startup
The NFS client setup is now complete.
Other considerations:
1.) If your environment is going to involve multiple domains - for example:
NFS client: netlab34.austinlab.ibm.com
NFS server: netlab35.labs.ibm.com
KDC: netlab59.ibm.com
...then you'll need to manually modify the 'domain_realms' portion of the Kerberos configuration files (/etc/krb5.conf) files to map each of those domains to the realm that is being used:
[domain_realm]
.austinlab.ibm.com = NFSV4LAB
.labs.ibm.com = NFSV4LAB
.ibm.com = NFSV4LAB
2) Each user who needs access to the NFS mount point could have their own Kerberos principal created for access to the mount point. These can be created the same way the mynfsuser principal was created in earlier instructions - if using IBM NAS as your KDC, run '/usr/krb5/sbin/kadmin -p admin/admin', and then from the kadmin command prompt, run 'addprinc -pw <passwd> <username>'.
Once the user logs in and runs '/usr/krb5/bin/kinit <username>' to obtain their credential, they can access the mount point. The user could then change their Kerberos password using '/usr/krb5/bin/kpasswd'. Finally, setting up Kerberos-integrated login (KRB5files or KRB5LDAP) would allow the user to obtain the credential automatically through the login process.
If there is a desire to create just one Kerberos principal that could be shared by multiple users, that can be done also. For this example, again assuming that IBM NAS is being used as the KDC, I'll create a principal called 'nfsaccess', export it to a keytab file, and then this keytab file can be copied to the home directories of the users needing it.
From the kadmin tool (/usr/krb5/sbin/kadmin -p admin/admin):
addprinc -randkey nfsaccess
ktadd -k /tmp/nfsaccess.keytab nfsaccess
quit
To activate the keytab, this command could then be run from the user's .profile:
/usr/krb5/bin/kinit -kt /<full home dir path>/nfsaccess.keytab nfsaccess
Once that is run, the user will have access.
3) Despite previous existing IBM documentation stating otherwise, no nfshostkey setup is needed on the NFS client side. Create nfs/<hostname.domain> principals for your NFS servers, and then do the nfshostkey setup as shown earlier only on the NFS servers in your environment.
4) The NFSv4 + krb5 filesystems can be added to the /etc/filesystems file with the 'mount = true' option so that they are mounted automatically on reboot, but that might not be the best option. If anything goes wrong, like gssd is unavailable, the system could hang on reboot during execution of the /etc/rc.nfs script. This script typically runs before sshd is brought up, so if it hangs, it will not be possible to log in via ssh. It might be better to consider setting 'mount = false' and creating a separate script to mount these filesystems. This script can be run from inittab after sshd has been brought up.
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB08","label":"Cognitive Systems"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"ARM Category":[{"code":"a8m0z000000cvyTAAQ","label":"Communication Applications-\u003ENFS\/NFSV4\/PCNFS"},{"code":"a8m0z000000cxx1AAA","label":"NFS"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
22 September 2025
UID
ibm17156457