how to NOT use SASL

[Frank Van Damme]

Hi list,

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?

***@osc1:~$ ldapsearch -w dd -D
'cn=admin,dc=otec,dc=vub,dc=ac,dc=be' '(cn=admin)' -H
ldap://localhost -x
ldap_bind: Invalid credentials (49)
***@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??

[Philip Guenther]

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?
'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)
'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

[Frank Van Damme]

Post by Philip Guenther

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?
'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
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.

Ok, I'll keep that in mind next time I post anything like that to a
mailing list (I worked with non-GNU's but usually I indeed don't pay
much attention to it when on Linux).

Post by Philip Guenther
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.

Ah, ok. That declares it nicely. Thank you very much.