Re: [ldapext] subtree search with glue entries

["Jim Sermersheim" <jimse@novell.com>]

So if I can paraphrase: The simple answer is that since this server is
not a top-level DSA, a search based at the root should return a referral
to a higher DSA. Or am I oversimplifying it?

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/9/04 10:34:24 AM >>>
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