https://bugs.winehq.org/show_bug.cgi?id=50545
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
--- Comment #11 from Damjan Jovanovic damjan.jov@gmail.com --- I am also investigating an Active Directory authentication bug at the moment.
Here we have 0x8007202a from the messagebox, meaning severity error, facility Win32, code ERROR_DS_AUTH_UNKNOWN.
From the trace:
---snip--- 0024:trace:wldap32:ldap_bind_sW (0x19a488, (null), 0x31b8d4, 0x00000486) 0024:trace:adsldp:openobj_OpenDSObject ldap_bind_sW error 0x56 ---snip---
0x56 is WLDAP32_LDAP_AUTH_UNKNOWN obtained from OpenLDAP's LDAP_AUTH_UNKNOWN.
---snip--- 0x56 86 LDAP_AUTH_UNKNOWN DUA client-side result code Indicates that a bind method was called with an unknown authentication method. ---snip---
Looking at this line in particular:
---snip--- 0024:trace:wldap32:ldap_bind_sW (0x19a488, (null), 0x31b8d4, 0x00000486) ---snip---
(This function is where my app fails too.)
0x00000486 = WLDAP32_LDAP_AUTH_NEGOTIATE cred is non-null, ld is non-null
That means it will call ldap_sasl_interactive_bind_s().
During the call to that function, it should call the sasl_interact() callback which supplies the credentials (realm, username and password). sasl_interact() logs these calls, but nothing is logged here. That means it must be failing earlier: presumably it asks AD for acceptable authentication methods, and the ones supplied by AD are all unsupported, so it is unable to authenticate at all, and doesn't even try asking for credentials.
Take a packet trace with tcpdump or Wireshark, and let's see what it's doing at the network level. If encrypted, you might need a plaintext connection, a tool like ssldump, or to configure Wireshark with the private key. It should tell us much more about what's going, including which authentication methods the AD server supports.
Is this the tool in question: https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer