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.