[PATCH] wldap32: log in with the authentication name instead of the authorization name
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(-)
Damjan Jovanovic <damjan.jov(a)gmail.com> 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. -- Dmitry.
On Wed, 2021-01-27 at 19:22 +0300, Dmitry Timoshkov wrote: Damjan Jovanovic <damjan.jov(a)gmail.com> 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.
On Wed, 2021-01-27 at 19:22 +0300, Dmitry Timoshkov wrote:
Damjan Jovanovic <damjan.jov(a)gmail.com> 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.
Hans Leidekker <hans(a)codeweavers.com> wrote:
On Wed, 2021-01-27 at 19:22 +0300, Dmitry Timoshkov wrote:
Damjan Jovanovic <damjan.jov(a)gmail.com> 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. -- Dmitry.
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.
participants (3)
-
Damjan Jovanovic -
Dmitry Timoshkov -
Hans Leidekker