Linux NFS development
 help / color / mirror / Atom feed
From: Jaap Winius <jwinius@umrk.nl>
To: linux-nfs@vger.kernel.org
Subject: Re: NFSv4 cross-realm support
Date: Tue, 8 Jul 2014 01:33:10 +0000 (UTC)	[thread overview]
Message-ID: <lpfhom$qku$1@ger.gmane.org> (raw)
In-Reply-To: CAHVgHyWU9B+VE=_qTEG2TVOyMHijzVTA0a2rVb_7hrjsKf7Jfw@mail.gmail.com

On Mon, 07 Jul 2014 17:24:52 -0400, Andy Adamson wrote:

> I have never used the olcAuthzRegexp. Is this used to map potentially
> multiple principal@REALM names to the same UID name/number?

Correct. AFAIK MIT Kerberos doesn't issue tickets containing additional 
authorization data, so my site stores it in an OpenLDAP DIT. Moreover, 
when OpenLDAP is used as a backend for MIT Kerberos, it does a much 
better job at database synchronization than kprop. olcAuthzRegexp is a 
regular expression that maps GSSAPI-format user names to LDAP names. For 
example:

  olcAuthzRegexp: uid=([^,]+),cn=example.com,cn=gssapi,cn=auth
    uid=$1,ou=people,dc=example,dc=com

This works great for same-realm authentication, mapping bob@EXAMPLE.COM 
to the corresponding LDAP entry in ou=people where his account metadata 
is stored, containing UID, GID, shell and home directory information.

See http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-provider.php for 
a more complete explanation.

For a cross-realm situation, that regex can be modified to map accounts 
from another trusted realm to an account with the same name in the local 
realm. However, in a bit of a twist, a foreign account, bob@EXAMPLE.NET, 
will start out with a slightly different GSSAPI format:

  uid=bob@example.net,cn=example.com,cn=gssapi,cn=auth

The aforementioned olcAuthzRegexp maps it to:

  uid=bob@example.net,ou=people,dc=example,dc=com

As a result, Bob's LDAP entry is not found, even though he is allowed to 
browse the local DIT (that just works). So, to make sure it works for 
users in the foreign realm, like Bob, who also happen to have a matching 
account in the local realm, I modified the regex to look like this:

  uid=([^,@]+)(@example.net)*,cn=example.com,cn=gssapi,cn=auth

That's one problem solved. Now what I need is for NFS to play nice. IMO, 
rpc.svcgssd should simply ask the local KDC if the foreign realm is to be 
trusted. Apparently, that's the way OpenLDAP, SSH and Dovecot IMAP do it, 
but that's not happening at the moment. So is this a bug, or what?


      reply	other threads:[~2014-07-08  1:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-02 17:42 NFSv4 cross-realm support Jaap Winius
2014-07-07 12:36 ` Andy Adamson
2014-07-07 16:23   ` Jaap Winius
2014-07-07 21:24     ` Andy Adamson
2014-07-08  1:33       ` Jaap Winius [this message]

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='lpfhom$qku$1@ger.gmane.org' \
    --to=jwinius@umrk.nl \
    --cc=linux-nfs@vger.kernel.org \
    /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