I suggest you ditch OpenLDAP 2.0.27 and update to the latest 2.1 release. Then you ditch saslauthd & PAM and have SASL authenticate directly against LDAP. Note that OpenLDAP 2.0.X does not work with Cyrus SASL 2.1.x anyway, so you need OpenLDAP 2.1 if you're already using SASL 2.1.
With those issues aside, you still need to set up separate SASL realms corresponding to each unique domain namespace you want. The OpenLDAP 2.1 Admin Guide http://www.openldap.org/doc/admin21/ has information on how to configure SASL authentication in slapd. As an example, you would need some regex maps like sasl-regexp uid=(.*),cn=(.*)\\.(.*),cn=DIGEST-MD5,cn=auth ldap:///dc=$2,dc=$3??sub?uid=$1 The SASL user "[EMAIL PROTECTED]" logging in with DIGEST-MD5 would be turned into the authentication DN uid=blackard,cn=omniprise.com,cn=DIGEST-MD5,cn=auth and then the regexep would map this into a slapd-internal subtree search for "uid=blackard" under the dc=omniprise,dc=com tree. The slapd auxprop mechanism will provide the userpassword attribute from whatever single entry is found that matches this search to SASL, allowing the authentication to complete. (If 0 or more than 1 entry is found, the search fails and the slapd auxprop mech is ignored.) There are a number of advantages to using this approach over any other one: saslauthd only supports plaintext login, and plaintext logins are inherently insecure. the OpenLDAP 2.1 approach supports all of the password-based SASL mechanisms, securely. pam_ldap requires every client machine to be configured with search descriptors for mapping SASL usernames to LDAP DNs. This can be a headache when you have a large number of clients and your LDAP configuration evolves over time (as it always does). The search mapping takes multiple LDAP requests per login, which can be very inefficient. It requires the LDAP server gives anonymous access to search all accounts in the DIT, which violates many corporate security policies. the OpenLDAP 2.1 approach only needs search mapping to be done in slapd.conf, which vastly simplifies the job of keeping a large number of clients up to date. It also requires only a single LDAP Bind request by the client, and the rest of the mapping work is done internally to slapd. This makes far more efficient use of time and network resources. Also, clients don't need anonymous access to the DIT, which is another huge security win. This is just a quick description of how things work. If you want to talk more about how to use OpenLDAP, go to the OpenLDAP-Software mailing list. OpenLDAP 2.0 only supports Cyrus SASL 1.5. None of what I've just described works with OpenLDAP 2.0. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Blackard, Robert Sent: Wednesday, March 05, 2003 7:48 AM To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Questions about LDAP schema and Multi-Domain IMAP I didn't know if this was a general Cyrus issue or a sasl issue so I sent to both lists. I'm having a hard time finding and reconciling documentation about how to set up multi-domain user authentication for Cyrus IMAP using saslauthd, PAM and OpenLDAP. Any information, hints or suggestions of other resources would be helpful. I've been focusing on solving the problem for Cyrus and then expecting to back-fit that solution to sendmail. I have rather grand plans, so let me give a little background. I'm running RedHat 8.0, which comes with OpenLDAP 2.0.27, and I've downloaded the latest Cyrus IMAP and sasl stuff. Ideally users would be authenticated (and have their mail routed by sendmail and stored by Cyrus) with uid and domain. Uid's should be unique within domain, but the same uid should be allowed to exist under different domains. It would be nice, but not a requirement, that additional dc components be available to segregate classes of users within a domain so that, for example, within omniprise.com I could have support.omniprise.com and sales.omniprise.com - I would think that the uid be unique under omniprise.com so that [EMAIL PROTECTED] and [EMAIL PROTECTED] would be invalid. I have gotten this tree functioning under OpenLDAP as a starting point: root |- com (dc) | |- omniprise (dc) | | |- people (ou) | | | |- blackard (inetOrgPerson, posixAccount) | |- <yourco> (dc) | | |- ... |- org (dc) | |- hillcountrytriumphclub (dc) | | |- people (ou) | | | |- dgjulien (inetOrgPerson) | |- <theirorg> (dc) | | |- ... At the moment I've got the slapd.conf in a very simple form, and the suffix is defined as "" so that all data is stored in the same database. I'll worry about separating these later. Thanks in advance for any information you can provide, and I'm wearing my fireproof shorts in case I get flamed.
