[Date Prev][Date Next] [Chronological] [Thread] [Top]

ldapsearch - unexpected behavior with "-h URI -p PORT"


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} \

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_new_connection 1 1 0
	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
	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.