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