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

Re: how to NOT use SASL



On Tue, 11 May 2010, Frank Van Damme wrote:
> Now this is something I don't understand. TSL shouldn't require the use 
> of sasl, logically speaking, yet why am I getting this output?
> 
> frvdamme@osc1:~$ ldapsearch  -w dd -D
> 'cn=admin,dc=otec,dc=vub,dc=ac,dc=be' '(cn=admin)'  -H
> ldap://localhost -x

As a side-note, the above command-line is non-portable as it depends on a 
GNU-libc extension to the behavior of getopt() to parse option arguments 
after positional arguments.  (That behavior is a violation of the POSIX 
standard.)  The portable way to write that is to put the positional 
argument, the search filter in this case, after all of the option 
arguments, ala:

ldapsearch  -w dd -D 'cn=admin,dc=otec,dc=vub,dc=ac,dc=be' \
	-H ldap://localhost -x '(cn=admin)'  

That's not related to your issue, but you may bump into it later and may 
confuse others trying to reproduce your problem.


> ldap_bind: Invalid credentials (49)
> frvdamme@osc1:~$ ldapsearch  -w dd -D
> 'cn=admin,dc=otec,dc=vub,dc=ac,dc=be' '(cn=admin)' -x -H ldap://osc1
> -x
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> 
> So the only difference is how I specify the hostname and ldapsearch
> chooses to use sasl, even though I'm specifying -x. Why??

It's not actually doing SASL, but rather is doing a simple bind (see the 
"SIMPLE" there?).  ldap_sasl_bind() is the supported libldap entry point 
for *all* authentication, SASL, SIMPLE, or otherwise.  The old library 
entry points ldap_simple_bind(), ldap_bind(), and similar were deprecated 
at some point, largly because they didn't support passing controls or 
returning server creds, IIRC.


Philip Guenther