Re: LDAP Design Help Requested

["Jeffrey T. Clowser" <jclowser@aerotek.com>]

In my own experience, some of the deciding points were where things were
maintained and how autonomous each site needed to be.  We have offices all
over north america, but most changes to our LDAP service are centralized -
either via our helpdesk, or nightly exports from our HR database.  Given that,
it made sense to create a master in one place, maintain the data there, and
replicate it out where needed.  Users hit a cgi to manage changes on the
master (like changing passwords, etc).  Local read only services - email,
communicator/outlook address books, etc can hit the local copy.

If each site maintains it's own data, it may be worth creating a common top
(say a suffix of dc=hiwaay, dc=net), and under that create "ou=<site
identifier>" with people, groups, etc under each.  Each site's LDAP server
maintains it's branch, and replicates the information to the other sites.
'Course, the thing you run into are items that are shared - say a company wide
mailing list.  This could go under something like ou=shared or pick one site
to maintain shared resources and put it there (i.e ou=Company HQ).  I've
played with this configuration on Netscape's DS, but not on OpenLDAP.

The advantage of the first is that you can keep your tree flat and it's a
simple design.  Moving users from site to site is easy (though ldap v3 should
support moving records from branch to branch).  The advantage of the second is
distributed admin - particularly if the connection between sites is expensive,
slow, or unreliable, or if politics require each site to maintain it's own
stuff.  Each site has it's own data up-to-date, while info from elsewhere may
come in when it can get sent across the network, and each site is happy they
can define their own little part of the world.

If all your services are centralized and connectivity is good - i.e., if you
have one central company wide mail server that everyone connects to, it may be
best to not bother putting replicas at each site - just have a master and (for
performance/reliability) a couple replica's located centrally. to handle
everything.  If you have an email server at each site, replicating out your
LDAP servers is probably a necessity, to keep WAN bandwidth issues from
bottlenecking your mail server (assuming, of course, your mail server is tied
to LDAP - you _REALLY_ want to do this rather than trying to constantly sync
LDAP and mail).

Stephen Anderson wrote:

> I was hoping you guys could help me decide on a high level design for my
> openldap based system.
>
> The place where I work is considering moving from ccMail to an SMTP/POP3
> based mail system.  The problem is loss of directory services.  So I piped
> up and mentioned LDAP.  So I now have to design an LDAP email directory
> service for our company.
>
> My question is this, in our company we have several sites around the
> country.  Does anyone have any idea whether it would be better to
> implement the directory service as one LDAP database that's replicated to
> all the sites, or as seperate site specific databases that can contact
> each other.
>
> the latter sounds better to me since the bulk of email is sent within a
> site, but I'm not sure how to implement the system such that users can
> seemlessly query remote site's LDAP servers for email addresses at other
> locations.  Oh, the client we are loking at using is either Outlook
> Express or Netscape's mail client.
>
> Any ideas, thoughts,ruminations, or stories would be greatly appreciated.
>
>                                        Stephen Anderson
>                                      <stephena@HiWAAY.net>