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
