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
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
