Here is a response to your questions from a Solaris NFS developer: > ----- Forwarded message from Wang Shouhua<[email protected]> ----- > > Date: Mon, 14 Apr 2014 20:55:10 +0200 > From: Wang Shouhua<[email protected]> > Subject: Re: Accessing Kerberos NFS via /net automounter with kinit only (no > /etc/krb5.conf access) > To: Wang Shouhua<[email protected]>,[email protected], Will > Fiveash<[email protected]> > Message-ID:<CANzOW+KG-H37=JRttBHMyA0=Yaqcc=8c7n6whh9g_rwubid...@mail.gmail.com> > > On 13 April 2014 21:59, Will Fiveash<[email protected]> wrote: >> On Sat, Apr 12, 2014 at 09:50:25AM +0200, Wang Shouhua wrote: >>> We are talking about NFS version 4 (NFSv4) on Solaris only. Why does >>> NFSv4 have such extra requirements? NFS4 clients must maintain a state lease with each NFS4 server. The scope of the lease covers all state created by all users for all mounts from a NFS4 server. For the Solaris and Linux kernel NFS4 client implementations, state renewal is performed by a kernel thread using the root credential. This is of course problematic for kerberos mounts since a user principal does not typically exist in the KDC for the root user. To enable NFS4 lease renewal traffic for kerberos mounts, a host service principal is needed in the NFS4 client's keytab file. This is not simply a Solaris NFS4 client implementation issue. It is also a documented requirement for Linux NFS4 clients:
Linux NFS4 client kerberos config/setup: http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA#Setup_Kerberos_principals Here's a link to Solaris docs explaining how to configure a kerberos client for NFS4: http://docs.oracle.com/cd/E19253-01/816-4557/setup-341/index.html scroll down to "6. start kadmin" section "c. Create a host principal and add the principal to the server's keytab file." >>> What we hoped is that if a machine has Kerberos5 enabled it can >>> connect to *any* other Keberos5 (krb5p/krb5i) filesystem, not only >>> those in the current Kerberos5 realm, if kinit can be provided with >>> the correct tickets. If it doesn't work then it looks like a bug to us >>> (speaking for MOST.GOV.CN). >>> >>> How can we get this fixed? If you cannot provision host service pricipals on Solaris NFS4 clients, then your only option is to mount using NFS3. >> The NFS4 client’s lease renewal thread runs as root (kcred), > 1. Is that just root/ or does that include host/ or nfs/ creds, too? Solaris NFS4 clients need host/<fqdn>@realm. nfs/<fqdn>@realm is required for NFS4 servers. If a system will access and share kerberos mounts using NFS4, add both host/<fqdn> and nfs/<fqdn> to the keytab. > 2. If you look at > http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/fs.d/nfs/nfsd/ > where is the code which does that state update? NFS4 lease renewal happens in the kernel in nfs4_client.c [nfs4_renew_lease_thread()]. > 3. Does nfsd log any errors if the state lease cannot be renewed? No, nfsd runs only on the server. The client logs an (unfortunately) cryptic and unhelpful message along the lines of "protocol error". An enhancement request exists to improve error reporting related to NFS kerberos mounts. We are working to remove the requirement for provisioning Solaris NFS4 clients with host service principals, Another planned (Solaris) enhancement to remove the NFS4client's need for a host service principal, but I cannot comment on a timeframe for delivery. -- Will Fiveash Oracle Solaris Software Engineer ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
