Different backend authentications for Cyrus IMAP

[Dan White]

On 07/12/10 12:49 -0500, Jason Voorhees wrote:
>Hi:
>
>For personal reasons I'm planning to migrate a Zimbra installation to
>a Postfix+Cyrus IMAP based schema. My Zimbra server has two domains:
>domain1.com and domain2.com. Users from domain1.com authenticate via
>Active Directory and domain2.com authenticate via Zimbra (using its
>own OpenLDAP server).
>
>As you know Zimbra has its own POP/IMAP server embedded with a custom
>version of saslauthd. Now I have to keep the same double
>authentication schema
>when migrate to Cyrus IMAP so the question is: How could configure
>Cyrus IMAP to authenticate users from one domain (domain1.com) to a
>backend A (Active Directory) and users from other domain (domain2.com)
>to a backend B (OpenLDAP, MySQL, PAM, etc)? Is it possible? Any ideas?

One approach would be to run multiple instances of imapd, each pointing to
its own configuration file, or customized SASL configuration within the
primary imapd.conf file.

Given the following entries in /etc/cyrus.conf:

SERVICES {
      imapdom1    cmd="imapd" listen="imap.domain1.com:imap" prefork=0
      imapdom2    cmd="imapd" listen="imap.domain2.com:imap" prefork=0
      ...
}

Your imapd.conf could contain:

imapdom1_sasl_pwcheck_method: saslauthd
imapdom1_sasl_saslauthd_path: /path/to/zimbra's/custom/daemon/mux

imapdom2_sasl_pwcheck_method: saslauthd
imapdom2_sasl_saslauthd_path: /path/to/second/instance/of/saslauthd/mux

Which would require that your users connect to two different IP addresses
(imap.domain1.com and imap.domain2.com), and you'd need to run two
instances of saslauthd, but your second instance of saslauthd could
authenticate a number of different ways. On the downside, this approach
would require some creative configuration of postfix, if you users
authenticate to it.

If both domains can authenticate via LDAP (or Kerberos), you might check
out a recent thread on the OpenLDAP-technical list titled 'Pass-Through
authentication', which discusses a couple of alternatives.

-- 
Dan White