Pierangelo Masarati wrote:
Then try this:
database meta suffix "dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=north america,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=south america,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=asia,dc=example,dc=com"
uri "ldap://remote/dc=example,dc=com" suffixmassage "dc=example,dc=com" "l=europe,dc=example,dc=com"
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it
Fascinating results. An ldapsearch retrieves two entries for each query. One with the massaged dn, one with the "real" dn. The entry with the massaged dn is missing any attributes that are not in the meta server's schema. The "real" entry shows you everything (attributes not in the meta servers schema are in all caps, just like with a simple slapd-ldap backend pass-through proxy). You can bind with either the massaged or real dn, but the acis I have in place on the Sun DS server give me only anonymous rights to see attributes in the massaged entry (I can see everything I'd normally see in the entry returned with the real dn). Modifications going back up are successful, so long as the target attribute is in the meta server schema. Adds with a real dn are successful, but using the massaged dn gives you an "insufficient add privilege" error. Interestingly, the real target changes from attempt to attempt. On my first try adding a massaged dn, the target reported was from the last suffixmassage line in the config file. The next time I tried, it skipped to the first line. Of course none of the usual LDAP browsing tools works, because they can't display the tree in the way they're used to doing.
-- Phil Lembo