Dears,
I'm trying to setup openldap for a small ISP here in Italy.
The purpose of the openldap tree would be to allow for more customers (i.e.:
companies) to be registered into ldap for authentication, dns, mail and web
purposes.
The key target of the whole setup would be to allow one customer tree to be
replicated between our systems and the customer's one(s), such that they have
their own mail server in the company and may add users, mailboxes, mail
aliases. So, they must be capable to handle the thing by their own (at least
ideally).
For security purposes, however, the customer ldap db must not be the whole ISP
db, but just the part of db related to the customer itself.
In example, assume we have to trees in the ISP db:
o=Yoyodyne S.r.l., c=IT
and
o=Acme S.p.a., c=IT
They should be replicated among the ISP machines and the one installed in the
respective company, but each customer must have only their own replicated copy
of the tree, not the other customers' tree.
Also, since users are not required to be ldap experts in order to setup their
accounts, things should be simple for them, even when they own more domain. We
want to have all user mailboxes of a company tree to be available in more than
a mail domain (sort of domain aliases) by adding an "associatedDomain"
attribute in the company's root node for each mail domain our systems must
serve in the behalf of the company itself.
This way, replication seems easy to achieve: we spare a single db for each
customer tree. It should work.
The problem is that many services (MTA and pam-ldap, in example) can only
perform very simple searches based on a specific dn. Since the ISP servers
"see" more trees, it seems we have to find a way to "merge them toghether".
Also, we would like to have not too much config differences between our servers
and the one(s) at the customer site, so this feature should be present into the
customer server(s) too. This may also be useful in case a big customer wants to
break its single organizational entry in more organizationaUnit-s, or in
l=city, o=Acme S.p.a., c=IT and have a system in each location, everyone
replicating to one in their headquarters and with the ISP.
To me, all this turns out to be resolved by creating a "special", dynamic tree,
say "o=localSystem", containing some OUs with aliased entries referring all the
users, mailboxes, aliases and so on available in a specific iana domain.
For example, let assume we have the following objects in the ISP tree:
dn: o=Yoyodyne ISP S.r.l., c=IT
objectClass: top
objectClass: organization
objectClass: domainRelatedObject
o: Yoyodyne ISP S.r.l.
associatedDomain: yoyodyne.it
dn: cn=Mario Rossi, o=Yoyodyne ISP S.r.l., c=IT
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: Mario Rossi
sn: Rossi
givenName: Mario
uid: mario
uidNumber: -1
gidNumber: -1
homeDirectory: $HOMES/yoyodyne/rossi
userPassword: whatever
and the following ones in a customer tree:
dn: o=ACME S.p.a., c=IT
objectClass: top
objectClass: organization
objectClass: domainRelatedObject
o: ACME S.p.a.
associatedDomain: acme.it
associatedDomain: acme.com
dn: cn=Antonio Bianchi, o=Yoyodyne ISP S.r.l., c=IT
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: Antonio Bianchi
sn: Bianchi
givenName: Antonio
uid: mario
uidNumber: -1
gidNumber: -1
homeDirectory: $HOMES/acme/bianchi
userPassword: whatever
In the ISP systems, under the tree:
ou=MailDomains, o=localSystem
I would like to see:
dn: dc=yoyodyne.it, ou=MailDomains, o=localSystem
objectClass: top
objectClass: dcObject
objectClass: alias
dc: yoyodyne.it
aliasedObjectName: o=Yoyodyne ISP S.r.l., c=IT
dn: dc=acme.it, ou=MailDomains, o=localSystem
objectClass: top
objectClass: dcObject
objectClass: alias
dc: acme.it
aliasedObjectName: o=ACME S.p.a., c=IT
dn: dc=acme.com, ou=MailDomains, o=localSystem
objectClass: top
objectClass: dcObject
objectClass: alias
dc: acme.com
aliasedObjectName: o=ACME S.p.a., c=IT
This would be useful both for e-mail purposes and for authentication ones
(since users do authenticate with the [EMAIL PROTECTED] principals). Postfix
can be configured to perform the ldap search starting from a dn containing the
destinating mail domain, so it should work. pam-ldap shouldn't have anything
too much close to this, but in the worst case it shouldn't be too much
difficult to extend the pam-ldap functionalities with username/domain splitting
code.
The problem is that the dc= component in the dn of these objects should be
something that is dynamically created from each associatedDomain attribute of
the "o=company, c=IT" hierarchy. I first started studying the back-ldap and
back-meta backends to do this, but I got the feeling that these backend can at
most just rewrite the dn component of a tree, not build a dn based on the
content of a second (not acme.it, nor acme.com, in example, is in the dn of
o=ACME S.p.a., c=IT).
I tried also to do this with back-perl. I made a perl module attempting an LDAP
connection through Net::LDAP, but it seems that Net::LDAP woun't work from
inside slapd.
So, is there a dynamic backend capable of this? Am I completely wrong in my
approach to the problem? Do you see any other solution to this?
Thanks,
-----------------------------------
Giampaolo Tomassoni - IT Consultant
Piazza VIII Aprile 1948, 4
I-53044 Chiusi (SI) - Italy
Ph: +39-0578-21100
