[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] when is manageDsaIT needed for the root DSE?
Hi Steven,
Could you please tell me where in the X.500 documents this root DSE is described?
Ron
-----Original Message-----
From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On
Behalf Of Steven Legg
Sent: Friday, 24 September 2004 10:35
To: Jim Sermersheim
Cc: ldapext@ietf.org; Kurt@OpenLDAP.org
Subject: Re: [ldapext] when is manageDsaIT needed for the root DSE?
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" <Kurt@OpenLDAP.org> 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" <Kurt@OpenLDAP.org> 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
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
>
>
> _______________________________________________
> 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
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext