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.