Enduser doc kerberos
From Linux NFS
Kerberos 5 setup for NFSv4
The following is only necessary if you wish to use Kerberos 5 (krb5). (Which is a good idea.)
To use Kerberos with NFS you need to setup the server and the client on your realm.
We assume you have a Kerberos KDC installed somewhere and have configured Kerberos on your client and server. This Kerberos Infrastructure HOWTO is a good reference to configure and start the Kerberos KDC.
The server needs to be identified to the KDC with a principal of
On the nfs-server you can run kadmin and authenticate as kadmin/admin:
# kadmin kadmin: addprinc -randkey nfs/myclient.mydomain kadmin: ktadd nfs/myclient.mydomain
On Debian you should enable the nfs server gssapi daemon in /etc/defaults/nfs-kernel-server :
In the [General] section the Domain value should be the real value of your domain. The value "localdomain" is not a key meaning "your local domain" it is a misguided attempt at documentation!
Domain = your-domain.com
If your REALM is not the same as your lowercased dns domain you can add:
Local-Realm = <REALM>
(This is not documented)
In May 2010: according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568771 You should edit /etc/krb5.conf and put the following in the [libdefaults] section:
This is a WIP and may be resolved around 2.6.35+
Restart nfs-kernel-server and nfs-common
The client must present some kind of principal at mount time. This can be a user or an entry in the keytab; either a host/<fqdn>@REALM principal or an nfs/<fqdn>@REALM principal
Both the id-mapper daemon and the gssapi daemon should be running: This may be picked up by initscripts parsing /etc/fstab or forced in /etc/defaults/nfs-common:
Under Debian you may find adding debug options in /etc/defaults/nfs-common helps:
(May 2010): The client also needs the allow_weak_crypto in /etc/krb5.conf [libdefaults]:
Same as the server... if you get user-id mapping issues check this is correct.
NFSv4 can use Kerberos security to provide:
These are specified on the client side using:
mount -t nfs4 -o sec=krb5p nfs-server.domain.com:/ /nfs4/
See Exporting Directories section for more details on the exports file syntax.
The constraint to use -e des-cbc-crc:normal for keytab entries for nfs/<fqdn> principals is not needed:
Explanation of enctypes:
From the Debian NEWS.Debian.gz referenced above
(1.8+dfsg~alpha1-1 This version of MIT Kerberos disables DES and 56-bit RC4 by default. These encryption types are generally regarded as weak; defeating them is well within the expected resources of some attackers. However, some applications, such as OpenAFS or Kerberized NFS, still rely on DES. To re-enable DES support add allow_weak_crypto=true to the libdefaults section of /etc/krb5.conf Sam Hartman <email@example.com> Fri, 08 Jan 2010
Some warnings about Kerberos:
- The system clocks on your machines must be set to the correct time; install ntp to make sure this is the case.
- The /etc/hosts file must list the fully-qualified domain name as the first entry on the line with the machine's IP address, and the machine's name must not be included on the localhost line.
- Do not us uppercase characters for machine names in Kerberos and/or the host naming solution DNS. This is not a good solution fpr NFS Kerberos only
- At present NFS using Kerberos authentication is not able to work with multiple network interfaces on the same machine
- Issue: Mounting a nfs volume gives an error message and the syslog or dmesg shows
"RPC: Couldn't create auth handle (flavor 390003)"
- Solution: Try 'modprobe rpcsec_gss_krb5' on the client
- Issue: Enabling users other than root to access the nfs4 mount, i.e. bob. The syslog (/var/log/messages) on the client will show something like "WARNING: error from gss_acquire_cred for user with uid 3333 (No credentials cache found)" and "WARNING: Failed while limiting krb5 encryption types for user with uid 3333".
- Solution: Create the Kerberos principal for bob using kadmin or kadmin.local on the KDC. Then on the client, as user bob, run kinit.
- Issue: Mounting gives permission denied. Starting rpc.gssd with verbose output (-vv) gives failed credentials for hostname of server (not FQDN). Nslookup gives FQDN for reverse-lookup. dig -x <IP> gives only hostname (probably BIND9 configuration problem).
- Solution: Create entries with FQDN /etc/hosts (or solve BIND9 configuration problem. How?).