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

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 23 Sep 2004 18:11:26 -0600

Thinking more about the alias thing; an alias should be allowed to point
to a glue DSE. I couldn't find anything in X.501 that said an alias must
only point to DSETypes of entry or alias. Just that it points to an
object entry or an alias entry. It further confuses things when it says:
"The root is not an entry as such, but can, where convenient to do so
[e.g. in the definitions of b) and c) below], be viewed as a null object
entry [see d) below];" I assume it's not convenient to view the root as
a 'null object entry' when it's being referenced by an alias entry :-)

>>> "Jim Sermersheim" <[email-masked]> 9/23/04 4:33:56 PM >>>
True, if there is a check to validate that aliasedObjectName points to
an entry or alias DSE, this should just result in an error.

So, getting back to my original question * does anyone know if X.500
allows access to the root DSE without the use of ManageDsaIT?

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 9/23/04 3:33:34 PM >>>
At 02:16 PM 9/23/2004, Jim Sermersheim wrote:
>I can reconcile some things, but not others. It's the inverse that is
the problem * in the absense of manageDsaIT, when is the root to be
treated as a normal object?
>
>I *think* X.500 says never, and LDAP special cased read, and sort of
left the door open for special casing write.
>
>I was hoping that an X.500 vendor with an LDAP front-end could clarify
(as they would have implemented the X.500 semantics, and the LDAP
front-end would have done something to special case where needed).
>
>Another question is: Assume an alias object <dc=TopOfTheWorld> which
has an aliasedObjectName set to the empty DN.

One could consider this invalid.  aliasObjectName is suppose to
refer an object entry (or possibly another alias entry).  Having
an alias refer to a root DSE, which is not part of the DIT,
makes no (or, at most, little) sense.

>If a base-scope search is rooted at that alias, the filter is
(objectclass=*), and derefAliases is derefFindingBaseObj, what is the
proper behavior? I think RFC 2251 could be read either way.

I would think the server would return some sort of aliasing
error here. (I believe the OpenLDAP server does.)

>What I wanted to do with the distproc I-D was give a simple, straight
forward way of determining whether a DSE reresents a normal object (in
the absense of manageDsaIT). 
>
>Jim
>
>>>> "Kurt D. Zeilenga" <[email-masked]> 9/22/04 6:50:28 PM >>>
>Though I said "I disagree" over on the LDAPBIS list, in
>retrospect, I would have to minimally agree that a server
>*could* returning the rootDSE in response to subtree
>manageDsaIt search.  RFC 3296 says:
>   The control MAY cause other objects to be treated as
>   normal entries as defined by subsequent documents.
>
>While there is no subsequent document stating how this
>control would cause rootDSE to be treated as a normal
>entry, I think it reasonable that some subsequent document
>could state how.  I would hope that any such document
>would state a how consistent with X.511(97) manageDsaIt
>service.
>
>Are you able to reconcile things if you assume that
>the rootDSE is treated as a normal object in
>manageDsaIT searches with baseObject=""? 
>
>Kurt

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 23 Sep 2004 17:21:46 -0700

At 05:11 PM 9/23/2004, Jim Sermersheim wrote:
>to a glue DSE. 

I'd argue that such an alias is not pointing at the glue,
but the object/alias entry that the glue entry is providing
glue for.

---

From: Steven Legg <[email-masked]>
Date: Fri, 24 Sep 2004 11:58:41 +1000

Jim,

> a 'null object entry' when it's being referenced by an alias entry :-)

X.501 also says an aliasedEntryName "does not have to be the distinguished
name of any entry", which sort of allows the root name. An implementation
might disallow it though if it can't handle loops in subtree searches.

Regards,
Steven