On 17/06/2010 22:52, Luiz Marcelo wrote:
Hello everyone. Well, I have a scenario with three LDAP servers. This scenario represents a practical structure of a multi-campus institution.
For example: Each server of each campus has the following contexts instantiated name in a backend hdb:
Campus 1: dc = a, dc = institution, dc = org Campus 2: dc = b, dc = institution, dc = org Campus 3: dc = c, dc = institution, dc = org
Each campus only manages your server, but allows that queries to other remote servers. They must present themselves as a single directory, transparent to user queries. I tried using the backend target with the suffix dc=institution,dc=org to perform a masking of the name. In practice the target backend (server instantiated in the campus) is like this:
database meta suffix "dc=institution,dc=org"
uri "ldap: / / localhost /dc=a" idassert-bind bindmethod=simple binddn="cn=reader,dc=a" credentials="readera" rebind-as-user yes suffixmassage "dc=institution,dc=org" "dc=a"
# Remote Server - b uri "ldap: / /10.0.0.2/dc=b" idassert-bind bindmethod=simple binddn="cn = reader,dc = b" credentials = "leitorb" rebind-as-user yes suffixmassage "dc=institution,dc=org" "dc=b" lastmod off
# Remote server - c uri "ldap: / /10.0.0.3/dc=c" idassert-bind bindmethod=simple binddn="cn=reader,dc = c" credentials = "leitorc" rebind-as-user yes suffixmassage "dc=institution,dc = org" "dc=b" lastmod off
When performing a general consultation to dc=institution,dc=org all data from the three campuses were merged and the query returned. example: ldapsearch -x -D cn=reader,dc=a -W -b dc=institution,dc=org "cn=reader "
the result is: cn = reader, dc = institution, dc = org cn = reader, dc = institution, dc = org cn = reader, dc = institution, dc = org
3 results appear, each encontraddo in three different bases. The problem is that have the same DN.
Assuming that this structure is used to authentication user and a user can log in at any institution, be it home or away, if any two users with uid=john (eg: uid=john,dc=a and uid=john,dc=b) when performing a search using the meta backend, duplicate the results appear.
Why do you not just ajust the suffixmassage configuration so that dc=a is rewritten to be dc=a,dc=institution,dc=org ? This way, a search for cn=reader will return 3 different DNs.
This is fine for authenticating users in several domains, each account has a unique DN, while a search will return as many as possible. Or is there something I missed in your explanation?
Better than that, why not just use an sub-naming context in each domain's directory, so that dc=a is actually dc=a,dc=institution,dc=org?
Someone with experience in using the meta backend, give me a hint how to implement this scenario without causing an Replication DNs? Suddenly a way to make the server does not store a new entry if it is equal to an existing (masquerading under the proxy target)?
The main objective of this implementation is to implement a distributed model that guarantees 1 - administrative independence for each campus (just write in your base, but read all) 2 - Allow users to authenticate to the system, inside or outside their home institution.
Finally, it would be possible to use the backend relay, after which the main role of the backend?
Thanks in advance. Luizmarceloo!