[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldap structure for multi domain.tld email hosting
On Thu, Aug 29, 2002 at 11:35:22AM -0700, Gary C. New wrote:
> >
> > | I am attempting to setup an email hosting solution
> > | with postfix, cyrus-imap, and openldap that will
> > | support several of my current clients and those
I have recently been working on a very similar project, though I am
using exim rather than postfix as I find it easier to control.
> I previously outlined a few of the basic attributes
> that will be needed per ldap entry, but for security
> purposes would it be better to separate each client
> company's entries per an organizational unit?
As the client is probably an organisation in its own right, it may be
better to use 'o' rather than 'ou' to name them. I started out that
way, but later changed to using associatedDomain as the RDN, as that
cuts out one search during the mail routing process. It also makes the
structure slightly easier for admins to follow as they will probably
be thinking in terms of domain names rather than customer names.
If you want to expose the LDAP directory for 'white-pages' searching then
it may be best to put the client domains in the directory under their
'proper' names. (e.g. The Example Organisation might be under
dc=example,dc=org rather than under
associatedDomain=example.org,ou=clients,dc=myname,dc=com).
Unfortunately this makes life more difficult for your mail routing
software as it does not have a single easy search base.
> Wouldn't this better segment the entries and allow a
> distinct per organizational unit address book list?
I would certainly recommend giving each client/domain its own part of
the hierachy. For one thing, it makes access-control easier.
> This would further allow me to continue my use of the
> uid attribute (which I believe is required for SASL
> authentication) rather than being forced to use the
> mail=user@domain attribute in a single group. Any
UIDs for authentication are one of the difficult areas. If you go for
simple UIDs with no structure in them then they must be unique across
your whole service. This tends to mean one of two things:
UIDs must be mechanically generated in such a way that they
are guaranteed to be unique. People may not like the UIDs that
result, but they do not appear in mail addresses so once
configured into client mailers they need not be seen again.
OR access-control must allow all client admins to search
across all other client domains to verify uniqueness.
This allows people to choose their UIDs, but it is a
first-come-first-served system and something still has to
enforce the uniqueness requirement: the LDAP server won't.
Using the complete mail address as the UID is another possibility, but
I suspect this will not work well with the Cyrus mailstore.
> idea how I might tie a mailling list to a client
> company's group? I guess my real problem, at the
> moment, is the fact that I don't know how ldap's
> default attributes work (i.e., o=, ou=, objectclass).
You need to understand a bit about objectClass before starting to play
with schema, otherwise you can paint yourself into a corner. I would
strongly advise that you use the 2.1 series of OpenLDAP servers and
always load data through ldapadd/ldapmodify - this makes sure that you
are not breaking any schema rules.
> This is how I currently picture the structure in my
> mind (a kind of 2 tier then flat model):
>
> -- company1
> rootdn -- company2 -- user1 -- user2 -- user3
> -- company3
I assume the users are all on a level there, rather than one under the
other :-)
> As always, comments and suggestions are appreciated
> (especially ldif examples).
misc.schema contains some mail routing stuff that you may want to look
at. It derives from an expired Internet Draft, but I believe the
structure defined there is in use with Sendmail in some places.
I started using misc.schema, but found that it had certain restrictions
that did not meet my needs (e.g. some attributes being marked SINGLE-VALUE
when I wanted to allow multiples). As a result I have swapped to using
a 'Virtual Domain Manager' schema of my own. This is still a work in
progress, but I append the schema file in case it helps. As always with
schemas, if you need to change the definitions you should assign your
own OIDs and names to anything you change to avoid confusion later.
My plan is to use LDAP to store the data and to do basic access
control, but only to allow updates through a purpose-built web
interface which will also enforce some of the rules that a straight
LDAP server cannot express. I now have this working at an alpha-test
level.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| www.skills-1st.co.uk +44 1628 782565 |
-----------------------------------------------------------------------
# vdm.schema
#
# LDAP Schema entries for Virtual Domain Manager
#
# Andrew.Findlay@skills-1st.co.uk
# August 2002
#
# $Id: vdm.schema,v 1.4 2002/09/04 13:17:28 ajf Exp ajf $
# Partially based on draft-lachman-laser-ldap-mail-routing-02.txt
# which has long since expired
#
# Intended to be used with a structure of the form:
#
# .... VDM root .
# +- associatedDomain=example.com .
# | + uid=u3427
# | + uid=u7563
# |
# +- associatedDomain=my.example.org .
# | +- cn=Fred Smith
# | +- cn=Ann Jones
#
# ^ ^
# vdmDomain objects vdmAccount objects
#
# The vdmDomain objects should be named with the associatedDomain attribute
# and should have structural objectClass 'organization'.
#
# The vdmAccount objects can be named using any legal attribute(s) and
# are likely to have structural objectClass 'person' or 'organizationalRole'.
#
# User authentication is done by a subtree search from the VDM root
# looking for a match on 'uid'. Binding as the entry found then validates
# the user credentials.
#
# Mail routing proceeds as follows for incoming address LHS@RHS
#
# 1) Verify that RHS is one of our domains by one-level search
# for associatedDomain=RHS under the VDM root.
#
# 2) Search for vdmMailLHS=LHS under associatedDomain=RHS,<VDM root>
# to obtain account entry.
#
# 3) If account entry contains one or more vdmMailRoutingAddress
# attributes, these replace LHS@RHS and routing starts again from
# the top.
#
# 4) If account entry contains a uid attribute, mail is delivered
# locally to that account (which may be a mailstore-only account -
# it does not have to be an operating system account)
#
# 5) Perform steps (2) and (3) with '*' in place of LHS to provide
# a default mail recipient.
#
# 6) If mail still not routed, look for a vdmSubstituteDomain attribute
# in the domain entry associatedDomain=RHS,<VDM root> - if found,
# replace RHS with the value and re-start routing from the top.
# This allows any LHS@domain1 to be routed to LHS@domain2 thus
# making the domains effectively equivalent.
#
# 7) If none of the above match, then mail routing fails and the
# address may optionally be passed to a different algorithm
# using different data sources for further processing.
########################################################################
# Attribute types
########################################################################
attributetype ( 1.2.826.0.1.3458854.0.1.1.1
NAME 'vdmMailLHS'
DESC 'Left-Hand-Side of RFC822 email address of this recipient'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
attributetype ( 1.2.826.0.1.3458854.0.1.1.2
NAME 'vdmMailRoutingAddress'
DESC 'Where to send mail for this recipient'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
attributetype ( 1.2.826.0.1.3458854.0.1.1.3
NAME 'vdmSubstituteDomain'
DESC 'Domain to substitute for the one supplied in a mail address'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
SINGLE-VALUE )
attributetype ( 1.2.826.0.1.3458854.0.1.1.4
NAME 'vdmDomainManager'
DESC 'Name of the person who owns or manages this domain'
SUP name )
########################################################################
# Object Classes
########################################################################
objectclass ( 1.2.826.0.1.3458854.0.1.0.1
NAME 'vdmAccount'
DESC 'Account in the Virtual Domain Manager system'
SUP top AUXILIARY
MAY ( vdmMailLHS $ vdmMailRoutingAddress $ uid $ userPassword $
mail $ mailPreferenceOption ) )
objectclass ( 1.2.826.0.1.3458854.0.1.0.2
NAME 'vdmDomain'
DESC 'Domain in the Virtual Domain Manager system'
SUP top AUXILIARY
MAY ( vdmSubstituteDomain $ vdmDomainManager ) )