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

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 23 Sep 2004 15:16:25 -0600

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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 23 Sep 2004 14:33:34 -0700

At 02:16 PM 9/23/2004, Jim Sermersheim wrote:
>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.)

---

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

Thanks Steven,

Does your implementation allow updates to attributes of the root DSE?
If so, does it allow LDAP to perform updates without ManageDsaIT?

>>> Steven Legg <[email-masked]> 9/23/04 6:34:47 PM >>>

Jim,

Jim Sermersheim wrote:

> 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?

I believe X.500 does not allow the root DSE (or any glue entry for that
matter) to
be visible except when manageDSAIT is used. This is how our
implementation works
for DAP and DSP. In LDAP we special-case a baseObject search of the
root DSE.

Regards,
Steven

> 
> Jim
> 
> 
>>>>"Kurt D. Zeilenga" <[email-masked]> 9/23/04 3:33:34 PM >>>
> 
>>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.
>>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.
>>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).

---

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

Jim,

> Does your implementation allow updates to attributes of the root DSE?

Yes. In DAP, only if manageDSAIT is used.

> If so, does it allow LDAP to perform updates without ManageDsaIT?

We allow modifies of the root DSE in LDAP with or without manageDSAIT.

Our implementation always has a root DSE, so add entry and remove entry
on the root name are disallowed. ModifyDN is disallowed for obvious reasons.

Glue entries can only be updated if manageDSAIT is used.

Regards,
Steven

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 24 Sep 2004 11:44:33 +1000

Hi Jim,

I don't understand this talk about the root DSE in X.500. I would have thought that "The root is not an entry" is clear enough? Do you have a reference to any section other than 7.4 which talks about the root DSE? I believe 7.4 is simply talking about the graph, not about the DIT.

9.7 says

"It also proves convenient to define the 'distinguished name' of the root, although this can never be the distinguished name
of an object. The distinguished name of the root is defined to be an empty sequence."

In summary, I don't believe there is any such thing as the root DSE in X.500.

Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jim Sermersheim
Sent: Friday, 24 September 2004 10:11
To: [email-masked]
Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE?

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

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 23 Sep 2004 22:06:45 -0600

Sorry Ron,

I imprecisely was referring to the X.5nn series of recommendations when
I said X.500 below. I should have said X.501.

>>> "Ramsay, Ron" <[email-masked]> 9/23/04 7:44:33 PM >>>
Hi Jim,

I don't understand this talk about the root DSE in X.500. I would have
thought that "The root is not an entry" is clear enough? Do you have a
reference to any section other than 7.4 which talks about the root DSE?
I believe 7.4 is simply talking about the graph, not about the DIT.

9.7 says

"It also proves convenient to define the 'distinguished name' of the
root, although this can never be the distinguished name
of an object. The distinguished name of the root is defined to be an
empty sequence."

In summary, I don't believe there is any such thing as the root DSE in
X.500.

Ron

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

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

>I was hoping that an X.500 vendor with an LDAP front-end could
clarify

---

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

For the record, I'm not writing any document that describes the behavior
of aliases or the allowed values of aliasedObjectName. I was just using
the example as another lever to help me understand whether (and to what
extent) LDAP has 'special cased' reads and modifies of the root DSE. I'm
trying to understand that is so I'll know how to best describe the way
in which an LDAP server discovers whether an asserted DN represents an
entry that can be normally accessed (without the use of manageDSAIT).

I think I have it now, and I think it's straight-forward except there
will have to be an exception for the read and modify of the root DSE to
be compatible with RFC 2251.

Thanks again,

Jim

>>> Steven Legg <[email-masked]> 9/23/04 8:10:25 PM >>>

Jim,

Jim Sermersheim wrote:
> I agree conceptually. But when describing the steps for determining
> suitability of the pointed-to object in technical terms, you'd kind
of
> have to say "aliasedObjectName can point to a glue DSE, but not the
root
> DSE."

Couldn't you just say that the value of aliasedObjectName cannot be
the
empty RDN sequence ?

You might be better off not saying that the aliasedObjectName *points*
to
anything, but rather that it provides a new name with which to
recommence
name resolution. The name is a reference to an entry or alias that may
or
may not exist (anywhere), and may or may not be locally represented by
either an entry DSE, an alias DSE or a glue DSE. One finds out by
doing
name resolution.

Regards,
Steven

> 
> 
>>>>"Kurt D. Zeilenga" <[email-masked]> 9/23/04 6:21:46 PM >>>
> 
> 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.
> 
>