Dynamically mapping an LDAP tree to another LDAP tree with content-based DNs

["Giampaolo Tomassoni" <g.tomassoni@libero.it>]

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 uid@maildomain.tld 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