Questions about LDAP schema and Multi-Domain IMAP

[Howard Chu]

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 "blackard at omniprise.com" 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: owner-cyrus-sasl at lists.andrew.cmu.edu
[mailto:owner-cyrus-sasl at lists.andrew.cmu.edu]On Behalf Of Blackard, Robert
Sent: Wednesday, March 05, 2003 7:48 AM
To: 'info-cyrus at lists.andrew.cmu.edu'; 'cyrus-sasl at lists.andrew.cmu.edu'
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 blackard at omniprise.com and
blackard at support.omniprise.com 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.