On 29/09/10 10:19 -0500, Erik Lotspeich wrote:
Hi Dan,
I hope that I don't mind if I ask a follow-up question:
root@starfish:/usr/local/etc/openldap# testsaslauthd -u erik -p XXX -s slapd 0: OK "Success."
That works, but when I run ldapwhami, it doesn't:
root@starfish:/usr/local/etc/openldap# ldapwhoami -Y login -U erik -H ldap://localhost ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found
I did a search on the internet, and I ran this command:
root@starfish:/usr/local/etc/openldap# ldapsearch -x -ZZ -s base -b "" # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL #
# dn: objectClass: top objectClass: OpenLDAProotDSE
# search result search: 3 result: 0 Success
In other examples I've seen, mechanisms such as PLAIN or LOGIN or listed here.
Make sure you have the appropriate sasl shared libraries installed on both your server and your client (which appears to be the same according to your examples from above). Use plugingview/saslpluginviewer to see which server/client mechanisms you do have installed.
For instance, on a Debian system you'd need to have the libsasl2-modules package.
If you do have those mechanisms installed but are still not seeing them in the '-s base -b ""' search, make sure you've added 'sasl-secprops none' to your openldap slapd.conf.
Hi Dan,
Thanks so much for your help. I'm getting closer.
The ldapwhoami seems to work now.
erik@starfish:~/ldif$ ldapwhoami -U erik -H ldaps://localhost/ SASL/PLAIN authentication started Please enter your password: SASL username: erik SASL SSF: 0 dn:uid=erik,cn=plain,cn=auth erik@starfish:~/ldif$
I can also run an ldapsearch to list the contents of my database:
erik@starfish:~/ldif$ ldapsearch -D 'uid=erik,cn=plain,cn=auth' -b 'ou=people, dc=lotspeich,dc=org' '(objectclass=*)' -H ldaps://localhost/ -W -Y plain Enter LDAP Password: SASL/PLAIN authentication started SASL username: erik SASL SSF: 0 # extended LDIF # # LDAPv3 # base <ou=people, dc=lotspeich,dc=org> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# people, lotspeich.org dn: ou=people,dc=lotspeich,dc=org objectClass: top objectClass: organizationalUnit ou: people . . *** DATA OMITTED! *** . # search result search: 2 result: 0 Success
# numResponses: 136 # numEntries: 135
I have two questions/concerns:
1. If I leave the "-Y plain" option off of the argument list to ldapsearch, I get "Invalid credentials":
erik@starfish:~/ldif$ ldapsearch -D 'uid=erik,cn=plain,cn=auth' -b 'ou=people, dc=lotspeich,dc=org' '(objectclass=*)' -H ldaps://localhost/ -W Enter LDAP Password: ldap_bind: Invalid credentials (49) erik@starfish:~/ldif$
I have a configuration file in /usr/local/sasl2 for slapd.conf; I tried adding one for ldapsearch:
root@starfish:/usr/lib/sasl2# cat ldapsearch.conf pwcheck_method: saslauthd mech_list: plain
This didn't seem to make a difference in allowing me to authenticate without the "-Y" option.
2. I would like to use authenticated LDAP in Thunderbird. I set uid=erik,cn=plain,cn=auth as my Bind DN. It asked for my password, but always returned 'authentication failed'.
I don't know if #1 or #2 are related. I know I must be missing something. From what I understand (which isn't much), I'm not using simple bind, so I don't need the mappings in my configuration file that you mentioned previously.
Regards,
Erik
Dan White wrote:
On 29/09/10 10:19 -0500, Erik Lotspeich wrote:
Hi Dan,
I hope that I don't mind if I ask a follow-up question:
root@starfish:/usr/local/etc/openldap# testsaslauthd -u erik -p XXX -s slapd 0: OK "Success."
That works, but when I run ldapwhami, it doesn't:
root@starfish:/usr/local/etc/openldap# ldapwhoami -Y login -U erik -H ldap://localhost ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found
I did a search on the internet, and I ran this command:
root@starfish:/usr/local/etc/openldap# ldapsearch -x -ZZ -s base -b "" # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL #
# dn: objectClass: top objectClass: OpenLDAProotDSE
# search result search: 3 result: 0 Success
In other examples I've seen, mechanisms such as PLAIN or LOGIN or listed here.
Make sure you have the appropriate sasl shared libraries installed on both your server and your client (which appears to be the same according to your examples from above). Use plugingview/saslpluginviewer to see which server/client mechanisms you do have installed.
For instance, on a Debian system you'd need to have the libsasl2-modules package.
If you do have those mechanisms installed but are still not seeing them in the '-s base -b ""' search, make sure you've added 'sasl-secprops none' to your openldap slapd.conf.
On 05/10/10 15:04 -0500, Erik Lotspeich wrote:
Hi Dan,
Thanks so much for your help. I'm getting closer.
The ldapwhoami seems to work now.
erik@starfish:~/ldif$ ldapwhoami -U erik -H ldaps://localhost/ SASL/PLAIN authentication started Please enter your password: SASL username: erik SASL SSF: 0 dn:uid=erik,cn=plain,cn=auth erik@starfish:~/ldif$
I have two questions/concerns:
- If I leave the "-Y plain" option off of the argument list to
ldapsearch, I get "Invalid credentials":
That might indicate that your client utilities are attempting to use a mechanism that is not able to complete your authentication, such as DIGEST-MD5, or perhaps EXTERNAL.
A work around is to create a '.ldaprc' file in your home directory with the contents:
SASL_MECH PLAIN
which all OpenLDAP client utilities (and client library) should honor. See the man page for ldap.conf(5) for details.
erik@starfish:~/ldif$ ldapsearch -D 'uid=erik,cn=plain,cn=auth' -b 'ou=people, dc=lotspeich,dc=org' '(objectclass=*)' -H ldaps://localhost/ -W Enter LDAP Password: ldap_bind: Invalid credentials (49) erik@starfish:~/ldif$
I have a configuration file in /usr/local/sasl2 for slapd.conf; I tried adding one for ldapsearch:
Is that /usr/lib/sasl2/slapd.conf or /usr/local/sasl2/slapd.conf (should be the former)?
The file name is determined by the sasl library (or how OpenLDAP calls it), and should always be 'slapd.conf' for OpenLDAP. The default location for the file should be /usr/lib/sasl2, but may also be looked in /etc/sasl2, depending on the version of cyrus your using, and what '--with-configdir' option was passed to it at compile time.
root@starfish:/usr/lib/sasl2# cat ldapsearch.conf pwcheck_method: saslauthd mech_list: plain
This didn't seem to make a difference in allowing me to authenticate without the "-Y" option.
- I would like to use authenticated LDAP in Thunderbird. I set
uid=erik,cn=plain,cn=auth as my Bind DN. It asked for my password, but always returned 'authentication failed'.
the 'uid=erik,cn=plain,cn=auth' is your derived authenticated identity based on SASL authentication. Thunderbird will need to perform a SASL bind using a username of 'erik' and your password. You cannot perform simple authentication using that DN unless that DN actually exists in your tree.
See chapter 15 of the OpenLDAP Software 2.4 Administrator's Guide for a discussion of mapping authentication identities to DNs.
Hi Dan,
A work around is to create a '.ldaprc' file in your home directory with the contents:
SASL_MECH PLAIN
This change has no effect...
I am running 2.4.23 that I built from source. Both ldapsearch and ldapwhoami are linked against libsasl2. If there's some configuration that I'm missing, I'm not aware of it...
Is that /usr/lib/sasl2/slapd.conf or /usr/local/sasl2/slapd.conf (should be the former)?
Yes, that was a typo, sorry about that (it's the former).
the 'uid=erik,cn=plain,cn=auth' is your derived authenticated identity based on SASL authentication. Thunderbird will need to perform a SASL bind using a username of 'erik' and your password. You cannot perform simple authentication using that DN unless that DN actually exists in your tree.
What DN would I use for simple authentication? Maybe Thunderbird cannot perform a SASL BIND?
It seems that Thunderbird and ldapwhoami (with the -D option) are doing the same kind of Bind:
# ldapwhoami -H ldaps://localhost/ -D 'uid=erik,cn=plain,cn=auth' -W Oct 6 11:28:14 starfish slapd[17086]: conn=1000 fd=13 ACCEPT from IP=127.0.0.1:44395 (IP=0.0.0.0:636) Oct 6 11:28:14 starfish slapd[17086]: conn=1000 fd=13 TLS established tls_ssf=256 ssf=256 Oct 6 11:28:14 starfish slapd[17086]: conn=1000 op=0 BIND dn="uid=erik,cn=plain,cn=auth" method=128 Oct 6 11:28:14 starfish slapd[17086]: conn=1000 op=0 RESULT tag=97 err=49 text= Oct 6 11:28:14 starfish slapd[17086]: conn=1000 fd=13 closed (connection lost)
And from Thunderbird: Oct 6 11:26:17 starfish slapd[17042]: conn=1010 fd=13 ACCEPT from IP=1.2.3.4:49964 (IP=0.0.0.0:636) Oct 6 11:26:17 starfish slapd[17042]: conn=1010 fd=13 TLS established tls_ssf=256 ssf=256 Oct 6 11:26:17 starfish slapd[17042]: conn=1010 op=0 BIND dn="uid=erik,cn=plain,cn=auth" method=128 Oct 6 11:26:17 starfish slapd[17042]: conn=1010 op=0 RESULT tag=97 err=49 text=
The ldapwhoami command works with the -U option:
root@starfish:/home/erik/ldif# ldapwhoami -U erik -H ldaps://localhost/ SASL/PLAIN authentication started Please enter your password: SASL username: erik SASL SSF: 0 dn:uid=erik,cn=plain,cn=auth
The debug output is as follows:
Oct 6 11:32:55 starfish slapd[17086]: conn=1001 fd=13 ACCEPT from IP=127.0.0.1:41416 (IP=0.0.0.0:636) Oct 6 11:32:55 starfish slapd[17086]: conn=1001 fd=13 TLS established tls_ssf=256 ssf=256 Oct 6 11:32:55 starfish slapd[17086]: conn=1001 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Oct 6 11:32:55 starfish slapd[17086]: conn=1001 op=0 SRCH attr=supportedSASLMechanisms Oct 6 11:32:55 starfish slapd[17086]: conn=1001 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 6 11:32:56 starfish slapd[17086]: conn=1001 op=1 BIND dn="" method=163 Oct 6 11:32:56 starfish slapd[17086]: conn=1001 op=1 BIND authcid="erik" authzid="erik" Oct 6 11:32:56 starfish slapd[17086]: conn=1001 op=1 BIND dn="uid=erik,cn=plain,cn=auth" mech=PLAIN sasl_ssf=0 ssf=256 Oct 6 11:32:56 starfish slapd[17086]: conn=1001 op=1 RESULT tag=97 err=0 text= Oct 6 11:32:56 starfish slapd[17086]: conn=1001 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.3 Oct 6 11:32:56 starfish slapd[17086]: conn=1001 op=2 WHOAMI Oct 6 11:32:56 starfish slapd[17086]: conn=1001 op=2 RESULT oid= err=0 text= Oct 6 11:32:56 starfish slapd[17086]: conn=1001 op=3 UNBIND Oct 6 11:32:56 starfish slapd[17086]: conn=1001 fd=13 closed
See chapter 15 of the OpenLDAP Software 2.4 Administrator's Guide for a discussion of mapping authentication identities to DNs.
I have read the Adminstrator's guide, but it is still not clear to me... I'm not sure why I need to map anything, actually. I do not use LDAP as an authentication server at all. I only want to provide authenticated access to the LDAP database -- and I want that authentication to come from a password in /etc/shadow.
I'm not sure why the "-U erik" form works and the "-D 'uid=erik,cn=plain,cn=auth'" form does work.
Thanks again for your help and for bearing with me.
Regards,
Erik
Erik,
Erik Lotspeich schrieb am 05.10.2010 22:04 Uhr:
I have two questions/concerns:
- If I leave the "-Y plain" option off of the argument list to
ldapsearch, I get "Invalid credentials":
As far as I know from other SASL using software (like Postfix), the client always chooses the "securest" available mechanism offered by the server. So if you do not minimize the mechanism offered, the client tries a mechanism that might not be intended to be used. [openldap may do it in another way, anyway - but I don't think so.]
I have a configuration file in /usr/local/sasl2 for slapd.conf; I tried adding one for ldapsearch:
root@starfish:/usr/lib/sasl2# cat ldapsearch.conf pwcheck_method: saslauthd mech_list: plain
I don't think this file will be used. The file must be names like the application name the software communicates to SASL, which is slapd for the openldap server.
Did you set mech_list: plain in slapd.conf in /usr/local/sasl2 to tell slapd to just offer PLAIN?
Marc
openldap-technical@openldap.org
-
Dan White -
Erik Lotspeich -
Marc Patermann