From: Simo Sorce <simo@redhat.com>
To: Jurjen Bokma <j.bokma@rug.nl>
Cc: Cedric Blancher <cedric.blancher@gmail.com>,
"<kerberos@mit.edu>" <kerberos@mit.edu>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Steve Dickson <steved@redhat.com>
Subject: Re: How to use NFS with multiple principals in different realms?
Date: Thu, 04 Sep 2014 14:35:58 -0400 [thread overview]
Message-ID: <1409855758.8703.48.camel@willson.usersys.redhat.com> (raw)
In-Reply-To: <54085BF3.60802@rug.nl>
On Thu, 2014-09-04 at 14:32 +0200, Jurjen Bokma wrote:
> On 09/04/2014 01:25 PM, Cedric Blancher wrote:
> > On 4 September 2014 11:33, Jurjen Bokma <j.bokma@rug.nl> wrote:
> >> You use cross realm authentication, so that your NFS client may obtain
> >> tickets for servers that are not in its own realm.
> >
> > What if I cannot use cross realm authentication? For example if both
> > realms do not like each other?
> > What if I really have to kinit into multiple realms? Kerberos since
> > 1.10 can do that and klist now has a new flag -A to list all entries
> > if KRB5CCNAME points to a directory, e.g.
> > KRB5CCNAME=DIR:/tmp/krbcc$UID/
> >
> > Ced
> >
> I tried that about a year ago, and failed to make it work.
The problem is that the server can only have one set of credentials from
the POV of the client, and that's: nfs@fqdn (a GSSAPI name), that gets
converted into a principal of the form nfs/fqdn@REALM (where REALM is
determined by a mapping of the form domain_name->REALM in the client
usually).
> As far as I know, gssd always picks the same key to authenticate with. I
When rpc.gssd (potentially interposed by gss-proxy) then uses GSSAPI to
obtain a ticket for the server it will choose the credentials that match
the same REALM in preference, even if you have multiple credentials.
The client has no way to know that you want to use a different set of
credentials, because it doesn't even know (IIRC) what you are trying to
access on the server when this call is made.
> did offer a patch on this list a couple of weeks ago that uses a
> krb5.conf appdefaults option to configure *which* key, but that one
> still doesn't make it possible to pick a different key for different shares.
It allows you to choose a different key for the *machine* principal, but
does nothing for authenticating users using different credentials.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
next prev parent reply other threads:[~2014-09-04 18:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 9:04 How to use NFS with multiple principals in different realms? Cedric Blancher
2014-09-04 9:33 ` Jurjen Bokma
2014-09-04 11:25 ` Cedric Blancher
2014-09-04 12:32 ` Jurjen Bokma
2014-09-04 18:35 ` Simo Sorce [this message]
2014-09-10 0:31 ` Cedric Blancher
2014-09-10 2:18 ` Nordgren, Bryce L -FS
2014-09-10 6:47 ` Trond Myklebust
2014-09-10 13:06 ` Simo Sorce
2014-09-17 11:20 ` Cedric Blancher
2014-09-17 15:05 ` Simo Sorce
2014-09-17 20:30 ` Cedric Blancher
2014-09-17 21:31 ` Simo Sorce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1409855758.8703.48.camel@willson.usersys.redhat.com \
--to=simo@redhat.com \
--cc=cedric.blancher@gmail.com \
--cc=j.bokma@rug.nl \
--cc=kerberos@mit.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=steved@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).