multi-domain/multi-rootdn for ptclient/ldap.c

[Jeroen van Meeuwen (Kolab Systems)]

Hi there,

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[3],

  - It should handle groups better[4], namely nested/recursive groups, 
the 'memberOf' attribute,

  - It should handle memberUrls[5].

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 
nice cleanup.

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 
cn=kolab,cn=config.

   - A domain "example.org" may have a root dn of "dc=example,dc=org", 
and would be an LDAP entry as follows:

     dn: associatedDomain=example.org,cn=kolab,cn=config
     objectClass: top
     objectClass: domainRelatedObject
     associatedDomain: example.org

   - 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:

     dn: associatedDomain=example.com,cn=kolab,cn=config
     objectClass: top
     objectClass: domainRelatedObject
     objectClass: inetDomain
     associatedDomain: example.com
     inetDomainBaseDN: o=example,dc=de

   - Here, the inetDomainBaseDN attribute should be used to translate a 
user login of "lucy.meier at example.com" to a search against 
"o=example,dc=de".

This leads me to believe the following items should be configurable:

   - domain_base_dn

     The base dn to use when searching for "domains" or "domain name 
spaces".

     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.

   - domain_filter

     The filter to use.

     Perhaps something like 
"(&(objectClass=domainRelatedObject)(inetDomainStatus=on)(associatedDomain=%s))"

   - domain_scope

     The search scope. "sub", "one" or "base", with a default of "sub".

   - domain_name_attribute

     The attribute name for actual domain name spaces, such as 
"associatedDomain".

     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).

   - domain_result_attribute

     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,

Kind regards,

Jeroen van Meeuwen

[1] 
http://lists.andrew.cmu.edu/pipermail/cyrus-devel/2011-August/001923.html
[2] 
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2011-August/035257.html
[3] 
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2011-August/035259.html
[4] 
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2011-August/035262.html
[5] 
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2011-August/035294.html

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-imapd-2.5-ptclient-ldap-discover-domain-root-dn.patch
Type: text/x-diff
Size: 15098 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20130622/41b4dab7/attachment-0001.bin