From: Hans Leidekker Subject: Re: [PATCH v3 7/7] wldap32: supply our username as SASL_CB_AUTHNAME too Message-Id: Date: Fri, 19 Feb 2021 12:19:53 +0100 In-Reply-To: <20210219140555.b3cd0008c0e419018a4ebe63@baikal.ru> References: <20210219132037.09a6b20bf83247dc5ed6f9e6@baikal.ru> <1608c3f10aec62dbf5ec7a78474e7df82fea4892.camel@codeweavers.com> <20210219134617.227c0ab1485e41533c2fe285@baikal.ru> <58ccac3e5885638a938fe45a8a017aa505f6bb95.camel@codeweavers.com> <20210219140555.b3cd0008c0e419018a4ebe63@baikal.ru> On Fri, 2021-02-19 at 14:05 +0300, Dmitry Timoshkov wrote: > Hans Leidekker 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.