A while ago I asked a question about this same issue already (Cyrus on CentOS with sasl / pam / ldap), and I came a bit further. The Bind DN is no longer empty; LDAP works with all apps except imap.
Whenever I try to logon using imtest:
[root@testserv ~]# imtest -u my.Email@testserv.mydomain.com -a my.Email@testserv.mydomain.com
I get this message in slapd.log:
Oct 17 01:22:06 testserv slapd[1745]: conn=2627 op=2 SRCH base="o=mydomain,c=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=my.Email@testserv.mydomain.com))"
What I don't understand is, where does the filter "(&(objectClass=posixAccount)(uid=my.Email@testserv.mydomain.com)" come from? I didn't put it in any of the config files; filter must be on mail, but whatever I change, this is what I get.
My /etc/pam.d/imap:
auth sufficient /lib64/security/pam_unix.so debug likeauth nullok
auth sufficient /lib64/security/pam_ldap.so debug use_first_pass
auth required /lib64/security/pam_deny.so
account sufficient /lib64/security/pam_unix.so
account sufficient /lib64/security/pam_ldap.so
My /etc/saslauthd.conf:
ldap_servers: ldap://127.0.0.1/
ldap_search_base: dc=%d,o=mydomain,c=com
ldap_bind_dn: cn=Manager,o=mydomain,c=com
ldap_password: ***********
ldap_auth_method: bind
ldap_filter: (|(uid=%u)((&(mail=%u@%d)(accountStatus=active)))
ldap_debug: 1
ldap_version: 3
/etc/sysconfig/saslauthd:
# Directory in which to place saslauthd's listening socket, pid file, and so
# on. This directory must already exist.
SOCKETDIR=/var/run/saslauthd
# Mechanism to use when checking passwords. Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.
MECH=pam
# Additional flags to pass to saslauthd on the command line. See saslauthd(8)
# for the list of accepted flags.
FLAGS="-c -r -O /etc/saslauthd.conf"
Some values from /etc/imap.conf:
sasl_mech_list: PLAIN LOGIN
sasl_pwcheck_method: saslauthd
And in /etc/ldap.conf I set this:
# The user ID attribute (defaults to uid)
pam_login_attribute mail
As I said, other apps do work with LDAP, so I assume it's PAM/SASL related... and I'm stuck :-S