Hello,
I run into some unexpected behavior using ldapsearch today and believe it is a bug. It all started with following command:
ldapsearch -x -LLL -h ldap://localhost -p 10636 -b ${BASEDN} \ uid=${USER} -D ${BINDINGUSER} -W
After checking the man page, it became clear that: 1. '-h' should take a *hostname* as argument (not "ldap://...") 2. Using '-H' (+ URI) is recommended instead of '-h'/'-p'
And sure enough following command works as expected:
ldapsearch -x -LLL -H ldap://localhost:10636 (...)
The actual issue is what happens when running the fist command. - The "-h" option takes a hostname. As "ldap://localhost" is *not* a valid hostname, I would expect the command the fail - What happens instead is that ldapsearch connect to localhost on port 389 (!)
$ ldapsearch -x -d 255 -h ldap://localhost -p 10389 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389
Note this *only* happens when both '-h' and '-p' are used. When only '-h' is used, following happens which seem fine:
$ ldapsearch -x -d 255 -h ldap://localhost ldap_create ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost) ldap_err2string Could not create LDAP session handle for URI=ldap://ldap: %2F%2Flocalhost (-9): Bad parameter to an ldap routine
Bellow are some more example:
1. $ ldapsearch -x -d 255 -h example.org -p 10636 -> Connects to example.org on port 10636 (as expected)
2. $ ldapsearch -x -d 255 -h /example.org -p 10636
-> Connects to localhost on port 389 (!) - note the added "/"
3. $ ldapsearch -x -d 255 -h /example.org
-> Fails as "/example.org" is not resolvable (as expected)
Running the command will give you the debug output (which I omitted here). Note I am using openldap 2.4.44.
I hope the explanation is clear. The behavior must definitely looks like a bug to me and got me very confused.
Best,
Alex