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 cyradm.
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
Be warned: there is a nasty bug regarding Cyrus and SASL on Debian Woody that can cause a lot of problems. If you don't need it, 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.
Also found in syslog:
Oct 12 22:57:56 ''server'' perl: No worthy mechs found Oct 12 22:57:57 ''server'' cyrus/imapd[''number'']: cannot connect to saslauthd server: Permission denied
You need to make sure that Cyrus can read /var/run/saslauthd/mux. The best way to do this (as done in Sarge and up) is to make a 'sasl' group on your system, make 'cyrus' a member of this group, and set /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.
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]
The LDAP client config file can be at either /etc/openldap/ldap.conf or /etc/ldap.conf. The additions listed above for /etc/openldap/ldap.conf should actually be added to /etc/ldap.conf. This was figured out by setting the loglevel on openldap to -1 and watching the conversation while doing a cyradm --user cyrus localhost.
In Debian, the file is /etc/pam_ldap.conf with content as in /etc/openldap/ldap.conf. You should configure it with dpkg-reconfigure libpam-ldap.
Aug 24 15:01:49 vienne saslauthd[29787]: (pam_unix) check pass; user unknown Aug 24 15:01:49 vienne saslauthd[29787]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= Aug 24 15:01:52 vienne saslauthd[29787]: DEBUG: auth_pam: pam_authenticate failed: User not known to the underlying authentication module Aug 24 15:01:52 vienne saslauthd[29787]: do_auth : auth failure: [user=craig] [service=imap] [realm=domain.co.nz] [mech=pam] [reason=PAM auth error]
You're using a new saslauthd, which by default, will present the user without the @domain.co.nz in it. This might break your virtual hosting setup. The fix is add -r to your saslauthd command line, which on Debian you can do in /etc/default/saslauthd with PARAMS="-r".(Debian bug)
Note: see LDAPNotes for more information regarding LDAP under Debian.
(cyrus2.2 on Debian 4.0 (Etch))
Following the walkthrough in /usr/share/doc/cyrus-imapd-2.2/README.Debian.simpleinstall.gz, I got to here and couldn't log in as admin to create users.
The problem was that I had only enabled imaps (ie over SSL) and not imap in /etc/cyrus.conf, and the cyradm tool appears to do configuration over plain imap. Enable imap in /etc/cyrus.conf, restart cyrus, and you should now be able to log in to localhost using cyradm.
If you have (stupidly - I did this!) 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. Websieve login will fail without libsasl2-modules.
Cyrus supports LMTP mail delivery - this is much more efficient than using a delivery program such as deliver, or using procmail. Edit /etc/cyrus.conf and enable a SERVICES entry similar to the following (it may already be enabled)
lmtp cmd="lmtpd -a" listen="127.0.0.1:lmtp" prefork=0
This will listen for lmtp on the localhost IP. You may wish to use a unix domain socket instead:
lmtpunix cmd="lmtpd -a" listen="/var/imap/socket/lmtp" prefork=0
You can now set your MTA to deliver to Cyrus via LMTP, by specifying the appropriate address. See LMTPNotes for more information, or EximNotes for connecting to Exim.
If you happen to be using an MTA that doesn't support LMTP delivery, and you really have to use something like procmail to get the mail from the MTA into Cyrus, then you MUST use the deliver program packaged with Cyrus. Do not attempt to deliver directly into the Cyrus mailspool.
See ProcmailNotes for an example recipe snippet. Or upgrade your MTA to something like Exim or Postfix.
4 pages link to CyrusNotes:
