From owner-freebsd-fs@freebsd.org Fri Oct 12 03:32:06 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6F0510D0C36 for ; Fri, 12 Oct 2018 03:32:06 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A48C8F377 for ; Fri, 12 Oct 2018 03:32:06 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-cf9ff70000003ddd-99-5bc015adebfd Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 06.8E.15837.EA510CB5; Thu, 11 Oct 2018 23:31:58 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w9C3Vq4i019074; Thu, 11 Oct 2018 23:31:54 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w9C3Vkgk022179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Oct 2018 23:31:48 -0400 Date: Thu, 11 Oct 2018 22:31:46 -0500 From: Benjamin Kaduk To: Rick Macklem Cc: Peter Eriksson , Felix Winterhalter , "freebsd-fs@freebsd.org" Subject: Re: NFSv4 Kerberos mount from Linux Message-ID: <20181012033145.GC3293@kduck.kaduk.org> References: <30f6446c-6fed-4b1e-9cae-9c417974ec46@audiofair.de> <33A0F0BC-4AD8-4DE3-B484-42B7FB208B6A@ifm.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6nortO9EC0QesvI4s/b16xWBx7/JPN Yubcn6wWD5ddY3Jg8Zj+2dRjxqf5LB4brl9j9Pi9eS9TAEsUl01Kak5mWWqRvl0CV8aZI/tY C+YrVHxf1s3WwDhVqouRk0NCwETi2NIrLCC2kMBiJolbWzS6GLmA7I2MEp+OP2OBcK4ySZze coMJpIpFQFVi76Q5YDabgIpEQ/dlZhBbREBdYvPqfmaQBmaBLkaJCU2zwMYKC+gANbewgti8 AsYSi+fdhpq6jlli0e7FLBAJQYmTM5+A2cxAk/7MuwQ0iQPIlpZY/o8DIiwv0bx1NtgyToFE iRNvG8GOEBVQltjbd4h9AqPgLCSTZiGZNAth0iwkkxYwsqxilE3JrdLNTczMKU5N1i1OTszL Sy3SNdPLzSzRS00p3cQIDn8X5R2ML/u8DzEKcDAq8fD+mLg/Wog1say4MvcQoyQHk5Ior+0n oBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3r6fQDnelMTKqtSifJiUNAeLkjjvxJbF0UIC6Ykl qdmpqQWpRTBZGQ4OJQneVyIHooUEi1LTUyvSMnNKENJMHJwgw3mAhmcJA9XwFhck5hZnpkPk TzHqcrQ9vT6DWYglLz8vVUocYpAASFFGaR7cHFDaksjeX/OKURzoLWHeAyBVPMCUBzfpFdAS JqAlp0L2gCwpSURISTUwuj53tKyZ6mDft+yi0N5nj3QEmsKfR83YVXFC/zjPXcHkOZd9Qr/K fC+ZU89w5+UEFhUlLluvIym9P15efLC+cJKOJ9uaNxmrL3Xc2nwgZZVD0P/duRqnt/1KYl7m MOvXqZ+rLn0R3+7WK9Fne1P0yLIIlei6s8dyp0oq5q//e/7cY46X/cqru5VYijMSDbWYi4oT AXOQoL82AwAA X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 03:32:07 -0000 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” 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 -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@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@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