Enduser doc kerberos
From Linux NFS
Contents |
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.
Server Setup
The server needs to be identified to the KDC with a principal of
nfs/<fqdn>@REALM
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 :
NEED_SVCGSSD=yes
check /etc/idmapd.conf
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:
allow_weak_crypto=true
This is a WIP and may be resolved around 2.6.35+
Restart nfs-kernel-server and nfs-common
Client Setup
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:
NEED_IDMAPD=yes NEED_GSSD=yes
Under Debian you may find adding debug options in /etc/defaults/nfs-common helps:
RPCGSSDOPTS="-vvv -rrr"
(May 2010): The client also needs the allow_weak_crypto in /etc/krb5.conf [libdefaults]:
allow_weak_crypto=true
check /etc/idmapd.conf
Same as the server... if you get user-id mapping issues check this is correct.
Restart nfs-common
Mounting
NFSv4 can use Kerberos security to provide:
- authentication
- integrity
- privacy
These are specified on the client side using:
- sec=krb5
- sec=krb5i
- sec=krb5p
respectively. eg:
mount -t nfs4 -o sec=krb5p nfs-server.domain.com:/ /nfs4/
See Exporting Directories section for more details on the exports file syntax.
External Links
The constraint to use -e des-cbc-crc:normal for keytab entries for nfs/<fqdn> principals is not needed:
http://mailman.mit.edu/pipermail/kerberos/2008-May/013698.html
Explanation of enctypes:
http://blogs.sun.com/wfiveash/resource/krb_enctypes_so8.pdf
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 <hartmans@debian.org> Fri, 08 Jan 2010
Warnings
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.
- Use only lower case characters for machines names in kerberos and/or the DNS.
- At present NFS using kerberos authentication is not able to work with multiple network interfaces on the same machine
FAQ
- Problem: 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
- Problem: 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.
- Problem: 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?).
