Subject: [ldapext] Subentries as children of the root

From: "Jim Sermersheim" <[email-masked]>
Date: Sat, 06 Nov 2004 11:06:07 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 8 Nov 2004 15:13:57 +1100

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: [email-masked] [mailto:[email-masked]]On
Behalf Of Jim Sermersheim
Sent: Sunday, 7 November 2004 05:06
To: [email-masked]
Cc: Steve McLain
Subject: [ldapext] Subentries as children of the root

Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 07 Nov 2004 22:00:17 -0700

>>> "Ramsay, Ron" <[email-masked]> 11/7/04 11:13:57 PM >>>
>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. 
 
Referring the request is needed to service the intended operation.
X.511, Clause 10.2.2 is clear that one may perform a subtree search from
the tree root using an empty base. If a non-first-level DSA receives
such a request, it must refer up (the sender wants the search to apply
to the entire tree). I could be (and suspect I am) wrong about the root
being returned on a first-level DSA in absence of ManageDsaIT.
 
>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).
 
I would shy away from saying "ManageDsaIT allows access to metadata".
Lots of things can be considered to be metadata (stuff in subentries for
example). Also, "the actual entry" is misleading. A locally held DSE
(which happens to be of type xr) is still an "actual entry" and an
"entry", it's just not the object entry. I prefer the definition in 2.1,
or maybe the revised:

"ManageDsaIT is required to access local DSEs not part of any locally
held naming context"

>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.
 
You may be right in saying that an object named cn=schema cannot be a
subentry, and that root is never an admPoint (though I'd like to see
evidence supporting these assertions), but certainly root can be (and
often is) a supr.

Jim

-----Original Message-----

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).

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.

id-ar-subschemaAdminSpecificArea. Is it legal, on a non-first-level
DSA

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).

Jim