Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

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

Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Wang Shouhua
Lets recap:

1. Requirements:
- Linux or Solaris
- NFS automounter set up at /net
- Kerberos5 configured for realm EXAMPLE2.COM, rpc.gssd running
- A NFS server (version 4 only) nfsserver.most.gov.cn exists in the
realm MOST.GOV.CN, with a subdir of test3

2. Goal:
A user provides his password to obtain a ticket for [hidden email]
(optionally [hidden email], if this is a requirement to do a mount),
and is then able to cd into /net/nfsserver.most.gov.cn/test3, and do a
successful ls -al there

Is that possible?

Wang

---------- Forwarded message ----------
From: Will Fiveash <[hidden email]>
Date: 11 April 2014 22:14
Subject: Re: Accessing Kerberos NFS via /net automounter with kinit
only (no /etc/krb5.conf access)
To: Wang Shouhua <[hidden email]>
Cc: [hidden email]


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


--
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 version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Will Fiveash-2
On Sat, Apr 12, 2014 at 11:24:28AM +0200, Wang Shouhua wrote:

> Lets recap:
>
> 1. Requirements:
> - Linux or Solaris
> - NFS automounter set up at /net
> - Kerberos5 configured for realm EXAMPLE2.COM, rpc.gssd running
> - A NFS server (version 4 only) nfsserver.most.gov.cn exists in the
> realm MOST.GOV.CN, with a subdir of test3
>
> 2. Goal:
> A user provides his password to obtain a ticket for [hidden email]
> (optionally [hidden email], if this is a requirement to do a mount),
> and is then able to cd into /net/nfsserver.most.gov.cn/test3, and do a
> successful ls -al there
>
> Is that possible?

I don't think so.  If the NFS client is only configured for realm
EXAMPLE2.COM, how will a user get a nfs service ticket for the
MOST.GOV.CN realm?  The NFS client will need to be configured for
crossrealm operation in order for a user to get that service ticket once
they user has their krb TGT credential for EXAMPLE2.COM.

Second, how is the NFS server in MOST.GOV.CN going to map a principal in
EXAMPLE2.COM to a local user ID?  This will require some form of
'auth_to_local*' mapping configuration on the NFS server side in
/etc/krb5/krb5.conf.

You may want to ask for more info on this on the Oracle OTN discussion
forums, read the Solaris 10 online documentation or check with your
Oracle support person.

--
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 version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Nico Williams
Will,

Mobile devices don't really have stable hostnames, so the system
should support non-hostbased host/root credentials.

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

Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Simo Sorce-3
On Tue, 2014-04-15 at 11:36 -0500, Nico Williams wrote:
> Will,
>
> Mobile devices don't really have stable hostnames, so the system
> should support non-hostbased host/root credentials.

The hostname is pretty stable, unless you allow dhcp to push an hostname
unto you (bad idea).
I think what you mean is that not all mobile devices can use dyndns to
update the name -> ip map, but this shouldn't be a problem in the NFS
case.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

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

Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Will Fiveash-2
In reply to this post by Nico Williams
On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote:
> Will,
>
> Mobile devices don't really have stable hostnames, so the system
> should support non-hostbased host/root credentials.

