[PATCH v3 7/7] wldap32: supply our username as SASL_CB_AUTHNAME too
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. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50572 Signed-off-by: Damjan Jovanovic <damjan.jov(a)gmail.com> --- dlls/wldap32/bind.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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.
Hans Leidekker <hans(a)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? -- Dmitry.
On Fri, 2021-02-19 at 13:20 +0300, Dmitry Timoshkov wrote:
Hans Leidekker <hans(a)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
Hans Leidekker <hans(a)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. -- Dmitry.
On Fri, 2021-02-19 at 13:46 +0300, Dmitry Timoshkov wrote:
Hans Leidekker <hans(a)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 SASL_CB_USER supplies the user acting for, SASL_CB_AUTHNAME supplies the authenticating user.
Hans Leidekker <hans(a)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 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.
-- Dmitry.
On Fri, 2021-02-19 at 14:05 +0300, Dmitry Timoshkov wrote:
Hans Leidekker <hans(a)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.
participants (3)
-
Damjan Jovanovic -
Dmitry Timoshkov -
Hans Leidekker