NFSv4 Kerberos mount from Linux

[Benjamin Kaduk]

On Fri, Oct 12, 2018 at 12:37:55AM +0000, Rick Macklem wrote:
> From: Peter Eriksson wrote:
> >Just a few comments (random brain-dump) in case someone else is having problems >with NFS & Kerberos.
> >
> >
> >We’ve been using NFSv4 with Kerberos from Linux clients here for many years (with >Solaris-based NFS servers and MIT Kerberos) and lately using FreeBSD as the NFS >server OS (in an Microsoft AD Kerberos environment).
> I agree with the other post that this is a very useful document and it would be
> nice to keep it somewhere where it is easier to find than in the mailing list
> archive.
> I don't know where that could be, so hopefully someone else in FreeBSD-land
> can suggest a good place?
> 
> The one area you don't discuss (and maybe isn't really a problem?) is what
> ticket encryption type(s) you use.
> Kerberized NFS still uses DES (someday this may change, but I think that requires
> implementation of RPCSEC_GSS V3), so it needs an 8byte session key.

This isn't true anymore; you can use stronger session keys just fine.
(See also RFC 6649 -- don't use single-DES!)

> (I have never seen a documented way to convert a session key of greater than
>  8bytes into an 8byte session key for RPCSEC_GSS to use. As such, I have no idea
>  what happens if you choose a ticket encryption type that results in a greater
>  than 8byte key.)

We did have this problem in the AFS world, and are currently using this
hack: https://tools.ietf.org/html/draft-kaduk-afs3-rxkad-k5-kdf-00

> Here's a couple of minor comments:
> [lots of good stuff snipped]
> >4. rc.conf (we have a lot of users in our AD so we have to use a large number for >usermax, replace “liu.se<http://liu.se>” with your NFSv4 “domain” for >nfsuserd_flags)
> >
> >gssd_enable="YES"
> >nfs_server_enable="YES"
> >nfsv4_server_enable="YES"
> >nfscbd_enable="YES"
> Since the nfscbd is only used by the client (and only when delegations or pNFS is
>  enabled in the server), I believe this is harmless, but unnecessary for the server.
> >mountd_enable="YES"
> >nfsuserd_enable="YES"
> >nfsuserd_flags="-manage-gids -domain liu.se<http://liu.se> -usertimeout 10 -usermax 100000 16"
> >
> Btw, if you have many clients doing NFSv4.0 mounts, tuning of your DRC is advised.
> (The defaults are for extremely small NFS servers.) NFSv4.1 mounts don't use the
> DRC, so if that is what your clients are doing, this isn't necessary.
> It's a little off topic, but for NFSv4.0 (and/or NFSv3) mounts and a reasonable
> sized NFS server, reasonable settings in /etc/sysctl.conf might be:
> vfs.nfsd.tcpcachetimeo=600
> vfs.nfsd.tcphighwater=100000
> vfs.nfsd.v4statelimit=10000000
> vfs.nfsd.clienthashsize=10000
> vfs.nfsd.statehashsize=10000
> - If most/all of your mounts are NFSv4.1, then instead of the above, you might want:
> vfs.nfsd.sessionhashsize=10000
> 
> >5. Make sure you use NTPD so the clock is correct.
> >
> >
> >* All clients (Solaris 10, OmniOS, MacOS 10.12-10.14, FreeBSD 11.0-11.2, CentOS 7, >Debian 9, Ubuntu 17-18 tested):
> >
> >1. Make sure FQDN is in /etc/hosts
> >
> >2. Make sure you use NTPD so the clock is correct.
> >
> >3. Have a “host/FQDN at REALM” Kerberos host principal in /etc/krb5.keytab (nfs or >root is not needed for NFS-mounting to work)
> I'm guessing that you use the "gssname=host" mount option for your FreeBSD
> clients? (The name after "gssname=" is whatever name you have before
> "/FQDN at REALM" for this principal name.)
> This is what I referred to as the host-based initiator credential.

I'm told that the Linux client will automatically attempt to use any
of root/, host/, or nfs/ credentials as an NFS client.  This is incredibly
frustrating to me (not least because of the amount of confusion it
perpetuates about how NFS with Kerberos is hard!), and is decidedly not
Kerberos best practices.  I would probably have specified a new host-based
service name, like nfscl/, though I guess there is some argument that root/
is reasonable.

> Thanks for posting this, rick

And thank you for the extra tips!

-Ben