multi-domain/multi-rootdn for ptclient/ldap.c
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Sat Jun 22 10:04:14 EDT 2013
I've previously (a long time ago, actually, too long if you ask me) made
inquiries as to who might be using ptclient/ldap.c[1,2], and in which
fashion; I got three points from the responses;
- Everything should be configurable as LDAP deployments typically vary
widely and often pre-date a Cyrus IMAP deployment,
- It should handle groups better, namely nested/recursive groups,
the 'memberOf' attribute,
- It should handle memberUrls.
While these are all valid points and worth working on for me as well,
today I have another aspect; the handling of multi-domain deployments,
with isolated root dns for each parent domain. A very ugly and
presumptuous patch is attached, that needs extra careful checking and a
This scenario (of multiple domains separated in to multiple, different
root DNs) is widely in use with Kolab Groupware, while canonification
nor group ACLs would work.
The scenario for such a deployment could be described as follows:
- A list of objectClass=domainRelatedObject LDAP objects exists in
- A domain "example.org" may have a root dn of "dc=example,dc=org",
and would be an LDAP entry as follows:
- To translate "example.org" to "dc=example,dc=org" in this particular
case, the C equivalent of:
$root_dn = 'dc=' . implode(',dc=', explode('.', "example.org"));
can be used.
- Another domain "example.com" mayhave a root dn of "o=example,c=de",
and could be an LDAP entry as follows:
- Here, the inetDomainBaseDN attribute should be used to translate a
user login of "lucy.meier at example.com" to a search against
This leads me to believe the following items should be configurable:
The base dn to use when searching for "domains" or "domain name
For Kolab Groupware deployments, this is a default of
"cn=kolab,cn=config", but could of course be
"ou=Domains,dc=domain,dc=tld" as well.
The filter to use.
Perhaps something like
The search scope. "sub", "one" or "base", with a default of "sub".
The attribute name for actual domain name spaces, such as
For LDAP deployments without the Netscape schemas I suppose this
attribute name might be "cn".
For situations in which a domainRelatedObject does not contain one,
but multiple values for the domain_name_attribute, the first value
returned by LDAP is used (this typically corresponds with the relative
DN attribute value, and should be consistent).
Name of the attribute to look for, for example "inetDomainBaseDN".
If no such attribute exists (for the object found), fall back to the
"standard" root dn described above (the implode over explode thing).
I would appreciate your thoughts and feedback.
Thanks, in advance,
Jeroen van Meeuwen
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
pgp: 9342 BF08
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 15098 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20130622/41b4dab7/attachment-0001.bin
More information about the Info-cyrus