If you are referring to the NFS v4 client requiring root have a krb cred
in order to function as I described in an earlier e-mail I would ask why
NFS v4 clients require root to have a krb cred in the first place (NFS
v3 doesn't as you may recall)?  As you can imagine, many IT departments
would balk (putting it mildly) if they were asked to provision keytabs
on laptops or other mobile devices that need access to krb protected NFS
v4 shares.

As to how that requirement happened, according to one of the NFSv4
developers here that regularly attends Connectathon, the consensus among
the NFS v4 implementors for various Linux platforms was that a properly
configured NFS v4 client meant it had a keytab containing host service
princ keys which could then be leveraged to protect the lease renewal
traffic.  My opinion is that unless there is a very good reason to
protect that traffic, krb protection for lease renewal traffic should be
optional, depending on configuration.

--
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 version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Simo Sorce-3
On Tue, 2014-04-15 at 13:48 -0500, Will Fiveash wrote:

> On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote:
> > Will,
> >
> > Mobile devices don't really have stable hostnames, so the system
> > should support non-hostbased host/root credentials.
>
> If you are referring to the NFS v4 client requiring root have a krb cred
> in order to function as I described in an earlier e-mail I would ask why
> NFS v4 clients require root to have a krb cred in the first place (NFS
> v3 doesn't as you may recall)?  As you can imagine, many IT departments
> would balk (putting it mildly) if they were asked to provision keytabs
> on laptops or other mobile devices that need access to krb protected NFS
> v4 shares.
>
> As to how that requirement happened, according to one of the NFSv4
> developers here that regularly attends Connectathon, the consensus among
> the NFS v4 implementors for various Linux platforms was that a properly
> configured NFS v4 client meant it had a keytab containing host service
> princ keys which could then be leveraged to protect the lease renewal
> traffic.  My opinion is that unless there is a very good reason to
> protect that traffic, krb protection for lease renewal traffic should be
> optional, depending on configuration.


There is a good reason to require a keytab on a client if you use
kerberos for authentication to the machine, and that is that you need
validation for login.

You also need a host key if you want to allow to use gssapi
authentication for ssh.

So it is not too far fetched to expect to find a host key on every
machine participating to a kerberos REALM.

That said it is unclear to me why the NFSv4 server should try to use a
new channel to communicate with the client instead of just using the
existing channel the client opened against the server.

Opening back channels from servers have been proven brittle (firewalls,
NAT, etc.. all get in the way) time and again since ages, seem someone
hasn't learned their lesson.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

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

Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Nico Williams
In reply to this post by Simo Sorce-3
On Tue, Apr 15, 2014 at 11:54 AM, Simo Sorce <[hidden email]> wrote:

> On Tue, 2014-04-15 at 11:36 -0500, Nico Williams wrote:
>> Will,
>>
>> Mobile devices don't really have stable hostnames, so the system
>> should support non-hostbased host/root credentials.
>
> The hostname is pretty stable, unless you allow dhcp to push an hostname
> unto you (bad idea).
> I think what you mean is that not all mobile devices can use dyndns to
> update the name -> ip map, but this shouldn't be a problem in the NFS
> case.

Sure.  But there's no need for the client to have any particular sort
of name for itself, so why pretend that it's name is host-based?

(For the share -o root=... option Solaris really wants a root/hostname
credential that it then checks against the reverse lookup on the
client IP address.  I'm not too hot on this, but at least that's only
for root-equivalent access, not for general access.)

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

Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Nico Williams
In reply to this post by Will Fiveash-2
There is nothing in NFSv4 requiring the use of any sort of client
credentials other than user credentials.  However, for multi-user
clients it's important to have a credential for some session state and
for callbacks.

For single-user clients there's no need to have any device credentials
at all for NFSv4 -- if you have none then the device should use the
one user's credentials for all NFSv4 purposes.

That said, it's best practice to key all devices.  Still, nothing in
NFSv4 requires such keys to be named in host-based ways.

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

Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Will Fiveash-2
In reply to this post by Simo Sorce-3
On Tue, Apr 15, 2014 at 03:13:09PM -0400, Simo Sorce wrote:

> On Tue, 2014-04-15 at 13:48 -0500, Will Fiveash wrote:
> > On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote:
> > > Will,
> > >
> > > Mobile devices don't really have stable hostnames, so the system
> > > should support non-hostbased host/root credentials.
> >
> > If you are referring to the NFS v4 client requiring root have a krb cred
> > in order to function as I described in an earlier e-mail I would ask why
> > NFS v4 clients require root to have a krb cred in the first place (NFS
> > v3 doesn't as you may recall)?  As you can imagine, many IT departments
> > would balk (putting it mildly) if they were asked to provision keytabs
> > on laptops or other mobile devices that need access to krb protected NFS
> > v4 shares.
> >
> > As to how that requirement happened, according to one of the NFSv4
> > developers here that regularly attends Connectathon, the consensus among
> > the NFS v4 implementors for various Linux platforms was that a properly
> > configured NFS v4 client meant it had a keytab containing host service
> > princ keys which could then be leveraged to protect the lease renewal
> > traffic.  My opinion is that unless there is a very good reason to
> > protect that traffic, krb protection for lease renewal traffic should be
> > optional, depending on configuration.
>
>
> There is a good reason to require a keytab on a client if you use
> kerberos for authentication to the machine, and that is that you need
> validation for login.
>
> You also need a host key if you want to allow to use gssapi
> authentication for ssh.
>
> So it is not too far fetched to expect to find a host key on every
> machine participating to a kerberos REALM.

But if this is a work laptop, which is typically a single user system
and operates as a client in various contexts, requiring IT provision it
with a keytab seems onerous to me.  Note that a Solaris NFS v3 client
does not require root have a krb cred to operation, even when
automounting -- it only requires the user that triggered the automount
have a krb cred.

> That said it is unclear to me why the NFSv4 server should try to use a
> new channel to communicate with the client instead of just using the
> existing channel the client opened against the server.

I think part of the problem is that the gss security context protecting
the channel along with the user's krb cred could expire at any time.  I
think that's why they wanted root to use a key stored in the keytab (I
could be wrong of course).

--
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 version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Nico Williams
On Tue, Apr 15, 2014 at 2:22 PM, Will Fiveash <[hidden email]> wrote:
> But if this is a work laptop, which is typically a single user system
> and operates as a client in various contexts, requiring IT provision it
> with a keytab seems onerous to me.  Note that a Solaris NFS v3 client
> does not require root have a krb cred to operation, even when
> automounting -- it only requires the user that triggered the automount
> have a krb cred.

What should happen is that there should be a way to enroll a device.

That could be as simple as a kadm5 (or HTTP, or RFC3244 extension) API
that allows a user to create and key a principal of a form such as
device/<username>/<random>@<REALM> or just device/<random>@<REALM>.
The <random> should have no periods and should be illegal as a
hostname, and it should mostly be a base64 encoding of a few bytes of
/dev/urandom output.

(Roland's tools have a mechanism for joining a host to a realm using
multi-party ECDH to key it, and a site-local procedure for "blessing"
a host principal.  A similar but simplified approach could work here.)

> I think part of the problem is that the gss security context protecting
> the channel along with the user's krb cred could expire at any time.  I
> think that's why they wanted root to use a key stored in the keytab (I
> could be wrong of course).

No, that is a problem.  NFSv4.1 does something to address this, IIRC,
though I forget the details.

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

Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Tomas Kuthan
In reply to this post by Nico Williams
On 04/15/14 21:16, Nico Williams wrote:
> That said, it's best practice to key all devices.  Still, nothing in
> NFSv4 requires such keys to be named in host-based ways.

Makes sense ... but still, basing on host is a nifty way of constructing
unique principal name. Is there a meaningful alternative for mobile devices?

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

Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Nico Williams
On Tue, Apr 15, 2014 at 2:48 PM, Tomas Kuthan <[hidden email]> wrote:
> On 04/15/14 21:16, Nico Williams wrote:
>> That said, it's best practice to key all devices.  Still, nothing in
>> NFSv4 requires such keys to be named in host-based ways.
>
> Makes sense ... but still, basing on host is a nifty way of constructing
> unique principal name. Is there a meaningful alternative for mobile devices?

But it isn't nifty.  You quickly run into the issue that the hostname
has to have a record in whatever manages your DNS zones, else someone
might use that hostname and now some device has keys for its
principal.

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

Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Will Fiveash-2
In reply to this post by Nico Williams
On Tue, Apr 15, 2014 at 02:34:11PM -0500, Nico Williams wrote:
> On Tue, Apr 15, 2014 at 2:22 PM, Will Fiveash <[hidden email]> wrote:
> > But if this is a work laptop, which is typically a single user system
> > and operates as a client in various contexts, requiring IT provision it
> > with a keytab seems onerous to me.  Note that a Solaris NFS v3 client
> > does not require root have a krb cred to operation, even when
> > automounting -- it only requires the user that triggered the automount
> > have a krb cred.
>
> What should happen is that there should be a way to enroll a device.

If a keytab is really needed.  On the otherhand, if a laptop is only
acting as a client then why bother?  Assuming the logged-in user has a
way of acquiring their krb cred that's all they should need if the
laptop is acting as a NFS, ssh or any other client that tries to do
gss/krb auth.

--
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 version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Nico Williams
On Tue, Apr 15, 2014 at 4:48 PM, Will Fiveash <[hidden email]> wrote:
> On Tue, Apr 15, 2014 at 02:34:11PM -0500, Nico Williams wrote:
>> What should happen is that there should be a way to enroll a device.
>
> If a keytab is really needed.  On the otherhand, if a laptop is only
> acting as a client then why bother?  Assuming the logged-in user has a
> way of acquiring their krb cred that's all they should need if the
> laptop is acting as a NFS, ssh or any other client that tries to do
> gss/krb auth.

Sure, that's a fair thing to do in the short-term.  In the long term I
suspect you'll have many reasons to want to enroll a device (e.g., to
do FAST w/o PKINIT).

And in order to make this short-term fix workable you need a way to
configure the system to make the user's Kerberos credential also be
the system's (root's).
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos