Change in LDAP behavior on Windows

[cmaeckel]

I did this

With the Windows version of curl 7.53.1 the following command returns the expected result:

curl.exe ldap://ldap.forumsys.com/uid=tesla,dc=example,dc=com?cn
DN: uid=tesla,dc=example,dc=com
cn: Nikola Tesla

With the Windows version 7.61.1 it returns an error:

curl.exe ldap://ldap.forumsys.com/uid=tesla,dc=example,dc=com?cn
curl: (38) LDAP local: ldap_simple_bind_s Invalid DN Syntax

I expected the following

I expect the same answer as version 7.53.1. The unix/linux/Mac versions of 7.61.1 return the same answer as the Windows 7.53.1 version.

curl/libcurl versions

curl 7.53.1 (x86_64-pc-win32) libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 nghttp2/1.19.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM SSL libz HTTP2 HTTPS-proxy

curl 7.61.1 (x86_64-pc-win32) libcurl/7.61.1 WinSSL zlib/1.2.11
Release-Date: 2018-09-05
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz

operating system

Windows 10 64-bit

[cmaeckel]

Okay, I found what changed the behavior, #878. Still trying to figure out how to talk to a LDAP server from Windows that does not require authentication. Would be nice if the same syntax worked for the non-Windows versions also.

[snikulov]

@cmaeckel your assumption about #878 is wrong.
It was related to WinLDAP usage. But implementation or build you've mentioned curl 7.61.1 (x86_64-pc-win32) not using those changes ref.

[snikulov]

@cmaeckel this one works for me
curl.exe "ldap://ldap.forumsys.com/dc=example,dc=com?sub?cn=*" -v -u "cn=read-only-admin,dc=example,dc=com:password"

[snikulov]

This also works
curl.exe "ldap://ldap.forumsys.com/ou=mathematicians,dc=example,dc=com?sub?cn=*" -v -u "uid=tesla,dc=example,dc=com:password"

curl.exe "ldap://ldap.forumsys.com/uid=tesla,dc=example,dc=com?cn" -v -u "uid=tesla,dc=example,dc=com:password"

uid/passwords described here

[snikulov]

@cmaeckel is my explanations and examples solve your issue? Can we close this?

[cmaeckel]

The internal LDAP servers we are talking to do not want any authentication info, so we never have specified the -u option in the past, either for the Linux version or the Windows version. We are deciding what is going to be easier, change all our scripts or to just build our own version of curl.exe that works how it used to. I'm leaning to the later so that the command lines remain the same on both platforms.

[bagder]

@cmaeckel: the changed behavior/usage that you refer to was not intended (at least I was unaware of them). But I'm clueless about LDAP on windows so I have no suggestion on what a possible way forward could be here...

[snikulov]

@bagder Daniel, I've confirmed the issue.
It definitely I've changed the behaviour so I'll try to fix it soon.

[cmaeckel]

Thanks for looking at it. In the mean time we are using a curl.exe I've built backing out the changes to ldap.c from issue #878. Clearly this is not the general fix because that issue added addition authentication methods for Windows, which we don't need since all our usage is anonymous. I'm not sure how "automatic" the intent is for Windows is if nothing is specified but it currently doesn't guess correct for our case.

[cmaeckel]

Instead of backing out all the changes from issue #878 I've now just changed to the code to try anonymous access if the single signon fails. Really curl should have another option to try single signon instead of assuming that a blank username and password means to try the credentials of the user currently logged in.

ldap.diff.txt

[bagder]

I'm sorry but there seems to be nobody around who knows LDAP enough and wants to work on this.