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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Wang Shouhua
I am on Solaris 10U4 - can I access a NFS filesystem with (mandatory)
krb5p authentication via the Solaris /net automounter with kinit only,
without having r/w access to /etc/krb5.conf access)?

Wang
--
Wang Shouhua - [hidden email]
中华人民共和国科学技术部 - HTTP://WWW.MOST.GOV.CN


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Tom_Krauss
Hi,

you must configure /etc/nfssec.conf to support the krb5p as sec mode on your client and (re)start gss (and autofs probably).
The solaris client should automatically use the best sec mode offered by the server when automounting the share.

If your client system is not kerberized and has no keys for root/FQDN in its krb5.keytab then it will report ie:
df: cannot statvfs /path/to/share: Permission denied

I am not sure if that is intented or stable.

However - you will be able to access the share through /net as a normal user given you have gathered a nfs ticket. You may use KRB5_CONFIG to feed the appropriate configuration to kinit.

Hth

Reply | Threaded
Open this post in threaded view
|

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

Will Fiveash-2
In reply to this post by Wang Shouhua
On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote:
> I am on Solaris 10U4 - can I access a NFS filesystem with (mandatory)
> krb5p authentication via the Solaris /net automounter with kinit only,
> without having r/w access to /etc/krb5.conf access)?

You'll need to have Solaris krb configured which stores its config in
/etc/krb5 not /etc as is the MIT default.  You'll also need read access
to /etc/krb5/krb5.conf and have the system properly configured to do NFS
with krb in general (read the Solaris 10 online docs).

Beyond that, whether a user kinit'ing is enough depends on which version
of NFS you are using.  On the client side NFSv3 sec=krb5p shares will
automount if the user triggering the mount has a krb cred in their
ccache (klist will show that) and does not require any keys in the
system keytab nor does it require root to have a krb cred in general.

NFSv4 on the other hand does require that the root on the NFS client
system have a krb cred in its ccache.  This can be done either by
running kinit as root or having at least one set of keys for either the
root/<host> or host/<host> service princ in the system keytab which will
be automatically used to acquire a krb cred for root.

On the client system "nfsstat -m" will show what version of NFS is being
used.

--
Will Fiveash
Oracle Solaris Software Engineer
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Wang Shouhua
On 11 April 2014 22:14, Will Fiveash <[hidden email]> wrote:

> On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote:
>> I am on Solaris 10U4 - can I access a NFS filesystem with (mandatory)
>> krb5p authentication via the Solaris /net automounter with kinit only,
>> without having r/w access to /etc/krb5.conf access)?
>
> You'll need to have Solaris krb configured which stores its config in
> /etc/krb5 not /etc as is the MIT default.  You'll also need read access
> to /etc/krb5/krb5.conf and have the system properly configured to do NFS
> with krb in general (read the Solaris 10 online docs).
>
> Beyond that, whether a user kinit'ing is enough depends on which version
> of NFS you are using.  On the client side NFSv3 sec=krb5p shares will
> automount if the user triggering the mount has a krb cred in their
> ccache (klist will show that) and does not require any keys in the
> system keytab nor does it require root to have a krb cred in general.
>
> NFSv4 on the other hand does require that the root on the NFS client
> system have a krb cred in its ccache.  This can be done either by
> running kinit as root or having at least one set of keys for either the
> root/<host> or host/<host> service princ in the system keytab which will
> be automatically used to acquire a krb cred for root.
>
> On the client system "nfsstat -m" will show what version of NFS is being
> used.
We are talking about NFS version 4 (NFSv4) on Solaris only. Why does
NFSv4 have such extra requirements?

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?

Wang
--
Wang Shouhua - [hidden email]
中华人民共和国科学技术部 - HTTP://WWW.MOST.GOV.CN


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Will Fiveash-2
On Sat, Apr 12, 2014 at 09:50:25AM +0200, Wang Shouhua wrote:

