[PATCH v3 7/7] wldap32: supply our username as SASL_CB_AUTHNAME too

[Hans Leidekker]

On Fri, 2021-02-19 at 14:05 +0300, Dmitry Timoshkov wrote:
> Hans Leidekker <hans at codeweavers.com> wrote:
> 
> > > > > > On Thu, 2021-02-18 at 18:50 +0200, Damjan Jovanovic wrote:
> > > > > > > Try 3 gives up the attempt to provide credentials in an
> > > > > > > authentication method specific form, and just provides our
> > > > > > > username as the authentication username (SASL_CB_AUTHNAME) too.
> > > > > > 
> > > > > > It doesn't work here. This clearly depends on the mechanism used,
> > > > > > so I think the previous approach was better.
> > > > > 
> > > > > Could you provide more details? What doesn't work? What kind of
> > > > > authentication method and LDAP server are you using? Does adding
> > > > > KRB5_TRACE reveal anything?
> > > > 
> > > > GSSAPI and standard AD server. More details here:
> > > > https://www.winehq.org/pipermail/wine-devel/2021-January/179973.html
> > > 
> > > How did it work before? Not providing user name on SASL_CB_USER is clearly
> > > wrong.
> > 
> > It didn't work before. It's not wrong to provide an empty username for
> > SASL_CB_USER because it's only used in proxy authentication schemes.
> > See https://www.cyrusimap.org/sasl/sasl/developer/programming.html
> 
> It says nothing about SASL_CB_USER being only used in proxy authentication
> schemes.

SASL_CB_USER is defined there as 'the name of the user acting for'.

> > SASL_CB_USER supplies the user acting for, SASL_CB_AUTHNAME supplies
> > the authenticating user.
> 
> As I mentioned before and showed in the trace here I get only SASL_CB_USER
> with Kerberos and AD Samba server, and providing user name works just fine.
> From the Damjan's patch series description I get that adding SASL_CB_AUTHNAME
> to the SASL_CB_USER handler works for him, probably you need to investigate
> why it doesn't work on your side.

Damjan said he tested DIGEST-MD5, which behaves differently with
respect to SASL_CB_USER.