Re: Recommended approach for LDAP as backend for virtual domain mail hosting?

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Monday, 4 October 2010 19:47:16 Andreas Ntaflos wrote:
> Hi,
> 
> I will probably also post this to the Postfix mailing list but it is
> fundamentally an (Open)LDAP question so here goes:
> 
> Short version: What is a recommended way to set up virtual mail hosting
> based on OpenLDAP? I.e. providing mail and authentication services, like
> SMTP and IMAP, using Postfix and Dovecot, for multiple *independent
> domains* such as example.net, example.org, example.com?
> 
> I am looking for RTFMs, HOWTOs, blogs, or any experience and anecdotes
> users on this list can provide. I myself no experience designing a DIT
> in LDAP (I am more at home in Postgres) and have much learning to do.
> 
> Long version: I know such setups exist and I have found many references
> in the archives of this list but there was never a completely straigt-
> forward answer that didn't say "it depends on your requirements" or
> involve frontends/add-ons like Jamm or Phamm, which I have no interest
> in.
> 
> So the requirements are basically:
>  * Independent domains and users, i.e. john.doe@example.org is
> completely different/distinct from john.doe@example.net, even though
> both may be the same physical human being.
>   * Thus accounts in different domains must have separate passwords
> fields
>  * Groups and aliases must be possible

What specifically do you mean by groups?

>  * Performance should not be terrible, obviously

How many accounts, and what are the specs (memory, CPU speed, disk speed) of 
the hardware you will be running the LDAP server on?

>  * Applications such as Apache, Ejabberd, Wikis and Webmail clients (to
> name a few) which support LDAP authentication should be able to query
> the DIT or DITs without needing any hacks or ugly constructs (this is a
> vague requirement, I know).
> 
> Now I believe the question basically boils down to this:
> 
> Should we use multiple independent backend databases (DITs) or one large
> "hosting" database as described in [1,2]?

There are limits on the number of backend databases you can have, so for any 
hosting application, individual databases per domain will probably not be 
feasible. I would recommend a single database in most cases. What the suffix is 
is largely irrelevant IMHO. For example, there is almost no difference between 
uid=joe@example.com,dc=example,dc=com (IOW, empty suffix) vs 
uid=joe@example.com,dc=example,dc=com,o=mysitename. However, if accounts will 
have aliases on different domains, it does not make much sense to over-
complicate the structure for no benefit, uid=joe@example.com,o=mysitename would 
be fine.

> Which of the two is the better
> approach? Which is more flexible, which has less administrative or
> functional overhead?

Obviously multiple databases gives you more flexibility for more administrative 
overhead.

The advantages of multiple databases are:
-Different index settings
-Independent replication configuration
-Different access controls

If these will not provide significant benefits, the additional overhead of 
managing multiple databases (and their tuning) is not justified IMHO.

> If we use multiple DITs we probably will have to glue them together
> somehow, won't we? How would queries against multiple independent DITs
> look?
> 
> Our current setup is more like [1,2], one big hosting database. It is a
> PostgreSQL database with a few tables for virtual domains
> (virtual_mailbox_domains in Postfix), virtual users
> (virtual_mailbox_maps), virtual aliases (virtual_alias_maps) and a few
> others. It is based loosely on [3].
> 
> This works fine but now the need has arisen to see if we can migrate
> that setup to an LDAP-based one, mainly for flexibility and
> compatibility with various authentication needs: many applications and
> services provide some kind of LDAP-based authentication but are
> hopelessly overwhelmed with SQL backends, especially when the queries
> are a bit complex.
> 
> Thanks in advance!

While NSS was mentioned, I would avoid stuffing everthing through NSS, when all 
the applications you have listed so far already have direct LDAP support. 
However, if you are going to use LDAP for any "system" accounts, you may want 
to consider the DIT structure a bit more carefully than if you aren't.


Regards,
Buchan