> On 11 April 2014 22:14, Will Fiveash <[hidden email]> wrote:
> > On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote:
> >> I am on Solaris 10U4 - can I access a NFS filesystem with (mandatory)
> >> krb5p authentication via the Solaris /net automounter with kinit only,
> >> without having r/w access to /etc/krb5.conf access)?
> >
> > You'll need to have Solaris krb configured which stores its config in
> > /etc/krb5 not /etc as is the MIT default.  You'll also need read access
> > to /etc/krb5/krb5.conf and have the system properly configured to do NFS
> > with krb in general (read the Solaris 10 online docs).
> >
> > Beyond that, whether a user kinit'ing is enough depends on which version
> > of NFS you are using.  On the client side NFSv3 sec=krb5p shares will
> > automount if the user triggering the mount has a krb cred in their
> > ccache (klist will show that) and does not require any keys in the
> > system keytab nor does it require root to have a krb cred in general.
> >
> > NFSv4 on the other hand does require that the root on the NFS client
> > system have a krb cred in its ccache.  This can be done either by
> > running kinit as root or having at least one set of keys for either the
> > root/<host> or host/<host> service princ in the system keytab which will
> > be automatically used to acquire a krb cred for root.
> >
> > On the client system "nfsstat -m" will show what version of NFS is being
> > used.
>
> We are talking about NFS version 4 (NFSv4) on Solaris only. Why does
> NFSv4 have such extra requirements?
>
> 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?

This is not a krb problem, it's an issue with the way NFSv4 was
implemented by many vendors including Solaris.  It's my understanding
that many Linux distros have the same requirements.

Here is some explanation about the issue sent to me by a NFS developer:

"Unlike NFS3, the NFS4 protocol is stateful, and a
 lease model is used to manage its state.
 
 After creating state tokens, NFS4 clients must periodically
 check-in with the NFS4 server to renew their state lease.
 If the state lease is not renewed, the server is free to
 expire the client’s lease and destroy its state.   This
 is precisely what happened to your client.
 
 The NFS4 client’s lease renewal thread runs as root (kcred),
 and when the client’s keytab doesn’t contain a host svc princ,
 kcred/root cannot be mapped to a kerberos principal.  The
 end result is that the renew thread cannot send its OP_RENEW
 to the server to renew its state lease."

You should ask about this issue on a NFS developer mail list.

--
Will Fiveash
Oracle Solaris Software Engineer
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Wang Shouhua
On 13 April 2014 21:59, Will Fiveash <[hidden email]> wrote:

> On Sat, Apr 12, 2014 at 09:50:25AM +0200, Wang Shouhua wrote:
>> On 11 April 2014 22:14, Will Fiveash <[hidden email]> wrote:
>> > On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote:
>> >> I am on Solaris 10U4 - can I access a NFS filesystem with (mandatory)
>> >> krb5p authentication via the Solaris /net automounter with kinit only,
>> >> without having r/w access to /etc/krb5.conf access)?
>> >
>> > You'll need to have Solaris krb configured which stores its config in
>> > /etc/krb5 not /etc as is the MIT default.  You'll also need read access
>> > to /etc/krb5/krb5.conf and have the system properly configured to do NFS
>> > with krb in general (read the Solaris 10 online docs).
>> >
>> > Beyond that, whether a user kinit'ing is enough depends on which version
>> > of NFS you are using.  On the client side NFSv3 sec=krb5p shares will
>> > automount if the user triggering the mount has a krb cred in their
>> > ccache (klist will show that) and does not require any keys in the
>> > system keytab nor does it require root to have a krb cred in general.
>> >
>> > NFSv4 on the other hand does require that the root on the NFS client
>> > system have a krb cred in its ccache.  This can be done either by
>> > running kinit as root or having at least one set of keys for either the
>> > root/<host> or host/<host> service princ in the system keytab which will
>> > be automatically used to acquire a krb cred for root.
>> >
>> > On the client system "nfsstat -m" will show what version of NFS is being
>> > used.
>>
>> We are talking about NFS version 4 (NFSv4) on Solaris only. Why does
>> NFSv4 have such extra requirements?
>>
>> 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?
>
> This is not a krb problem, it's an issue with the way NFSv4 was
> implemented by many vendors including Solaris.  It's my understanding
> that many Linux distros have the same requirements.
>
> Here is some explanation about the issue sent to me by a NFS developer:
>
> "Unlike NFS3, the NFS4 protocol is stateful, and a
>  lease model is used to manage its state.
>
>  After creating state tokens, NFS4 clients must periodically
>  check-in with the NFS4 server to renew their state lease.
>  If the state lease is not renewed, the server is free to
>  expire the client’s lease and destroy its state.   This
>  is precisely what happened to your client.
>
>  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?
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?
3. Does nfsd log any errors if the state lease cannot be renewed?

