[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[no subject]
Greetings,
Internet Drafts publisher: please publish this as an individual submission.
LDAP-ext and IETF-else members: I welcome your comments on this individual submission.
Regards,
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
Internet Draft T. Hahn
Document: draft-hahn-schemapart-00.txt IBM
Expires: January 2002 July 2001
Approach for identifying different schemas in effect across a
Directory Name-space
1. Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
2. Abstract
IETF RFC 2251 [RFC2251] provides a mechanism for indicating, given
any particular entry in the directory tree, what entry in the
directory tree holds the directory schema information for that
particular entry. RFC 2251 does not, however, provide guidance on
how different directory servers, each of which might have their own
active directory schema, should ?publicize? this directory schema
such that the different active schemas are distinct from one another
when viewing the entire directory name-space. This document
describes a way to name sub-schema sub-entry entries such that
different active schemas can be distinguished from one another
across the entire directory name-space.
Hahn Expires January 2002 [Page 1]
Identifying multiple schemas
3. Table of Contents
1. Status of this Memo............................................1
2. Abstract.......................................................1
3. Table of Contents..............................................2
4. Conventions used in this document..............................3
5. Review of RFC 2251 and RFC 2252 definition of subschemasubentry3
6. Contents of subschemasubentry..................................3
7. Method of naming subschemasubentry entries as distinct from one
another............................................................4
7.1. Potential problems with ambiguous subschemasubentry values..4
7.2. Subschema sub-entry is really an administrative element.....5
7.3. Subschema sub-entry entries as ldapSubEntry entries.........6
8. Summary........................................................8
9. Security Considerations........................................8
10. References...................................................9
11. Copyright Notice.............................................9
12. Author's Address.............................................9
Hahn Expires January 2002 [Page 2]
Identifying multiple schemas
4. Conventions used in this document
In this document, directory entries will be described using LDAP
Data Interchange Format (LDIF). See RFC 2849 [RFC2849] for details
on LDIF.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
5. Review of RFC 2251 and RFC 2252 definition of subschemasubentry
In RFC 2251 and RFC 2252, an operational attribute was defined
called subschemasubentry. This attribute can be requested from any
entry in the directory tree. When requested, the attribute?s value
will be a distinguished name which ?points to? another entry in the
name-space. The entry ?pointed to? contains the definition of the
directory schema which controls that entry.
While this allows the schema that controls an entry to be found
given any entry in the name-space, it does not give guidance on how
servers that manage multiple ?active schemas? or multiple servers
would make their active schemas appear ?unique? from other schemas
that are active in the name-space.
Based on implementation experience, the distinguished names that
have been chosen for the subschemasubentry have ranged from fixed
names such as ?cn=schema? to names relative to the namingContexts
attribute values in the root DSE entry such as ?cn=schema, o=Your
Company, c=US?. It is clear that to promote interoperability and
organization of the directory name-space (within single servers and
across multiple server environments), more specification of how to
name the subschema sub-entry entries is required. If multiple
servers name their schema ?cn=schema? and each subschema sub-entry
is different from one another, applications which access data in
each of those servers will have difficulty determining which
?cn=schema? entry is in effect for the name-space. This problem is
further confounded with the use of LDAP referrals where the LDAP
server on which a request originates may not be the server on which
the request is processed.
This document will provide a means of naming subschema sub-entry
entries such that each ?active schema? has a unique name in the
directory name-space.
6. Contents of subschemasubentry
RFC 2251 provides a description of the attributes which should be
contained in the subschemasubentry entry. These attributes are
?attributetypes?, ?objectclasses?, ?ldapsyntaxes?, and
?matchingrules?. Implementation experience has shown that
implementers have added additional attributes including attributes
that further define attribute type definitions as well as attributes
Hahn Expires January 2002 [Page 3]
Identifying multiple schemas
to describe naming formats and structure rules. The definition of
the subschema sub-entry entry in RFC 2251 has its roots in the X.500
directory model and its definition of a sub-entry which defines the
schema for an area of the directory name-space.
A few implementations have named the subschema sub-entry entries
based on the tree of information that is controlled by that schema.
In these implementations, the subschema sub-entry is also defined as
an object class that is derived from the X.500 ?subentry? object
class. The ?subentry? object class has since been modeled in LDAP
schema as a ?ldapSubEntry? object class [LDAPSUBENTRY].
By using the ?ldapSubEntry? construct coupled with the notion that
different portions of the directory name-space may be controlled by
different schemas, we can define a mechanism for uniquely naming
subschema sub-entry entries across single and multiple server
environments.
7. Method of naming subschemasubentry entries as distinct from one
another
7.1. Potential problems with ambiguous subschemasubentry values
RFC 2252 defines the ?subschemasubentry? attribute value. It does
not require all entries in the directory to return the same value
for this attribute. Indeed, an implementation could choose to
define a separate value for every entry in the directory name-space
it is controlling and still conform to the requirements for the
subschemasubentry attribute from RFC 2251.
Most implementations today take a ?single server? view of the
directory name-space. With this view, the choice of naming the
?subschemasubentry? entry as ?cn=schema? does not appear to cause
any difficulty. After all, if there is only one server serving the
directory, there need not be more than one schema. When multiple
servers are serving the overall directory name-space (for example,
when multiple servers are tied together using LDAP referrals
[LDAPREFERRALS], then different servers might contain different
active schemas. At this point, if all servers name their schema as
?cn=schema?, problems can arise as applications access the subschema
sub-entry. The same distinguished name refers to different entries,
depending upon the server that is contacted. If a server is
contacted through following a referral, a subsequent request to
retrieve the subschema sub-entry may not follow the referral,
causing the wrong subschema sub-entry entry to be returned to the
application.
As an example, consider two LDAP servers, server A and server B. If
server A has namingContexts in the root DSE entry of:
namingContexts: ou=Marketing, o=Your Company
namingContexts: ou=Research, o=Your Company
While server B has namingContexts of:
Hahn Expires January 2002 [Page 4]
Identifying multiple schemas
namingContexts: ou=Dept 14, ou=Marketing, o=Your Company
Further, assume that server A holds a referral to server B such that
applications which request information below ?ou=Dept 14,
ou=Marketing, o=Your Company? will be re-routed to server B for
processing.
Also assume that both server A and server B use the same
distinguished name, ?cn=schema? for the subschemasubentry attribute
value.
If an application requests the ?subschemasubentry? attribute from
?ou=Dept 14, ou=Marketing, o=Your Company? from server A, referrals
will be followed (presumably), and the value ?cn=schema? will be
returned from server B (unbeknownst to the application). If the
application then requests the subschema sub-entry from server A, it
will get the ?cn=schema? entry from server A (not from server B).
If the two subschema sub-entry entries were named uniquely, this
situation would not occur.
It is within the bounds of RFC 2251 that server A and server B use
different distinguished names for the subschema sub-entry. For
example, server A could use ?cn=schema, ou=Research, o=Your Company?
and server B could use ?cn=schema, ou=Dept 14, ou=Marketing, o=Your
Company?. If this were done, then when the application requested
the subschemasubentry attribute in the prior example, it would be
returned a distinguished name that was also in server B?s ?name-
space?. If the request for this entry was sent to server A, then
the LDAP referral which re-routed the first request to server B
would do so again, re-directing the request for the subshema sub-
entry to the server on which the schema exists.
There are two other possibilities as well: multiple servers all use
the same schema or a single server uses multiple schemas. In either
of these cases, if the subschema sub-entry entry is named uniquely
(relative to other subschema sub-entry entries that might exist in
the directory name-space) then the ?right? schema can be retrieved
unambiguously.
7.2. Subschema sub-entry is really an administrative element
The active schema (or schemas) in a directory server is (are) really
an administrative element of that server. This information, similar
to replication information or namingContext information, is related
to administering the directory server(s) and the directory name-
space(s) that those servers are serving.
As an administrative element, it seems a good fit that the subschema
sub-entry entry use the object classes and structures that have been
defined for modeling administrative elements in the directory name-
space, namely the ldapSubEntry object class defined in
[LDAPSUBENTRY]. Using ldapSubEntry also provides the notion of a
Hahn Expires January 2002 [Page 5]
Identifying multiple schemas
?span of control? for the subschema sub-entry entry, something that
has been missing from RFC 2251.
There is a slight problem today with defining only the
subschemasubentry attribute per RFC 2251. This has to do with
predicting which sub-schema subentry will be used when an entry is
added to the directory. Since the directory entry does not exist
yet, it has no subschemasubentry attribute ? thus, there is no way
to point to the subschema sub-entry entry that ?would be? used to
verify the entry?s structure during the processing of the add
operation.
Further, when found in the root DSE entry, the single-valued
subschemasubentry attribute does not refer to the schema across the
server but rather to the subschema entry that contains the
definition of the attribute types in the root DSE entry.
By using the ldapSubEntry construct, applications would get a ?hint?
regarding what subschema sub-entry ?would be? in effect when adding
an entry to the directory as the ldapSubEntry construct defines its
span of control ?downward? in the tree until an overriding
ldapSubEntry is encountered. Note that this is only a ?hint? since
the active schema could change right at the point in the directory
name-space where the new entry is being added. This could occur,
for example, when the entry at the top of a namingContext is being
added and the namingContext is located on a different server.
7.3. Subschema sub-entry entries as ldapSubEntry entries
With the justification in the last two sections, the proposal for
naming subschema sub-entry entries across the directory name-space
is to
1) define the subschema sub-entry entry to be derived from the
ldapSubEntry object class:
( 1.3.18.0.2.6.x NAME ?ldapSubSchemaSubEntry?
SUP ldapSubEntry
STRUCTURAL
DESC ?LDAP sub-entry which represents the active schema
that is in effect across a sub-tree of the directory
name-space. The subschema AUXILIARY object class
is attached to this sub-entry to reflect the schema
information.?
)
By using the ldapSubSchemaSubEntry object class above, the naming
attribute for the entry is ?cn? (per the ldapSubEntry object class).
Further, the entry should exist just below the entry at which the
subschema sub-entry starts controlling entries in the directory
name-space. Subschema entries are named in relation to the portion
of the overall directory name-space to which they apply.
Hahn Expires January 2002 [Page 6]
Identifying multiple schemas
2) recommend that directory servers use this construct to define
their subschema sub entry entries and that the ?subschemasubentry?
attribute for an entry should point to the schema that ?controls?
the entry (per RFC 2251), and that the name of the subschema sub-
entry entry should be specific to what information it controls (if
the schema only applies to information in one or a set of servers,
then the subschema sub-entry should have a name specific to that
server or set of servers).
Using the example from the previous section with server A and server
B, server A would have two subschema sub-entry entries:
dn: cn=schema, ou=Marketing, o=Your Company
objectclass: ldapSubEntry
objectclass: ldapSubSchemaSubEntry
objectclass: subschema
attributetypes: . . .
objectclasses: . . .
matchingrules: . . .
dn: cn=schema, ou=Research, o=Your Company
objectclass: ldapSubEntry
objectclass: ldapSubSchemaSubEntry
objectclass: subschema
attributetypes: . . .
objectclasses: . . .
matchingrules: . . .
There is nothing preventing server A from using the same ?active
schema? for both of these entries while ?publicizing? them at both
locations in the directory name-space.
Server B from the previous example would have a subschema sub-entry
named:
dn: cn=schema, ou=Dept 14, ou=Marketing, o=Your Company
objectclass: ldapSubEntry
objectclass: ldapSubSchemaSubEntry
objectclass: subschema
attributetypes: . . .
objectclasses: . . .
matchingrules: . . .
By basing this object class on the ldapSubEntry construct, the
active schema is presumed to be ?in effect? in the directory name-
space starting at the directory entry directly above the
ldapSubSchemaSubEntry/ldapSubEntry, until another
ldapSubSchemaSubEntry object is encountered lower in the directory
name-space.
3) define a new root DSE attribute which ?points to? the subschema
sub-entry entries that are active within that specific server (since
it is possible that multiple schemas may be active within a single
server).
Hahn Expires January 2002 [Page 7]
Identifying multiple schemas
Since multiple active schemas may exist across the directory name-
space, it would be useful for applications to be able to query the
root DSE entry in a directory server to find the names of all
?active schemas? in that server. The ?subschemasubentry? attribute
in the root DSE is not used for this purpose since this attribute
should be used to refer to the subschema sub-entry attribute which
controls the formats of the attributes used in the root DSE.
A new attribute must be defined to hold this information:
( 1.3.18.0.2.4.x NAME ?subschemasubentries?
SYNTAX distinguishedName
EQUALITY distinguishedNameMatch
DESC ?multi-valued attribute in the root DSE which points to
all ldapSubSchemaSubEntry entries that are in effect/used
on this server? )
8. Summary
This document has described the current problem of naming subschema
sub-entry entries with identical names across multiple LDAP servers
that are using different ?active schemas?. Problems can occur for
applications that are attempting to access and/or modify the
currently ?active schema?, especially when LDAP referrals are used
in the environment to build a directory name-space that spans
multiple directory servers.
This document recommends that subschema sub-entries build on the
ldapSubEntry construct to unambiguously name subschema sub-entry
entries across the directory name-space as well as provide a ?hint?
for applications in determining the ?active schema? that will be
used when a new entry is added to the directory. The name of the
scubschema sub-entry is distinct in the overall directory name-space
from other subschema sub-entries by their placement in the name-
space. In addition, this document defines a new root DSE attribute
to allow directory servers to ?publicize? the set of subschema sub-
entries that are controlling entries in the portion of the directory
name-space being served by that server.
9. Security Considerations
There are no additional security considerations introduced by the
recommendations made in this document. It should be noted that
access to and update of the active schema in a directory server
should be controlled by some means of access control to ensure that
only qualified entities are able to access and/or update the active
schema. Unauthorized updates to the active schema could cause
existing information in the directory to become unreachable.
Hahn Expires January 2002 [Page 8]
Identifying multiple schemas
10. References
[RFC2251]
M. Wahl, T. Howes, S. Kille, ?Lightweight Directory Access Protocol
(v3)?, RFC 2251, December 1997.
[RFC2252]
M. Wahl, A. Coulbeck, T. Howes, S. Kille, ?Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions?, RFC 2252,
December 1997.
[RFC2849]
G. Good, ?The LDAP Data Interchange Format (LDIF) - Technical
Specification?, RFC 2849, June 2000.
[LDAPREFERRAL]
K. Zeilenga, ?Named Subordinate References in LDAP Directories?,
Internet Draft, draft-zeilenga-ldap-namedref-03.txt.
[LDAPSUBENTRY]
E. Reed, ?LDAP SubEntry Definition?, Internet Draft, draft-ietf-
ldup-subentry-08.txt, April 2001.
11. Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
12. Author's Address
Hahn Expires January 2002 [Page 9]
Identifying multiple schemas
Tim Hahn
IBM
Bldg 256-2, Dept. C8NG
1701 North St.
Endicott, NY 13760 USA
E-mail: hahnt@us.ibm.com
Hahn Expires January 2002 [Page 10] =