[Date Prev][Date Next] [Chronological] [Thread] [Top]

[ldapext] when is manageDsaIT needed for the root DSE?



>From my read of X.501 (and others) is that the ManageDsaIT control is
required to read and update the root DSE. If this is the case, LDAP has
explicitly overriden that requirement by allowing a specific search
operation* to read it, and implies that it may be updated without the
use of ManageDsaIT.

It seems obvious to me that when a wholeSubtree or singleLevel scope
search has an empty base, that a referral is returned when the DSA is
not a first-level DSA (if ManageDsaIT is not used). I also assume that
an add of an object immediately subordinate to the root will also cause
a referral when ManageDsaIT is not used on a anon-first-level DSA.

I don't know what the behavior of a variant of the specific search
operation* where a differnt filter is used should be. I also don't know
what the behavior of compare should be.

I'm trying to reconcile this with the distributed procedures document.
It currently says:
If a DSE held by a DSA meets all of the following criteria, it is said
to be local to that DSA:
- It is or falls (hierarchically) under and administrative point.
- it is a DSE of any of the types:
  - root
  - cp
  - entry
  - alias
  - subentry

Well, the root never falls under (nor is to my knowledge) an ap, so I
should just remove it from the list. But for LDAP, it seems some
exeption needs to be made for at least the specific search operation*,
and maybe an exception for the modify operation on the empty DN.

Or is my initial assumption just wrong? 

* The specific search operation is where the scope is baseObject, the
base is empty, and the filter is (objectclass=*).

Thanks for any clarification.

Jim

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