I have never tried using this referral objectclass, but wanted to comment on
one of your queries:
> ldapsearch -b "o=my org, c=gb" '&(o=other org)(c=gb)(sn=person in other org)'
> return nothing at all
It would seem to me very unlikely that any entries would match this filter,
since filters only apply to attributes of entries themselves, and not (in
LDAPv2) to attributes of their parent entries. For example, the entry
<O=my org, c=gb> would typically not match a filter of (c=gb) since C=GB is
an attribute of the parent country entry, not of the entry itself.
> Please someone prove me wrong as I have sold LDAP internally on the basis of
> being able to 'mount' directories on each other in a fashion hinted at in
> chapter 10 of the SAM. Failing that, when is this functionality likely to
> appear?
Based on my limited understanding of the SLAPD database design, I would think
that mounts in LDAP would work like mounts in UNIX: you can only mount by
adding a branch below an existing tree. In SLAPD the "mount point" needs to
be an entry in the database, and that entry needs to be subordinate to the
database base (as specified by the suffix configuration line).
I believe SLAPD ignores entries in a database which are not subordinate to
suffix.
Thus if your SLAPD had in its config file that the database suffix was
<O=My Org,C=GB>, you _could_ perhaps have a referral entry like:
dn: ref="ldap://research.myorg.co.uk/OU=Research,O=My%20Org,C=GB",O=My Org,C=GB
objectclass: referral
However any entry, no matter what the object class, whose dn did not end with
the database suffix would not be used by SLAPD, and SLAPD would just refer an
operation based at that entry to the superior (default referral).
If you wish to have two different organizations in C=GB, then you will need
at least to configure that the database suffix is c=GB
Hope this helps,
Mark Wahl, Enterprise Directory Integration
Critical Angle Incorporated