[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: subschemasubentry attribute usage in rootDSE
Date forwarded: Fri, 25 Jun 1999 04:16:04 -0700 (PDT)
From: hahnt@us.ibm.com
Send reply to: hahnt@us.ibm.com
To: ietf-ldapext@netscape.com
Date sent: Fri, 25 Jun 1999 07:12:15 -0400
Subject: subschemasubentry attribute usage in rootDSE
Forwarded by: ietf-ldapext@netscape.com
> Hello,
Timothy,
You are correct. This is indeed a bug. The intent is as follows:
Each entry contains a single pointer to the subschema subentry that
controls it. This attribute is single valued, as an entry can only be
controlled by a single subschema subentry. This is part of the X.501
model, and is there to ensure that an entry is not controlled by
multiple conflicting subschema definitions (remember the recent
debate about MS's top object class) and also it is more efficient than
having to retreive subschema definitions from multiple places in the
DIT to work out what actually controls this entry. (Access controls on
the other hand are different in X.501, as multiple access control
subentries can control access to a single entry, and there are pre-
defined rules for working out the results of conflicting permissions).
This is how the subschema bug probably arose. In X.501 it is very
clear how to find the subschema subentry when navigating down
from the root of the DIT - it is immediately below an administrative
point. LDAP does not have/know about administrative points, so
instead, a pointer was stuck in the root DSE to point to the
subschema subentry. But here is where the problem comes. A
directory server can have multiple administrative domains (easily
solved in X.501 by having multiple administrative points each with a
subschema subentry beneath it) but in LDAP servers this will cause
multiple pointers to be added to the single valued
subschemaSubentry attribute in the root DSE (which is impossible
of course). The reason no-one has noticed the bug until now is
probably because everyone running pure LDAP servers is only
holding information from a single management domain, and
therefore only needs a single pointer to subschema definitions in the
root DSE.
The solution is quite simple, and it is this. Define a new attribute type
for top, with exactly the same syntax as now, but make it multiple
valued. Lets call it:
subschemaSubentries
Then we have the single valued attribute in each entry, and a
multiple valued attribute in the root DSE
David
>
> In reading RFC 2251 and RFC 2252, I have stumbled across a question
> regarding the use of the subschemasubentry attribute type.
>
> RFC 2251, in section 3.2.1, indicates that every entry mastered by a
> server will have an attribute type included within it called
> subschemasubentry. This attribute type's value will be a distinguished
> name that 'points to' the subschema entry in the namespace that describes
> the schema for which the entry conforms to. Quoting the RFC:
>
> - subschemaSubentry: the Distinguished Name of the subschema entry
> (or subentry) which controls the schema for this entry.
>
>
> RFC 2252 in section 5.1.5, indicates that the subschemasubentry attribute
> type is SINGLE-VALUE. Quoting the RFC:
>
> 5.1.5. subschemaSubentry
>
> The value of this attribute is the name of a subschema entry (or
> subentry if the server is based on X.500(93)) in which the server
> makes available attributes specifying the schema.
>
> ( 2.5.18.10 NAME 'subschemaSubentry'
> EQUALITY distinguishedNameMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
> SINGLE-VALUE USAGE directoryOperation )
>
>
> Later on in RFC 2251, Root DSE is described in section 3.4. In this
> section, it
> seems that a slightly different use of subschemasubentry is described.
> Quoting the RFC:
>
> - subschemaSubentry: subschema entries (or subentries) known by this
> server.
>
> Now my question: The plurarlity in the sentence about subschemasubentry
> in the Root DSEsection of RFC 2251 implies that this attribute type is
> multi-valued in the Root DSE. Is this the intent? Is it the intent of
> the RFC that the subschemasubentry attribute type be allowed to be
> multi-valued when contained in the Root DSE, regardless of its definition
> as being SINGLE-VALUE as defined in RFC 2252?
>
> Thanks in advance for this clarification,
> Tim Hahn
>
> Internet: hahnt@us.ibm.com
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388 tie-line: 8/852.6388
> fax: 607.752.3681
>
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
*NEW* Mobile +44 790 167 0359 *NEW*
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************