[PATCH 6/6] wldap32: log in with the authentication name instead of the authorization name
Resend of https://source.winehq.org/patches/data/198804 My continued testing and Hans's tests show this patch to be correct. Those that disagree (Dmitry?), please retest and submit results on the bug report? 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:
Resend of https://source.winehq.org/patches/data/198804 My continued testing and Hans's tests show this patch to be correct. Those that disagree (Dmitry?), please retest and submit results on the bug report?
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(-)
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;
https://bugs.winehq.org/show_bug.cgi?id=50545#c23 -- Dmitry.
On Sun, 2021-02-07 at 22:17 +0300, Dmitry Timoshkov wrote:
Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
Resend of https://source.winehq.org/patches/data/198804 My continued testing and Hans's tests show this patch to be correct. Those that disagree (Dmitry?), please retest and submit results on the bug report?
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(-)
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;
That comment is not entirely correct. In my testing GSSAPI does invoke this callback but fails if it returns a result.
Hans Leidekker <hans(a)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;
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") It's a snippet of the log running AD Explorer. P.S. Since we all are testing in different AD/LDAP configurations it would really help to have AD/LDAP testing server at winehq, so that we could be on the same page, and compare apples to apples. -- Dmitry.
On Mon, 2021-02-08 at 11:01 +0300, Dmitry Timoshkov wrote:
Hans Leidekker <hans(a)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;
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?
Hans Leidekker <hans(a)codeweavers.com> wrote:
Hans Leidekker <hans(a)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;
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. -- Dmitry.
On Mon, Feb 8, 2021 at 11:35 AM Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Hans Leidekker <hans(a)codeweavers.com> wrote:
Hans Leidekker <hans(a)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;
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?
Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
On Mon, Feb 8, 2021 at 11:35 AM Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Hans Leidekker <hans(a)codeweavers.com> wrote:
Hans Leidekker <hans(a)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;
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.
participants (3)
-
Damjan Jovanovic -
Dmitry Timoshkov -
Hans Leidekker