[PATCH] wldap32: log in with the authentication name instead of the authorization name
Dmitry Timoshkov
dmitry at baikal.ru
Fri Jan 29 04:11:09 CST 2021
Hans Leidekker <hans at codeweavers.com> wrote:
> On Wed, 2021-01-27 at 19:22 +0300, Dmitry Timoshkov wrote:
> > Damjan Jovanovic <damjan.jov at gmail.com> wrote:
> >
> > > diff --git a/dlls/wldap32/bind.c b/dlls/wldap32/bind.c
> > > index 1498dc49fe6..d9132d99793 100644
> > > --- a/dlls/wldap32/bind.c
> > > +++ b/dlls/wldap32/bind.c
> > > @@ -198,7 +198,7 @@ static int sasl_interact( LDAP *ld, unsigned
> > > flags, void *defaults, void *intera
> > > sasl->result = id->Domain;
> > > sasl->len = id->DomainLength;
> > > }
> > > - else if (sasl->id == SASL_CB_USER)
> > > + else if (sasl->id == SASL_CB_AUTHNAME)
> > > {
> > > sasl->result = id->User;
> > > sasl->len = id->UserLength;
> >
> > At the time I wrote this code I also tested it, and the callback was
> > called with SASL_CB_USER. Perhaps it depends on something else, I'd
> > suggest to use both IDs to return user name instead of preferring one
> > to another.
>
> SASL_CB_USER is called (at least for the mechanisms I tested: GSSAPI
> and GSS-SPNEGO), but they depend on the callback returning an error.
> SASL_CB_USER is documented to specify a proxy username, which is only
> supported by the PLAIN mechanism AFAICT.
>
> So I think Damjan's patch is correct.
The patch would definitely break the Kerberos authentication via GSSAPI,
as I mentioned already I tested this when I wrote the code, and with GSSAPI
SASL backend I got SASL_CB_USER in the callback, and returning failure from
the callback breaks the AD authentication.
--
Dmitry.
More information about the wine-devel
mailing list