Accessing Kerberos NFS via /net automounter with kinit only (no /etc/krb5.conf access)

[Will Fiveash]

Here is a response to your questions from a Solaris NFS developer:

> ----- Forwarded message from Wang Shouhua<shouhuaw at gmail.com>  -----
>
> Date: Mon, 14 Apr 2014 20:55:10 +0200
> From: Wang Shouhua<shouhuaw at gmail.com>
> Subject: Re: Accessing Kerberos NFS via /net automounter with kinit only (no /etc/krb5.conf access)
> To: Wang Shouhua<shouhuaw at gmail.com>,Kerberos at mit.edu, Will Fiveash<will.fiveash at oracle.com>
> Message-ID:<CANzOW+KG-H37=JRttBHMyA0=Yaqcc=8c7N6WHh9g_RwuBidk+Q at mail.gmail.com>
>
> On 13 April 2014 21:59, Will Fiveash<will.fiveash at oracle.com>  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