Hi,
I recently tried using gssproxy for krb5 authentication with nfsd.
This was because customer is using an AD kerberos master which uses
certificates which are too big for svcgssd to work with (i.e. larger
than one page).
Unfortunately it doesn't work.
The svcgssd code in nfs-utils calls
gss_display_name()
to get the name of the principal. This returns something like
"user@domain".
getpwnam() works perfectly on this (when nsswitch is set to use "winbind")
but svcgssd goes further and uses nfs4_gss_princ_to_ids() to perform
the lookup. Presumably this is more general?
gssproxy does neither of these.
It uses gss_localname() to get the user name, which returns something
like "user".
It then calls getpwnam() on that, which fails ("user@domain" or
"domain\user" both succeed).
I have modified my copy to use gss_display_name() instead of
gss_localname() and it now appears to work perfectly ... for this
use-case at least.
What is the right way forward here?
Is nfs4_gss_princ_to_ids() really necessary?
Should gssproxy use it, at least for requests from the NFS server?
Is there are good reason not to use gss_display_name() uniformly?
Maybe use gss_local_name(), and it that fails, or getpwnam fails,
use gss_display_name()??
Thanks,
NeilBrown
Hi Neil,
On Wed, 08 Mar 2017, NeilBrown wrote:
>
> Hi,
> I recently tried using gssproxy for krb5 authentication with nfsd.
> This was because customer is using an AD kerberos master which uses
> certificates which are too big for svcgssd to work with (i.e. larger
> than one page).
>
> Unfortunately it doesn't work.
>
> The svcgssd code in nfs-utils calls
> gss_display_name()
> to get the name of the principal. This returns something like
> "user@domain".
>
> getpwnam() works perfectly on this (when nsswitch is set to use "winbind")
> but svcgssd goes further and uses nfs4_gss_princ_to_ids() to perform
> the lookup. Presumably this is more general?
>
> gssproxy does neither of these.
> It uses gss_localname() to get the user name, which returns something
> like "user".
Are using SSSD by any chance? I had a similar issue in RHEL maybe a
year ago. If you're using SSSD there's a localauth plugin that needs to
be enabled that will cause krb5_aname_to_localname() (which is called by
gss_localname()) to return a fully-qualified username instead of the
short username.
-Scott
> It then calls getpwnam() on that, which fails ("user@domain" or
> "domain\user" both succeed).
>
> I have modified my copy to use gss_display_name() instead of
> gss_localname() and it now appears to work perfectly ... for this
> use-case at least.
>
> What is the right way forward here?
> Is nfs4_gss_princ_to_ids() really necessary?
> Should gssproxy use it, at least for requests from the NFS server?
> Is there are good reason not to use gss_display_name() uniformly?
> Maybe use gss_local_name(), and it that fails, or getpwnam fails,
> use gss_display_name()??
>
> Thanks,
> NeilBrown
On Wed, 08 Mar 2017, Scott Mayhew wrote:
> Hi Neil,
>
> On Wed, 08 Mar 2017, NeilBrown wrote:
>
> >
> > Hi,
> > I recently tried using gssproxy for krb5 authentication with nfsd.
> > This was because customer is using an AD kerberos master which uses
> > certificates which are too big for svcgssd to work with (i.e. larger
> > than one page).
> >
> > Unfortunately it doesn't work.
> >
> > The svcgssd code in nfs-utils calls
> > gss_display_name()
> > to get the name of the principal. This returns something like
> > "user@domain".
> >
> > getpwnam() works perfectly on this (when nsswitch is set to use "winbind")
> > but svcgssd goes further and uses nfs4_gss_princ_to_ids() to perform
> > the lookup. Presumably this is more general?
> >
> > gssproxy does neither of these.
> > It uses gss_localname() to get the user name, which returns something
> > like "user".
>
> Are using SSSD by any chance? I had a similar issue in RHEL maybe a
> year ago. If you're using SSSD there's a localauth plugin that needs to
> be enabled that will cause krb5_aname_to_localname() (which is called by
> gss_localname()) to return a fully-qualified username instead of the
> short username.
Err, never mind... I see up above that you said you were using
Winbind...
>
> -Scott
>
> > It then calls getpwnam() on that, which fails ("user@domain" or
> > "domain\user" both succeed).
> >
> > I have modified my copy to use gss_display_name() instead of
> > gss_localname() and it now appears to work perfectly ... for this
> > use-case at least.
> >
> > What is the right way forward here?
> > Is nfs4_gss_princ_to_ids() really necessary?
> > Should gssproxy use it, at least for requests from the NFS server?
> > Is there are good reason not to use gss_display_name() uniformly?
> > Maybe use gss_local_name(), and it that fails, or getpwnam fails,
> > use gss_display_name()??
> >
> > Thanks,
> > NeilBrown
>
>
On Wed, 2017-03-08 at 10:14 +1100, NeilBrown wrote:
> Hi,
> I recently tried using gssproxy for krb5 authentication with nfsd.
> This was because customer is using an AD kerberos master which uses
> certificates which are too big for svcgssd to work with (i.e. larger
> than one page).
>
> Unfortunately it doesn't work.
>
> The svcgssd code in nfs-utils calls
> gss_display_name()
> to get the name of the principal. This returns something like
> "user@domain".
>
> getpwnam() works perfectly on this (when nsswitch is set to use
> "winbind")
> but svcgssd goes further and uses nfs4_gss_princ_to_ids() to perform
> the lookup. Presumably this is more general?
>
> gssproxy does neither of these.
> It uses gss_localname() to get the user name, which returns
> something
> like "user".
> It then calls getpwnam() on that, which fails ("user@domain" or
> "domain\user" both succeed).
>
> I have modified my copy to use gss_display_name() instead of
> gss_localname() and it now appears to work perfectly ... for this
> use-case at least.
>
> What is the right way forward here?
> Is nfs4_gss_princ_to_ids() really necessary?
> Should gssproxy use it, at least for requests from the NFS server?
> Is there are good reason not to use gss_display_name() uniformly?
> Maybe use gss_local_name(), and it that fails, or getpwnam fails,
> use gss_display_name()??
No, you should configure krb5.conf to map to a fully qualified name if
that is what you normally want.
The default rule allows mapping only for the default realm and does so
by truncating away the realm name, but you can configure your own.
see auth_to_local_names directive in krb5.conf
Simo.
On Wed, Mar 08 2017, Simo Sorce wrote:
> On Wed, 2017-03-08 at 10:14 +1100, NeilBrown wrote:
>> Hi,
>> I recently tried using gssproxy for krb5 authentication with nfsd.
>> This was because customer is using an AD kerberos master which uses
>> certificates which are too big for svcgssd to work with (i.e. larger
>> than one page).
>>
>> Unfortunately it doesn't work.
>>
>> The svcgssd code in nfs-utils calls
>> gss_display_name()
>> to get the name of the principal. This returns something like
>> "user@domain".
>>
>> getpwnam() works perfectly on this (when nsswitch is set to use
>> "winbind")
>> but svcgssd goes further and uses nfs4_gss_princ_to_ids() to perform
>> the lookup. Presumably this is more general?
>>
>> gssproxy does neither of these.
>> It uses gss_localname() to get the user name, which returns
>> something
>> like "user".
>> It then calls getpwnam() on that, which fails ("user@domain" or
>> "domain\user" both succeed).
>>
>> I have modified my copy to use gss_display_name() instead of
>> gss_localname() and it now appears to work perfectly ... for this
>> use-case at least.
>>
>> What is the right way forward here?
>> Is nfs4_gss_princ_to_ids() really necessary?
>> Should gssproxy use it, at least for requests from the NFS server?
>> Is there are good reason not to use gss_display_name() uniformly?
>> Maybe use gss_local_name(), and it that fails, or getpwnam fails,
>> use gss_display_name()??
>
> No, you should configure krb5.conf to map to a fully qualified name if
> that is what you normally want.
>
> The default rule allows mapping only for the default realm and does so
> by truncating away the realm name, but you can configure your own.
>
> see auth_to_local_names directive in krb5.conf
Ah-ha. Thanks so much.
I added
auth_to_local = RULE:[1:$1@$0]
to krb5.conf, and now it works as expected.
Thanks,
NeilBrown
>
> Simo.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html