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?
frvdamme@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) 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??
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
2010/5/11 Philip Guenther guenther+ldapsoft@sendmail.com:
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.
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).
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.
openldap-software@openldap.org
-
Frank Van Damme -
Philip Guenther