Re: [ldapext] subtree search with glue entries

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:11 AM 6/9/2004, Jim Sermersheim wrote:
>All,
>
>Assume a server populated with these entries:
>
>dc=com (glue)
>dc=example,dc=com (context prefix)
>dc=org (context prefix)
>
>When a one-level or subtree search is rooted at the DIT root (empty RDN
>sequence)*, how should dc=com be treated?
>
>1.1) It should not be returned
>1.2) A search result reference should be generated using the superior
>referral should be returned

I would argue that since server does not hold the baseObject of the
search, it should return a referral to the server which holds it.
That server, in response to the client's search, return any objects
it holds in scope and a continuation back to this server for
dc=example,dc=com with an appropriate scope: baseObject (if original
scope was one-level) or subtree (if original scope was oneLevel).

>When a subtree search is rooted at the DIT root (empty RDN sequence)*,
>how should dc=example,dc=com (and subordinates) be treated?

The server should refer the client (using a search referral) to
a server which has superior knowledge.

>2.1) They should not be returned
>2.2) They should be returned
>
>I assume the answers are 1.1 and 2.1, but am not sure. Does anyone else
>have experience here?

Yes.  In OpenLDAP, one can configure a server to have root knowledge.
That is, to have knowledge of where all top-level naming contexts
are held.  The OpenLDAP Root Service [RFC3088] operates in this manner.

>*Note that while some LDAP servers don't support this, it is a feature
>of X.511

In LDAP, a number of implementations (including OpenLDAP, if so (mis)configured)
will treat a non-baseObject scoped search at the root ("") as a like-scoped
search at a context prefix held by the server.  The idea, I guess, is to
"friendly" or, more specifically, to avoid client configuration of an
appropriate search base (or implementation of namingContext/enhancedSearchGuide
discovery).

Because of this, it makes build any kind of "global" directory quite
difficult.  (There are, of course, other reasons why building "global"
directories is difficult.)

Kurt 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext