On Wed, 08 Mar 2017, Scott Mayhew wrote:
On Wed, 08 Mar 2017, NeilBrown wrote:
> 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
> to get the name of the principal. This returns something like
> getpwnam() works perfectly on this (when nsswitch is set to use
> 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
Err, never mind... I see up above that you said you were using
> > 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