[PATCH] wldap32: log in with the authentication name instead of the authorization name

[Damjan Jovanovic]

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50572
Signed-off-by: Damjan Jovanovic 
---
 dlls/wldap32/bind.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[Dmitry Timoshkov]

Damjan Jovanovic  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.

[Hans Leidekker]

On Wed, 2021-01-27 at 19:22 +0300, Dmitry Timoshkov wrote:
Damjan Jovanovic  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.

[Hans Leidekker]

On Wed, 2021-01-27 at 19:22 +0300, Dmitry Timoshkov wrote:
> Damjan Jovanovic  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.

[Dmitry Timoshkov]

Hans Leidekker  wrote:
> On Wed, 2021-01-27 at 19:22 +0300, Dmitry Timoshkov wrote:
> > Damjan Jovanovic  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.

[Hans Leidekker]

> > 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.

Here it's the other way around. Without the patch:

0024:trace:adsldp:openobj_OpenDSObject host L"win-sk40a5tr70v.test.local", port 0, object L"rootDSE"
0024:trace:wldap32:ldap_initW (L"win-sk40a5tr70v.test.local", 0)
0024:trace:wldap32:ldap_set_optionW (0x1a4550, 0x00000011, 0x31b980)
0024:trace:wldap32:ldap_connect (0x1a4550, (nil))
0024:trace:wldap32:ldap_bind_sW (0x1a4550, (null), 0x31b984, 0x00000486)
0024:trace:wldap32:sasl_interact 0x7d694cc0,00000002,0x31b8b8,0x7d68a6b0
0024:trace:wldap32:sasl_interact sasl->id = 4001
0024:trace:adsldp:openobj_OpenDSObject ldap_bind_sW error 0x31
0024:trace:wldap32:WLDAP32_ldap_unbind (0x1a4550)

With the patch:

0024:trace:adsldp:openobj_OpenDSObject host L"win-sk40a5tr70v.test.local", port 0, object L"rootDSE"
0024:trace:wldap32:ldap_initW (L"win-sk40a5tr70v.test.local", 0)
0024:trace:wldap32:ldap_set_optionW (0x1a4588, 0x00000011, 0x31b980)
0024:trace:wldap32:ldap_connect (0x1a4588, (nil))
0024:trace:wldap32:ldap_bind_sW (0x1a4588, (null), 0x31b984, 0x00000486)
0024:trace:wldap32:sasl_interact 0x7d382980,00000002,0x31b8b8,0x7d378370
0024:trace:wldap32:sasl_interact sasl->id = 4001
0024:trace:wldap32:sasl_interact 0x7d382980,00000002,0x31b8b8,0x7d37ceb0
0024:trace:wldap32:sasl_interact sasl->id = 4001
0024:trace:wldap32:ldap_search_sW (0x1a4588, (null), 0x00000000, L"(objectClass=*)", 0x31b8f0, 0x00000000, 0x31b8e8)

Same results if I force it to use GSSAPI.