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

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

On Thursday, 7 October 2010 21:37:30 Andreas Ntaflos wrote:
> On Tuesday 05 October 2010 10:19:37 Buchan Milne wrote:
> > On Monday, 4 October 2010 19:47:16 Andreas Ntaflos wrote:
> > > 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?
> 
> Thank you too for your reply! It is most helpful.
> 
> By group support I just mean the usual way to group users together, as
> in ou=groups,dc=example,dc=com. Users on different hosted domains
> won't/can't be in the same group, if that matters any.

But, what would you use the groups for? Authorization to specific services 
only available to specific groups?

[...]

> > >  * 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.
> 
> Ok, so a single hosting database is clearly the better approach (others
> have suggested similarly). It also seems that a DIT for such a hosting
> database doesn't have to be as complicated as I had initially thought,
> which is great.
> 
> However, when using uid=joe@example.com,o=mysitename, how would Postfix
> (or anything else) look up which virtual domains it is supposed to
> serve, i.e. virtual_mailbox_domains?
> 
> That's the one think about which I am not yet quite clear. In our
> relational database there's a simple table "virtual_domains" with a name
> and an ID for the hosted domains. Postfix only wants the key (the domain
> name) to exist when doing a lookup so a query is just a simple "SELECT 1
> FROM virtual_domains WHERE name='%s'", %s being the domain name of
> course. How would a "corresponding" LDAP query look like?

Don't try and one-to-one map an RDBMS table to an LDAP container, start by 
mapping the query to an ldap search (basedn, filter, result attributes) first.

You could use something like this:

dn: domain=domain1.example.com,dc=example,dc=com
objectclass: domain
domain: domain1.example.com

Then you would use an LDAP map with
search_base = dc=example,dc=com
query_filter = (&(objectclass=domain)(domain=%s)) 
result_attribute = domain

You may choose to have more separation, with a separate basedn for domains, 
but it isn't necessary.

But, depending on your requirements, you may need more complex schemas and/or 
layouts.

Regards,
Buchan