dovecot - Apr 2008 - Please help: LDAP configuration _almost_ works.

Red Hat Linux release 7.2 (Enigma)
OpenLDAP 2.3.38
Dovecot 1.0.12

SHORT VERSION
----- -------

	Here is my dovecot-ldap.conf:

hosts = ldap.lrtz
dn = cn=varmail,ou=users,dc=lorentz,dc=com
dnpass = *********
ldap_version = 3
auth_bind = yes
pass_filter = (&(objectClass=inetOrgPerson)(mail=%Lu))
base = ou=users, dc=%Dd
scope = onelevel

	I have tested using the above information with ldapsearch, and it works
fine.
	However, when dovecot tries to authenticate the user, the LDAP server
receives the query and responds to it (according to the LDAP log file),
but dovecot just hangs there.  180 seconds later, it drops the IMAP
client.
	E.g.:

        The dovecot log shows:

Apr  3 08:13:21 fourier dovecot: auth(default): new auth connection:
pid=15774
Apr  3 08:13:30 fourier dovecot: auth(default): client in:
AUTH^I1^IPLAIN^Iservice=IMAP^Isecured^Ilip=x.x.x.x^Irip=y.y.y.y^Iresp=<hidden>
Apr  3 08:13:30 fourier dovecot: auth(default):
ldap(jackmc at lorentz.com,y.y.y.y): bind search: base=ou=users,
dc=lorentz,dc=com
filter=(&(objectClass=inetOrgPerson)(mail=jackmc at lorentz.com))
Apr  3 08:16:30 fourier dovecot: imap-login: Disconnected: Inactivity:
method=PLAIN, rip=y.y.y.y, lip=x.x.x.x, TLS

        The OpenLDAP log shows that the query is received and that it
returns a match:

Apr  3 08:13:30 fourier slapd[14039]: conn=7 op=3 SRCH
base="ou=users,dc=lorentz,dc=com" scope=1 deref=0
filter="(&(objectClass=inetOrgPerson)(mail=jackmc at
lorentz.com))"
Apr  3 08:13:30 fourier slapd[14039]: conn=7 op=3 SRCH attr=uid
Apr  3 08:13:30 fourier slapd[14039]: conn=7 op=3 SEARCH RESULT tag=101
err=0 nentries=1 text

LONG VERSION
---- -------
        My users login using their email address as username. Each
domain has
their own LDAP subtree.  Each user has an entry in the ou=users subtree
of the domain subtree, and has a mail: field (inetOrgPerson) listing
their email address/login name.
        I am trying to use auth_bind: when I login with
jackmc at lorentz.com,
dovecot should search for mail=jackmc at lorentz.com in the onelevel below
ou=users,dc=lorentz,dc=com and find me as "cn=Jack
McKinney,ou=users,dc=lorentz,dc=com".
        I have created an entry in LDAP (varmail) that should be able to
do
this query.  Indeed, from the command line, it works:

ldapsearch -h ldap.lrtz -b 'ou=users, dc=lorentz, dc=com' -D
'cn=varmail,ou=users,dc=lorentz,dc=com' -x -W -s onelevel
'(&(objectClass=inetOrgPerson)(mail=jackmc at lorentz.com))'
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <ou=users, dc=lorentz, dc=com> with scope oneLevel
# filter: (&(objectClass=inetOrgPerson)(mail=jackmc at lorentz.com))
# requesting: ALL
#

# Jack McKinney, users, lorentz.com
dn: cn=Jack McKinney,ou=users,dc=lorentz,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Jack McKinney
givenName: Jack McKinney
sn: McKinney
mail: jackmc at lorentz.com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

	It appears that dovecot performs the above query successfully, but then
never uses the password and retrieved DN to attempt to bind and
authenticate the user.  Instead, it just times out. (See log files above
in the SHORT VERSION).
	I tried to add pass_attrs, in case there was a bug in dovecot where it
ignores the reply if there are no pass_attrs (even though none are
needed), but it still fails the same way.
	Timo Sirainen suggested that I add a debug line to src/auth/db-ldap.c
ldap_input() around line 372:

                msgid = ldap_msgid(res);
// added line:
                i_info("LDAP: Received reply %d", msgid);

	I did this.  Now, when the server first starts up, this line is logged.
However, it is not logged when it queries the LDAP server as a result of
an IMAP connection needing authentication.

-- 
Jack McKinney
GPG 1024D/99C6A174
jackmc at lorentz.com YM:lfaatsnat2006 AIM:jackmclorentz
"There is no parameter that makes it impossible for you to perform still
more excellently."
   -Mario Cuomo, on the lack of a clock in baseball
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080408/f04aa355/attachment-0002.bin>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 8 Apr 2008, Jack McKinney wrote:
> hosts = ldap.lrtz
> dn = cn=varmail,ou=users,dc=lorentz,dc=com
> dnpass = *********
> ldap_version = 3
> auth_bind = yes
> pass_filter = (&(objectClass=inetOrgPerson)(mail=%Lu))
> base = ou=users, dc=%Dd
> scope = onelevel
Your configuration looks bad:

You use auth_bind, but the displayed LDAP item does not contain no 
"userPassword" attribute and you've specified "dn", not
necessary for
auth_bind's. And you have no pass_attrs config.

I guess the first step is to set auth_bind = no
and add the password attribute to the user.

Or keep the auth_bind = yes and add a userPassword attribute to the user, 
so each user can bind itself to his/her LDAP item.

Wiki: http://wiki.dovecot.org/AuthDatabase/LDAP
>        The OpenLDAP log shows that the query is received and that it
> returns a match:
>
> Apr  3 08:13:30 fourier slapd[14039]: conn=7 op=3 SRCH
> base="ou=users,dc=lorentz,dc=com" scope=1 deref=0
> filter="(&(objectClass=inetOrgPerson)(mail=jackmc at
lorentz.com))"
> Apr  3 08:13:30 fourier slapd[14039]: conn=7 op=3 SRCH attr=uid
> Apr  3 08:13:30 fourier slapd[14039]: conn=7 op=3 SEARCH RESULT tag=101
> err=0 nentries=1 text
Well, does nentries=1 really indicates one _match_ or just one returned 
item/packet? If I use ldapsearch -x uid=nonexisting , I get: "# 
numResponses: 1" in the last line, but no hit.
You also see that the search is attr=uid, why?

I do _not_ know why Dovecot just hangs, this is probably a bug due to the 
configuration glitches.

Bye,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH/xFeVJMDrex4hCIRAq1TAJ9MVpxpDnAmNgDp7y3MO1tIcE6zhQCeMMe4
GQ5xrufcilvadYYiyaJvvCI=IgtW
-----END PGP SIGNATURE-----