LDAP auth backend in Dovecot 1.1.5 seemingly fails to handle certain paths of interaction with LDAP server, which is Windows AD running Windows 2003 server machine in my case.

The symptoms I observe look exactly as were already reported in [1]: authentication backend "hangs" after logging the fact it has sent the search request, then after a while the IMAP/POP3 connection is teared down by the server due to idle condition.

In the mentioned mail thread, it was proposed that if Dovecot doesn't log any LDAP server response, there is no such response, so I dumped the TCP traffic going between the backend and the server, and studied what happens with different settings.

The result is that it seems LDAP auth backend doesn't understand the case when the server offerrs one or more "referrals" which the client might want to check. It seems that the backend tries to do something else after it gets such a result from the LDAP server even if the server returned an entry matching the search request.

The described behaviour manifests itself with Windows AD only if I specify the domain name alone as the search base, e.g. "dc=mydomain,dc=com". If I also include at least one OU, the server doesn't return its list of referrals and Dovecot LDAP auth backend works OK.

I attached two files produced by tcpdump -- one with "hung" search request, and another with successful one. They are:

1. ldap-hung.pcap.gz Captured with /etc/dovecot/dovecot-ldap.conf settings: hosts = domain007.com dn = saslauthd@domain007.com dnpass = "secret" auth_bind = yes base = dc=domain007, dc=com pass_filter = (&(objectClass=person)(sAMAccountName=%u))

Packet #8 is of interest in this dump.

2. ldap-ok.pcap.gz Captured with /etc/dovecot/dovecot-ldap.conf settings: hosts = domain007.com dn = saslauthd@domain007.com dnpass = "secret" auth_bind = yes base = cn=Users, dc=domain007, dc=com pass_filter = (&(objectClass=person)(sAMAccountName=%u))

The only difference compared to the first case is the "cn=Users" prepended to the base DN, which prevents the server from attaching a list of referrals.

In both cases "search result done" is present in the server response.

3. ldap-ldapsearch.pcap.gz This dump captures the conversation of the ldapsearch utility with the same server using the same parameters Dovecot LDAP auth backend uses in the first case. ldapsearch invocation was like this: $ ldapsearch -h domain007.com -x -D saslauthd@domain007.com -w secret -a always -b dc=domain007,dc=com '(&(objectClass=person)(sAMAccountName=kostix))'

General configuration info (package from Debian stable):

# dovecot --version 1.0.15

# dovecot -n # 1.0.15: /etc/dovecot/dovecot.conf log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_privileged_group: mail mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv auth default: verbose: yes debug: yes passdb: driver: ldap args: /etc/dovecot/dovecot-ldap.conf userdb: driver: passwd

1. http://www.mail-archive.com/dovecot@dovecot.org/msg09174.html