Note: It is assumed that you already have an LDAP backend capable of authenticating via uid and userPassword attributes. This does not need to be on the same box as the cyrus imap server. It should have a valid "cyrus" user though.
Using RPMs downloaded from Simon Matter's Website...
auth sufficient /lib/security/pam_ldap.so
account sufficient /lib/security/pam_ldap.so
host your.ldap.server
base ou=Your-Account-Container,dc=your,dc=domain,dc=components
scope sub
pam_login_attribute uid
This is the same as above, but implemented under Debian Woody instead. Again, make sure there is a cyrus user with a password you can use to run cyradmin
Get the backported cyrus21 debs and dependencies from http://people.debian.org/hmh/ or the cyrus21 debs from sid/unstable.
auth sufficient /lib/security/pam_ldap.so
account sufficient /lib/security/pam_ldap.so
host your.ldap.server
base ou=Your-Account-Container,dc=your,dc=domain,dc=components
scope sub
pam_login_attribute uid
There is a nasty bug regarding Cyrus and SASL on debian woody that can cause a lot of problems. You need to get the deb src, edit debian/rules and remove --with-cyrus-sasl, recompile, and reinstall. Note that this is a bug with cyrus and not ldap/sasl. -- TomHibbert
IMAP Password: Login failed: generic failure at /usr/lib/perl5/Cyrus/IMAP/Admin.pm line 118
Another thing that tripped me up the second time around is the permissions on /var/run/saslauthd if you're using that as your auth mechanism - just make sure that cyrus can read it and all will be fine -- TomHibbert
The best way to do this IMO is to make a sasl group on your system, make cyrus a member of this group, and give /var/run/saslauthd/ group +x permissions (only needs +x in order to be able to get into the dir, the actual socket on /var/run/saslauthd/mux is world +rwx anyway). This way, if you have other apps that use sasl, you just need to make them members of the sasl group as well and they can also read the socket. This is, AFAIK, the way the debian packages normally handle this -- DanielLawson
I slammed my head against this for some time before figuring out that even though openldap creates /etc/openldap/ldap.conf as it's ldap client default configuration file, other programs aren't looking for that file. They're looking for /etc/ldap.conf. The additions listed above for /etc/openldap/ldap.conf should actually be added to /etc/ldap.conf I figured this out by setting the loglevel on openldap to -1 and watching the conversation while doing a cyradm --user cyrus localhost -- EugeneWood?
Here is what I was seeing in /var/log/messages Hopefully someone will catch this page from google with these terms -- EugeneWood?
Sep 20 14:44:35 server perl: No worthy mechs found Sep 20 14:44:37 server saslauthd[6341?: pam_ldap: ldap_search_s No such object Sep 20 14:44:37 server saslauthd[6341?: do_auth : auth failure: [user=cyrus? [service=imap? [realm=? [mech=pam? [reason=PAM auth error?
If you have (stupidly - I did ths!) deleted the cyrus spool directory for a mailbox, you will find you are unable to easily remove the mailbox from the db - cyrus will always think it exists. While I have no reason to believe this will harm anything, it is not a pleasant state to leave things in. I fixed it like this:
By Default Cyrus2.1 uses SASL2 based Authentication, which requires the installation of sasl2-bin, but doesn't install libsasl2-modules, which are required for sieve authentication.
Note: see LDAPNotes for more information regarding LDAP under Debian
4 pages link to CyrusNotes:
lib/main.php:944: Notice: PageInfo: Cannot find action page