[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Building a Distributed LDAP tree with replication.

On Tue, Oct 03, 2006 at 11:28:31AM -0300, sebastien Prouff wrote:

> I have a conception problem with my LDAP and would like to have your opinion.
> I have to built a LDAP tree.
> About 10000 LDAP entry.

It's not many.

> These are the points :
> - the directory service must be distributed on several sites
> - the sites are geographicaly distant and a have internet satellite connexion between 
> the deported sites and the central site.
> - In 12 month, I will have 25 sites to maintain.
> - I want to delegate the directory support on each site.
> - I want to get the whole LDAP tree on the main site.

I recommend using one provider server with DIT dc=example,dc=org,
contains two subtrees -- dc={a,b},dc=example,dc=org and fine
configured ACLs to this subtrees. And replication to all sites (up to
you -- all tree, or just sub-tree). Also, I recommend use fresh
release from 2.3.XX (now it is 2.3.27) and syncrepl.

> Why?
> /I want to delegate the directory support on each site./
> - Because each site is a Samba Controleur for the XP PC. So information must be first 
> upgrade on the distant site and replicated on the main site.

Use smbldap-tools for setup master (for change passwords), and
"regular" for authorization.
Also, you can use slapd-meta(5), insteed smbldap-tools.

> - Because of delegation also. I can't be the administrator for each branch

Just setup ACL for every subtree on main site.

> /I want to get the whole LDAP tree on the main site.
> /Because we want to offer a mail service for the whole tree. The mail server will be 
> in the main site.
> The users will be created on the distributed site by the local administrators and 
> these informations replicated on the main site.
> By this way the mail server will look on the main LDAP server to authentificate users.

If you are use cyrus-imapd + saslauthd (builded with ldap support) --
See details in saslauthd documetation. At least, you can use
mail-accounts look like user1@a, user2@b. Also, you can try to use
scope=sub and short names -- user1, user2, ..., but in this case you
can get confict:
uid=user1,dc=a,dc=example,dc=org and

For exclude this conflict you can use slapo-unique(5) overlay. But it
can correct used only with my architecture (one provieder, many
subscribers). If you have many providers, you can get situation, when
local admins create accounts uid=user1,dc=a,... and uid=user1,dc=b,...
and conflict will be found only when user1,dc=b will try to access to
his mail.

Dmitriy Kirhlarov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7247 ext.208 F:+7 495 105 7246 E:DmitriyKirhlarov@oilspace.com
OILspace - The resource enriched - www.oilspace.com