NFSv4 cross-realm support

NFSv4 cross-realm support

[Jaap Winius]

Hi folks,

Recently I've been working on cross-realm support to give my own MIT 
Kerberos realm, UMRK.NL, access to the services of a realm that I manage. 
All systems involved run Debian wheezy. So far, SSH, OpenLDAP, OpenAFS 
and Dovecot IMAP are all working properly this way, but NFSv4 with 
sec=krb5i is not; I keep getting "Permission denied" when attempting to 
read or write to any file or directory that is not globally accessible.

When the log output verbosity for rpc.gssd and rpc.svcgssd is increased 
about as far as it will go (-vvvvv), little is different when things go 
wrong, other than this one line produced by rpc.svcgssd on the server:

  nss_gss_princ_to_ids: Local-Realm 'UMRK.NL': NOT FOUND

However, even that seems a bit misleading, because the log output for 
rpc.idmapd (with Verbosity = 5) shows that the user and group IDs for my 
account are being identified properly.

Should I prepare a bug report for this issue, or does cross-realm support 
for NFSv4 require something extra?

Thanks,

Jaap

Re: NFSv4 cross-realm support

[Andy Adamson]

Hi

I have a personal IETF draft that deals with some of the NFSv4 cross
realm issues. This is a good place to start.

http://datatracker.ietf.org/doc/draft-adamson-nfsv4-multi-domain-federated-fs-reqs/


On Wed, Jul 2, 2014 at 1:42 PM, Jaap Winius <jwinius@umrk.nl> wrote:
> Hi folks,
>
> Recently I've been working on cross-realm support to give my own MIT
> Kerberos realm, UMRK.NL, access to the services of a realm that I manage.
> All systems involved run Debian wheezy. So far, SSH, OpenLDAP, OpenAFS
> and Dovecot IMAP are all working properly this way, but NFSv4 with
> sec=krb5i is not; I keep getting "Permission denied" when attempting to
> read or write to any file or directory that is not globally accessible.
>
> When the log output verbosity for rpc.gssd and rpc.svcgssd is increased
> about as far as it will go (-vvvvv), little is different when things go
> wrong, other than this one line produced by rpc.svcgssd on the server:
>
>   nss_gss_princ_to_ids: Local-Realm 'UMRK.NL': NOT FOUND
>
> However, even that seems a bit misleading, because the log output for
> rpc.idmapd (with Verbosity = 5) shows that the user and group IDs for my
> account are being identified properly.
>
> Should I prepare a bug report for this issue, or does cross-realm support
> for NFSv4 require something extra?

So you are supporting two Kerberos realms under one NFSv4 domain? You
are using LDAP for id mapping?

Which version of nfs-utils and which client kernel?

e.g.

# rpm -qa | grep nfs-utils
# uname -a

-->Andy

>
> Thanks,
>
> Jaap
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFSv4 cross-realm support

[Jaap Winius]

On Mon, 07 Jul 2014 08:36:00 -0400, Andy Adamson wrote:

> So you are supporting two Kerberos realms under one NFSv4 domain?

At some point I even hope to make it three Kerberos realms under one 
NFSv4 domain, but this also depends on a cross-realm issue with Exim4 
being resolved, so for now it's just two realms under one NFSv4 domain.

> You are using LDAP for id mapping?

Yes. After tweaking the user-olcAuthzRegexp for cn=config it seems to be 
working perfectly.

> Which version of nfs-utils and which client kernel?

I'm using Debian wheezy (stable), which comes with with nfs-common 
1.2.6-4 and kernel 3.2.0-4-amd64.

Cheers,

Jaap

Re: NFSv4 cross-realm support

[Andy Adamson]

On Mon, Jul 7, 2014 at 12:23 PM, Jaap Winius <jwinius@umrk.nl> wrote:
> On Mon, 07 Jul 2014 08:36:00 -0400, Andy Adamson wrote:
>
>> So you are supporting two Kerberos realms under one NFSv4 domain?
>
> At some point I even hope to make it three Kerberos realms under one
> NFSv4 domain, but this also depends on a cross-realm issue with Exim4
> being resolved, so for now it's just two realms under one NFSv4 domain.
>
>> You are using LDAP for id mapping?
>
> Yes. After tweaking the user-olcAuthzRegexp for cn=config it seems to be
> working perfectly.

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

-->Andy

>
>> Which version of nfs-utils and which client kernel?
>
> I'm using Debian wheezy (stable), which comes with with nfs-common
> 1.2.6-4 and kernel 3.2.0-4-amd64.
>
> Cheers,
>
> Jaap
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFSv4 cross-realm support

[Jaap Winius]

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?