[Kolab-devel] Hosting multiple domains

[Jeroen van Meeuwen]

On Wednesday, March 27, 2013 10:40:08 AM Timotheus Pokorra wrote:
> Hello all,
> 
> let me introduce myself first: My name is Timotheus Pokorra, and I now
> work for TBits in the south of Germany.

Hi Timotheus,

a pleasure to make your acquaintance ;-)

> I have had contact with the Kolab project already 10 years ago, I have
> written my diploma thesis about Exchange alternatives
> (http://www.pokorra.de/groupware/howto/kolab_toltec.html)
> I am glad that Kolab has developed and improved steadily over the
> years, and I am already enjoying to work with TBits who are hosting
> Kolab for many customers.
> 
> As the task of migrating from Kolab2 is now on me, I have written this
> blog post about support for multiple domains in Kolab3:
> http://www.tbits.net/tbits-opensource/kolab3multipledomains.html
> It is based on the Administrators Guide and various blog posts and
> mailing list posts. Thanks for that!
> I have tried to put the instructions into scripts that can be executed
> easily from the command line.
> 
> You find the code linked to my solution in this gist:
> https://gist.github.com/tpokorra/5244642
> 
> I am looking for feedback and suggestions to improve this.
> 

First of all, I need to note that for deployments of size, cn=kolab,cn=config 
may possibly not be the best location to store the list of domain name spaces;

IIRC, it is not a database, and therefore not indexed (ACIs and relevant 
attributes included), but I could not tell you whether one might run in to 
performance issues at 1024, 2048 or at 8192 domain name spaces (or, possibly, 
not at all).

Also, again for hosted deployments of size, cn=kolab,cn=config can not easily 
be replicated across multiple LDAP servers - in case you were considering to 
set up multiple LDAP servers for redundancy / high-availability / load-
balancing.

I have therefore attempted to ensure the base DN (in which domain name spaces 
are stored) is completely configurable - one can imagine you would, instead of 
"cn=kolab,cn=config", use "ou=Domains,dc=managementdomain,dc=com". With the 
scope and search filter also being configurable, I suppose one could attempt 
to populate such with a bit more of a structure like so:

  ou=Domains,dc=mgmt,dc=com
    `- ou=kolabsys.com
        `- associateddomain=kolabsys.com
        `- associateddomain=kolabsys.net
        `- associateddomain=kolabsys.org

where the second and third objects might be made writable to a kolabsys.com 
administrator (add new domain aliases, remove existing domain aliases), 
whereas the primary domain name space (ou=kolabsys.com and the 
associateddomain=kolabsys.com) would not be writable (as they are very likely 
associated with an immutable dc=kolabsys,dc=com).

This, at least, should work fine for the Kolab daemon, and other pykolab 
components. You have obviously found that Roundcube and friends do not adjust 
themselves as automagically ;-) More on that later.

That said, I suppose this may also be a little out-of-scope ;-)

> Especially the patch to Roundcube, for support of multiple domains
> without changing the config files or requiring several hosts. I have
> not fully tested it, and I don't know the rules and conventions of the
> Roundcube project (yet).
> 

The kolab_auth plugin you are patching (the configuration of) - having only 
briefly looked at your work, as I'm just returning from a holiday - is our 
baby[1], so you're good on that front.

As you have clearly found out already, our multi-domain setup has been 
initially set up / documented against using different virtual host addresses 
(i.e. webmail.company1.com vs. webmail.company2.com).

What I would like us to be able to do, for the case where a single vhost 
serves up multiple (isolated) domain users, i.e. https://webmail.provider.com, 
is if a john at example.org were to log in;

1) We validate example.org is a locally hosted domain. I suppose an LDAP query 
would use the uid=kolab-service,ou=Special Users,dc=mgmt,dc=com credentials to 
search the domain_base_dn with the "(associateddomain=example.org)" filter.

2a) If not found, clearly we want the login attempt to fail.

2b) If one entry is found, we'll want the primary domain name space (i.e. 
"example.org" may in fact be a secondary domain name space for "example.com").

2c) If multiple entries are found (it just so happens associateddomain=bla.fo 
as well as associateddomain=fu.bar have a secondary domain name space 
"example.org", either by accident or on purpose) - I suppose we still need to 
figure out what the appropriate result would look like.

3) Using the domain name space object (it's first value of associateddomain 
would typically also be the value used in the RDN), and the "standard" root_dn 
(dc=%2,dc=%1, etc.) or a specific root_dn (i.e. o=intra,dc=example,c=de as the 
inetdomainbasedn attribute value), we can now search for the actual LDAP entry 
for the user to be logged in.

I think a large chunk of this process has been coded once before, as part of 
our little Net_LDAP3 PHP library[2], in an effort to make multi-domain logins 
available as part of the Web Administration Panel (+ API).

What I would like us to consider is how code can be made adaptive (so no 
"<?php $domain_base_dn='dc=foo,dc=bar';?>" code is needed on a per domain name 
space basis), and attempt to avoid to need to write out configuration files 
just to be able to automatically serve up a new domain name space (that was 
just created). I think this would both serve the single vhost and multiple 
vhost scenario best.

Appreciate your thoughts,

Kind regards,

Jeroen van Meeuwen

[1] http://git.kolab.org/roundcubemail-plugins-kolab
[2] http://git.kolab.org/pear/Net_LDAP3/tree/lib/Net/LDAP3.php#n819

-- 
Systems Architect, Kolab Systems AG

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

pgp: 9342 BF08