RE: [ldapext] Subentries as children of the root

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

1) I would never expect the root DSE to be returned in a subtree search from the root, so I don't see the business of referring the request to a first-level DSA as relevant. A base-object search I would expect to return an error unless the manageDSAIT bit is set, when it would perform the reqest locally. I don't believe there is any DSA that can hold a global root DSE. But I have no authority for this statement.

2.1) Surely, accessing a xr DSE using manageDSAIT will return the reference and not the actual entry. That is, manageDSAIT allows access to metadata, not privileged access to the entry (which is remote, so how could it, unless it chained it, but you wouldn't expect manageDSAIT to act in this manner).

3) But cn=schema is not a subentry! At this point there is no correlation between LDAP and X.500. I don't believe the root can be either supr or admPoint.

Just my $0.02 worth.

Ron

-----Original Message-----
From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On
Behalf Of Jim Sermersheim
Sent: Sunday, 7 November 2004 05:06
To: ldapext@ietf.org
Cc: Steve McLain
Subject: [ldapext] Subentries as children of the root


A little over a month ago, in the thread "when is manageDsaIT needed for
the root DSE?" I failed to take the next logical step in discussing what
it means for the rootDSE to be treated as a non-local object. I actually
have a few observations:
 
1) The root isn't *always* treated as non-local. If one uses the empty
RDN sequence for a search base and a scope of wholeSubtree, they will
get referred up until they are talking to a first-level DSA. Then the
search will progress down the tree structure (See X.511, Clause 10.2.2).
In X.511, it doesn't matter what the scope (subset) is. I infer that
when the scope is baseObject proper X.500 DSAs will refer unless it's a
first-level DSA, in which case the rootDSE is NOT treated as non-local,
and may be returned (I would appreciate feedback here if I'm wrong).

1.1) (aside) In LDAP, if the scope is baseObject, and the filter is
(objectclass=*), ManageDsaIT is assumed, and the rootDSE is returned.

2) We typically see that a DSE below a non-local entry is itself glue,
cp, or xr. Essentially, if a DSE immediately subordinate to a non-local
DSE is not a cp, ManageDsaIT is required to access it.

2.1) A different way of putting it (which produce different semantics)
is that ManageDsaIT is required to access DSEs not part of any locally
held naming context. This definition says that ManageDsaIT is always
required to read the root object (even on first-level DSAs)

3) Many LDAP servers advertise a schema subentry immediately
subordinate to the root (i.e. cn=schema). To me, this says that the
rootDSE is an admPoint and it's administrativeRole attribute is set to
id-ar-subschemaAdminSpecificArea. Is it legal, on a non-first-level DSA
for the rootDSE to be supr, admPoint, and root?

4) Assuming I'm correct on 1 and 2, and assuming people are not marking
their subschema subentries as being a cp, then I assume ManageDsaIT is
required to read these schema subentries (unless one is accessing a
first-level DSA). This also means, that a wholeSubtree search from the
root of the tree with the search subentries control present, and the
ManageDsaIT control not present will return the root schema subentry for
the first-level DSA, but no others (assuming these DSAs all have a
schema subentry immediately subordinate to the root).

4.1) If 2.1 is more correct than 2, then ManageDsaIT is consistently
required to read subentries immediately subordinate to the root.

Or am I missing something that says "a subentry which is not part of a
local naming context does not require ManageDsaIT to be read"?

Jim

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


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