>  and when the client’s keytab doesn’t contain a host svc princ,
>  kcred/root cannot be mapped to a kerberos principal.  The
>  end result is that the renew thread cannot send its OP_RENEW
>  to the server to renew its state lease."
>
> You should ask about this issue on a NFS developer mail list.

Which list is that?

Wang
--
Wang Shouhua - [hidden email]
中华人民共和国科学技术部 - HTTP://WWW.MOST.GOV.CN

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Will Fiveash-2
On Mon, Apr 14, 2014 at 08:55:10PM +0200, Wang Shouhua wrote:

> On 13 April 2014 21:59, Will Fiveash <[hidden email]> wrote:
> > On Sat, Apr 12, 2014 at 09:50:25AM +0200, Wang Shouhua wrote:
> >> On 11 April 2014 22:14, Will Fiveash <[hidden email]> wrote:
> >> > On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote:
> >> >> I am on Solaris 10U4 - can I access a NFS filesystem with (mandatory)
> >> >> krb5p authentication via the Solaris /net automounter with kinit only,
> >> >> without having r/w access to /etc/krb5.conf access)?
> >> >
> >> > You'll need to have Solaris krb configured which stores its config in
> >> > /etc/krb5 not /etc as is the MIT default.  You'll also need read access
> >> > to /etc/krb5/krb5.conf and have the system properly configured to do NFS
> >> > with krb in general (read the Solaris 10 online docs).
> >> >
> >> > Beyond that, whether a user kinit'ing is enough depends on which version
> >> > of NFS you are using.  On the client side NFSv3 sec=krb5p shares will
> >> > automount if the user triggering the mount has a krb cred in their
> >> > ccache (klist will show that) and does not require any keys in the
> >> > system keytab nor does it require root to have a krb cred in general.
> >> >
> >> > NFSv4 on the other hand does require that the root on the NFS client
> >> > system have a krb cred in its ccache.  This can be done either by
> >> > running kinit as root or having at least one set of keys for either the
> >> > root/<host> or host/<host> service princ in the system keytab which will
> >> > be automatically used to acquire a krb cred for root.
> >> >
> >> > On the client system "nfsstat -m" will show what version of NFS is being
> >> > used.
> >>
> >> We are talking about NFS version 4 (NFSv4) on Solaris only. Why does
> >> NFSv4 have such extra requirements?
> >>
> >> 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?
> >
> > This is not a krb problem, it's an issue with the way NFSv4 was
> > implemented by many vendors including Solaris.  It's my understanding
> > that many Linux distros have the same requirements.
> >
> > Here is some explanation about the issue sent to me by a NFS developer:
> >
> > "Unlike NFS3, the NFS4 protocol is stateful, and a
> >  lease model is used to manage its state.
> >
> >  After creating state tokens, NFS4 clients must periodically
> >  check-in with the NFS4 server to renew their state lease.
> >  If the state lease is not renewed, the server is free to
> >  expire the client’s lease and destroy its state.   This
> >  is precisely what happened to your client.
> >
> >  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?

On Solaris the code first looks for root/<hostname> service princ keys
in the keytab then host/<hostname> keyes.

> 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?
> 3. Does nfsd log any errors if the state lease cannot be renewed?

I don't know.  You may want to ask about that on a Oracle OTN discussion
forum (google that).

> >  and when the client’s keytab doesn’t contain a host svc princ,
> >  kcred/root cannot be mapped to a kerberos principal.  The
> >  end result is that the renew thread cannot send its OP_RENEW
> >  to the server to renew its state lease."
> >
> > You should ask about this issue on a NFS developer mail list.
>
> Which list is that?

Don't know off the top of my head as I work on Solaris krb.  If I get
the answer from a Oracle NFS developer I'll let you know.

--
Will Fiveash
Oracle Solaris Software Engineer
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Will Fiveash-2
In reply to this post by Wang Shouhua
Here is a response to your questions from a Solaris NFS developer:

> ----- Forwarded message from Wang Shouhua<[hidden email]>  -----
>
> Date: Mon, 14 Apr 2014 20:55:10 +0200
> From: Wang Shouhua<[hidden email]>
> Subject: Re: Accessing Kerberos NFS via /net automounter with kinit only (no /etc/krb5.conf access)
> To: Wang Shouhua<[hidden email]>,[hidden email], Will Fiveash<[hidden email]>
> Message-ID:<CANzOW+KG-H37=JRttBHMyA0=Yaqcc=[hidden email]>
>
> On 13 April 2014 21:59, Will Fiveash<[hidden email]>  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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos