LDAP auth backend in Dovecot 1.1.5 seemingly fails to handle certainpaths 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 = [email protected] 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 = [email protected] 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.gzThis 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 [email protected] -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/[email protected]/msg09174.html
ldap-hung.pcap.gz
Description: application/gzip
ldap-ok.pcap.gz
Description: application/gzip
ldap-ldapsearch.pcap.gz
Description: application/gzip
