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

[Dmitry Timoshkov]

Damjan Jovanovic <damjan.jov at gmail.com> wrote:

> On Mon, Feb 8, 2021 at 11:35 AM Dmitry Timoshkov <dmitry at baikal.ru> wrote:
> 
> > Hans Leidekker <hans at codeweavers.com> wrote:
> >
> > > > Hans Leidekker <hans at codeweavers.com> wrote:
> > > >
> > > > > > > -        else if (sasl->id == SASL_CB_USER)
> > > > > > > +        else if (sasl->id == SASL_CB_AUTHNAME)
> > > > > > >          {
> > > > > > >              sasl->result = id->User;
> > > > > > >              sasl->len = id->UserLength;
> > > > > >
> > > > > > https://bugs.winehq.org/show_bug.cgi?id=50545#c23
> > > > >
> > > > > That comment is not entirely correct. In my testing GSSAPI does
> > invoke
> > > > > this callback but fails if it returns a result.
> > > >
> > > > It works here with my username and a Kerberos ticket (0x4001 -
> > SASL_CB_USER):
> > > >
> > > > 0024:trace:adsldp:openobj_OpenDSObject
> > 0019975C,L"LDAP://xxx.yyy.zzz/rootDSE",L"user",001997FC,00000021,0031C1E0
> > > > 0024:trace:adsldp:openobj_OpenDSObject host L"xxx.yyy.zzz", port 0,
> > object L"rootDSE"
> > > > 0024:trace:wldap32:ldap_initW (L"xxx.yyy.zzz", 0)
> > > > 0024:trace:wldap32:ldap_set_optionW (0x19a5a8, 0x00000011, 0x31bd60)
> > > > 0024:trace:wldap32:ldap_connect (0x19a5a8, (nil))
> > > > 0024:trace:wldap32:ldap_bind_sW (0x19a5a8, (null), 0x31bd70,
> > 0x00000486)
> > > > 0024:trace:wldap32:sasl_interact
> > 0x7d78f320,00000002,0x31bbd8,0x7d792600
> > > > 0024:trace:wldap32:sasl_interact sasl->id = 4001
> > > > 0024:trace:wldap32:ldap_search_sW (0x19a5a8, (null), 0x00000000,
> > L"(objectClass=*)", 0x31bd28, 0x00000000, 0x31bd14)
> > > > 0024:trace:wldap32:WLDAP32_ldap_first_entry (0x19a5a8, 0x7d784d00)
> > > > 0024:trace:wldap32:ldap_get_valuesW (0x19a5a8, 0x7d784d00,
> > L"subschemaSubentry")
> > >
> > > And it fails with Damjan's patch?
> >
> > With Damjan's patch it fails on the first run, after renewing the Kerberos
> > ticket it works. I have to note, that the Kerberos ticket was valid and
> > functional before renewing.
> >
> >
> What about if you return id->User on both SASL_CB_USER and SASL_CB_AUTHNAME?

As could be seen in the trace snippet above the callback is not called
with SASL_CB_AUTHNAME.

-- 
Dmitry.