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.

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