Rfc 4511 pdf

When a controlValue is defined in terms of ASN. Servers list the controlType of request controls they recognize in the 'supportedControl' attribute in the root DSE Section 5. The semantics of control combinations, if specified, are generally found in the control specification most recently published.

When a combination of controls is encountered whose semantics are invalid, not specified or not known , the message is considered not well-formed; thus, the operation fails with protocolError. Where the order is to be ignored but cannot be ignored by the server, the message is considered not well-formed, and the operation fails with protocolError. Again, controls with a criticality of FALSE may be ignored in order to arrive at a valid combination.

This document does not specify any controls. Controls may be specified in other documents. Bind Operation The function of the Bind operation is to allow authentication information to be exchanged between the client and server. The Bind operation should be thought of as the "authenticate" operation.

Operational, authentication, and security-related semantics of this operation are given in [ RFC ]. This document describes version 3 of the protocol. There is no version negotiation. The client sets this field to the version it desires. This field may take on a null value a zero-length string for the purposes of anonymous binds [RFC], Section 5.

This type is extensible as defined in Section 3. Servers that do not support a choice supplied by a client return a BindResponse with the resultCode set to authMethodNotSupported.

The determination of whether a password is textual is a local client matter. The server may either wait for the uncompleted operations to complete, or abandon them. The server then proceeds to authenticate the client in either a single-step or multi-step Bind process. Each step requires the server to return a BindResponse to indicate the status of authentication. If the client did not bind before sending a request and receives an operationsError to that request, it may then send a BindRequest.

This will aid in interoperating with servers implementing other versions of LDAP. Authentication from earlier binds is subsequently ignored. This will allow the client to abort a negotiation if it wishes to try again with the same SASL mechanism. Bind Response The Bind response is defined as follows.

A successful Bind operation is indicated by a BindResponse with a resultCode set to success. Otherwise, an appropriate result code is set in the BindResponse. For BindResponse, the protocolError result code may be used to indicate that the version number supplied by the client is unsupported. If the client receives a BindResponse where the resultCode is set to protocolError, it is to assume that the server does not support this version of LDAP.

While the client may be able proceed with another version of this protocol which may or may not require closing and re-establishing the transport connection , how to proceed with another version of this protocol is beyond the scope of this document. The serverSaslCreds field is used as part of a SASL-defined bind mechanism to allow the client to authenticate the server to which it is communicating, or to perform "challenge-response" authentication.

The Unbind operation is not the antithesis of the Bind operation as the name implies. The naming of these operations are historical. The Unbind operation should be thought of as the "quit" operation. Uncompleted operations are handled as specified in Section 3. It is used to signal an extraordinary condition in the server or in the LDAP session between the client and the server. The notification is of an advisory nature, and the server will not expect any response to be returned from the client.

One unsolicited notification Notice of Disconnection is defined in this document. Notice of Disconnection This notification may be used by the server to advise the client that the server is about to terminate the LDAP session on its own initiative. This notification is intended to assist clients in distinguishing between an exceptional server condition and a transient network failure.

Note that this notification is not a response to an Unbind requested by the client. When the strongerAuthRequired resultCode is returned with this message, it indicates that the server has detected that an established security association between the client and server has unexpectedly failed or been compromised.

Search Operation The Search operation is used to request a server to return, subject to access controls and other restrictions, a set of entries matching a complex search criterion. This can be used to read attributes from a single entry, from entries immediately subordinate to a particular entry, or from a whole subtree of entries.

A server that provides a gateway to X. The semantics as described in [ X. The act of dereferencing an alias includes recursively dereferencing aliases that refer to aliases. Servers MUST detect looping while dereferencing aliases in order to prevent denial-of-service attacks of this nature.

The semantics of the defined values of this field are: neverDerefAliases: Do not dereference aliases in searching or in locating the base object of the Search. Dereferenced objects become the vertices of further search scopes where the Search operation is also applied. If the search scope is wholeSubtree, the Search continues in the subtree s of any dereferenced object. If the search scope is singleLevel, the search is applied to any dereferenced objects and is not applied to their subordinates.

A value of zero in this field indicates that no client-requested size limit restrictions are in effect for the Search. Servers may also enforce a maximum number of entries to return.

A value of zero in this field indicates that no client- requested time limit restrictions are in effect for the Search. Servers may also enforce a maximum time limit for the Search. Setting this field to TRUE causes only attribute descriptions and not values to be returned.

The 'and', 'or', and 'not' choices can be used to form combinations of filters. At least one filter element MUST be present in an 'and' or 'or' choice. The others match against individual attribute values of entries in the scope of the Search. Implementor's note: the 'not' filter is an example of a tagged choice in an implicitly-tagged module.

In BER this is treated as if the tag were explicit. If the filter evaluates to TRUE for a particular entry, then the attributes of that entry are returned as part of the Search result subject to any applicable access control restrictions.

A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, assertion values are invalid, or the assertion syntax is not supported. More details of filter processing are given in Clause 7. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule.

If a value matches for equality, it also satisfies an approximate match. If approximate matching is not supported for the attribute, this filter item should be treated as an equalityMatch. The dnAttributes field is present to alleviate the need for multiple versions of generic matching rules such as word matching , where one applies to entries and another applies to entries and DN attributes as well.

The matchingRule used for evaluation determines the syntax for the assertion value. Once the matchingRule and attribute s have been determined, the filter item evaluates to TRUE if it matches at least one attribute type or subtype in the entry, FALSE if it does not match any attribute type or subtype in the entry, and Undefined if the matchingRule is not recognized, the matchingRule is unsuitable for use with the specified type, or the assertionValue is invalid.

Attributes that are subtypes of listed attributes are implicitly included. There are three special cases that may appear in the attributes selection list: 1. An empty list with no attributes requests the return of all user attributes. A list containing only the OID "1. If "1. This OID was chosen because it does not and can not correspond to any attribute in use. Furthermore, servers will not return operational attributes, such as objectClasses or attributeTypes, unless they are listed by name.

Operational attributes are described in [ RFC ]. Attributes are returned at most once in an entry. If an attribute description is named more than once in the list, the subsequent names are ignored. If an attribute description in the list is not recognized, it is ignored by the server. Each SearchResultReference represents an area not yet explored during the Search.

Following all the SearchResultReference and SearchResultEntry responses, the server returns a SearchResultDone response, which contains an indication of success or details any errors that have occurred. Each entry returned in a SearchResultEntry will contain all appropriate attributes as specified in the attributes field of the Search Request, subject to access control and other administrative policy.

Note that the PartialAttributeList may hold zero elements. Note also that the partialAttribute vals set may hold zero elements. This may happen when typesOnly is requested, access controls prevent the return of values, or other reasons. Some attributes may be constructed by the server and appear in a SearchResultEntry attribute list, although they are not stored attributes of an entry. Continuation References in the Search Result If the server was able to locate the entry referred to by the baseObject but was unable or unwilling to search one or more non- local entries, the server may return one or more SearchResultReference messages, each containing a reference to another set of servers for continuing the operation.

In this case, it would return a SearchResultDone containing either a referral or noSuchObject result code depending on the server's knowledge of the entry named in the baseObject. If a server holds a copy or partial copy of the subordinate naming context Section 5 of [RFC] , it may use the search filter to determine whether or not to return a SearchResultReference response.

Otherwise, SearchResultReference responses are always returned when in scope. The SearchResultReference is of the same data type as the Referral. If the client wishes to progress the Search, it issues a new Search operation for each SearchResultReference that is returned. Some clients use a counter that is incremented each time search result reference handling occurs for an operation, and these kinds of clients MUST be able to handle at least ten nested referrals while progressing the operation.

Note that the Abandon operation described in Section 4. The client must individually abandon subsequent Search operations it wishes to.

The client uses this name when following the reference. Modify Operation The Modify operation allows a client to request that a modification of an entry be performed on its behalf by a server. The entire list of modifications MUST be performed in the order they are listed as a single atomic operation. While individual modifications may violate certain aspects of the directory schema such as the object class definition and Directory Information Tree DIT content rule , the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory model and controlling schema [ RFC ].

Each operation type acts on the following modification. The values of this field have the following semantics, respectively: add: add values listed to the modification attribute, creating the attribute if necessary. If no values are listed, or if all current values of the attribute are listed, the entire attribute is removed.

A replace with no value will delete the entire attribute if it exists, and it is ignored if the attribute does not exist. Due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIT have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify operation.

Whether or not the modification was applied cannot be determined by the client if the Modify Response was not received e. Servers MUST ensure that entries conform to user and system schema rules or other data model constraints.

The Modify operation cannot be used to remove from an entry any of its distinguished values, i. The Modify DN operation described in Section 4.

For attribute types that specify no equality matching, the rules in Section 2. If successful, the final effect of the operations on the entry MUST be identical. Add Operation The Add operation allows a client to request the addition of an entry into the Directory. The immediate superior parent of an object or alias entry to be added MUST exist. Upon receipt of an Add Request, a server will attempt to add the requested entry. Delete Operation The Delete operation allows a client to request the removal of an entry from the Directory.

Only leaf entries those with no subordinate entries can be deleted with this operation. This entry may or may not have subordinate entries. Attribute values of the new RDN not matching any attribute value of the entry are added to the entry, and an appropriate error is returned if this fails. If there was already an entry with that name, the operation would fail with the entryAlreadyExists result code.

Note that X. In general, clients MUST NOT expect to be able to perform arbitrary movements of entries and subtrees between servers or between naming contexts.

Compare Operation The Compare operation allows a client to compare an assertion value with the values of a particular attribute in a particular entry in the Directory. Other result codes indicate either that the result of the comparison was Undefined Section 4. Note that some directory systems may establish access controls that permit the values of certain attributes such as userPassword to be compared but not interrogated by other means. Abandon Operation The function of the Abandon operation is to allow a client to request that the server abandon an uncompleted operation.

The Abandon request itself has its own MessageID. This is distinct from the MessageID of the earlier operation being abandoned. Since the client cannot tell the difference between a successfully abandoned operation and an uncompleted operation, the application of the Abandon operation is limited to uses where the client does not require an indication of its outcome. The ability to abandon other particularly update operations is at the discretion of the server.

Clients should not send Abandon requests for the same operation multiple times, and they MUST also be prepared to receive results from operations they have abandoned since these might have been in transit when the Abandon was requested or might not be able to be abandoned.

Servers MUST discard Abandon requests for messageIDs they do not recognize, for operations that cannot be abandoned, and for operations that have already been abandoned. Extended Operation The Extended operation allows additional operations to be defined for services not already available in the protocol; for example, to Add operations to install transport layer security see Section 4.

The Extended operation allows clients to make requests and receive responses with predefined syntaxes and semantics. These may be defined in RFCs or be private to particular implementations. Each Extended operation consists of an Extended request and an Extended response. The field will be absent whenever the server is unable or unwilling to determine the appropriate LDAPOID to return, for instance, when the requestName cannot be parsed or its value is not recognized.

Where the requestName is not recognized, the server returns protocolError. The server may return protocolError in other cases. The requestValue and responseValue fields contain information associated with the operation.

The format of these fields is defined by the specification of the Extended operation. Implementations MUST be prepared to handle arbitrary contents of these fields, including zero bytes.

Values that are defined in terms of ASN. Extended operations may be specified in other documents. IntermediateResponse Message While the Search operation provides a mechanism to return multiple response messages for a single Search request, other operations, by nature, do not provide for multiple response messages. It is intended that the definitions and descriptions of Extended operations and controls that make use of the IntermediateResponse message will define the circumstances when an IntermediateResponse message can be sent by a server and the associated meaning of an IntermediateResponse message sent in a particular circumstance.

This document defines two forms of solicitation: Extended operation and request control. IntermediateResponse messages are specified in documents describing the manner in which they are solicited i. Extensions that allow the return of multiple types of IntermediateResponse messages SHALL identify those types using unique responseName values note that one of these may specify no value. Usage with LDAP Request Controls A control's semantics may include the return of zero or more IntermediateResponse messages prior to returning the final result code for the operation.

One or more kinds of IntermediateResponse messages may be sent in response to a request control. This requirement ensures that the client can correctly identify the source of IntermediateResponse messages when: - two or more controls using IntermediateResponse messages are included in a request for any LDAP operation or - one or more controls using IntermediateResponse messages are included in a request with an LDAP Extended operation that uses IntermediateResponse messages.

The requestName is "1. Detected sequencing problems particularly those detailed in Section 3. If the server does not support TLS whether by design or by current configuration , it returns with the resultCode set to protocolError as described in Section 4. The responseName is "1. The responseValue is always absent. If the server is otherwise unwilling or unable to perform this operation, the server is to return an appropriate result code indicating the nature of the problem.

For example, if the TLS subsystem is not presently available, the server may indicate this by returning with the resultCode set to unavailable. Protocol Encoding, Connection, and Transfer This protocol is designed to run over connection-oriented, reliable transports, where the data stream is divided into octets 8-bit units , with each octet and each bit being significant.

This service is generally applicable to applications providing or consuming X. This specification was generally written with the TCP mapping in mind. Specifications detailing other mappings may encounter various obstacles. These restrictions are meant to ease the overhead of encoding and decoding certain elements in BER.

These restrictions do not apply to ASN. Servers may instead provide a listener on a different port number. A protocol peer may determine that the continuation of any communication would be pernicious, and in this case, it may abruptly terminate the session by ceasing communication and closing the transport connection.

In either case, when the LDAP session is terminated, uncompleted operations are handled as specified in Section 3. Security Considerations This version of the protocol provides facilities for simple authentication using a cleartext password, as well as any SASL [ RFC ] mechanism.

It is also permitted that the server can return its credentials to the client, if it chooses to do so. Sermersheim Standards Track [Page 43] RFC LDAPv3 June Use of cleartext password is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.

Servers are encouraged to prevent directory modifications by clients that have authenticated anonymously [ RFC ]. Note that SASL authentication exchanges do not provide data confidentiality or integrity protection for the version or name fields of the BindRequest or the resultCode, diagnosticMessage, or referral fields of the BindResponse, nor for any information contained in controls attached to Bind requests or responses. Implementors should note that various security factors including authentication and authorization information and data security services may change during the course of the LDAP session or even during the performance of a particular operation.

For instance, credentials could expire, authorization identities or access controls could change, or the underlying security layer s could be replaced or terminated.

Implementations should be robust in the handling of changing security factors. In some cases, it may be appropriate to continue the operation even in light of security factor changes. For instance, it may be appropriate to continue an Abandon operation regardless of the change, or to continue an operation when the change upgraded or maintained the security factor.

In other cases, it may be appropriate to fail or alter the processing of the operation. For instance, if confidential protections were removed, it would be appropriate either to fail a request to return sensitive data or, minimally, to exclude the return of sensitive data.

Implementations that cache attributes and entries obtained via LDAP MUST ensure that access controls are maintained if that information is to be provided to multiple clients, since servers may have access control policies that prevent the return of entries or attributes in Search results except to particular authenticated clients. For example, caches could serve result information only to the client whose request caused it to be in the cache. It is possible for a rogue application to inject such referrals into the data stream in an attempt to redirect a client to a rogue server.

Clients are advised to be aware of this and possibly reject referrals when confidentiality measures are not in place. Clients are advised to reject referrals from the StartTLS operation.

The matchedDN and diagnosticMessage fields, as well as some resultCode values e. Server implementations should restrict access to protected information equally under both normal and error conditions.

Protocol peers MUST be prepared to handle invalid and arbitrary- length protocol encodings. In the event that a protocol peer senses an attack that in its nature could cause damage due to further communication at any layer in the LDAP session, the protocol peer should abruptly terminate the LDAP session as described in Section 5. Normative References [ ASN. Zeilenga, Ed. It is also noted that one resultCode value strongAuthRequired has been renamed to strongerAuthRequired.

Where subordinate specialized descriptions are selected to be returned as part of a search result these descriptions shall be returned if available. Where the more general descriptions are selected to be returned as part of a search result both the general and the specialized descriptions shall be returned, if available. An attribute value shall always be returned as a value of its own attribute description. All of the attribute descriptions in an attribute hierarchy are treated as distinct and unrelated descriptions for user modification of entry content.

An attribute value stored in an object or alias entry is of precisely one attribute description. The description is indicated when the value is originally added to the entry. For the purpose of subschema administration of the entry, a specification that an attribute is required is fulfilled if the entry contains a value of an attribute description belonging to an attribute hierarchy where the attribute type of that description is the same as the required attribute's type.

Likewise, an entry may contain a value of an attribute description belonging to an attribute hierarchy where the attribute type of that description is either explicitly included in the definition of an object class to which the entry belongs or allowed by the DIT content rule applicable to that entry. Zeilenga Standards Track [Page 15] RFC LDAP Models June For the purposes of other policy administration, unless stated otherwise in the specification of the particular administrative model, all of the attribute descriptions in an attribute hierarchy are treated as distinct and unrelated descriptions.

Alias Entries As adapted from [ X. Each alias entry contains, within the 'aliasedObjectName' attribute known as the 'aliasedEntryName' attribute in X. The distinguished name of the alias entry is thus also a name for this object. It does not have to be the distinguished name of any entry. The conversion of an alias name to an object name is termed alias dereferencing and comprises the systematic replacement of alias names, where found within a purported name, by the value of the corresponding 'aliasedObjectName' attribute.

The process may require the examination of more than one alias entry. Any particular entry in the DIT may have zero or more alias names. It therefore follows that several alias entries may point to the same entry. An alias entry may point to an entry that is not a leaf entry and may point to another alias entry.

An alias entry shall have no subordinates, so that an alias entry is always a leaf entry. Every alias entry shall belong to the 'alias' object class. An entry with the 'alias' object class must also belong to an object class or classes , or be governed by a DIT content rule, which allows suitable naming attributes to be present. Subtrees As defined in [ X. Subtrees do not contain subentries. The prefix sub, in subtree, emphasizes that the base or root vertex of this tree is usually subordinate to the root of the DIT.

A subtree begins at some vertex and extends to some identifiable lower boundary, possibly extending to leaves. A subtree is always defined within a context which implicitly bounds the subtree. For example, the vertex and lower boundaries of a subtree defining a replicated area are bounded by a naming context.

Subentries A subentry is a "special sort of entry, known by the Directory, used to hold information associated with a subtree or subtree refinement" [ X. Subentries are used in Directory to hold for administrative and operational purposes as defined in [ X.

The term " sub entry" in this specification indicates that servers implementing X. The 'objectClass' attribute specifies the object classes of an entry, which among other things are used in conjunction with the controlling schema to determine the permitted attributes of an entry.

Values of this attribute can be modified by clients, but the 'objectClass' attribute cannot be removed. Servers that follow X.

That is, one cannot change a 'person' into a 'country'. When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. That is, if the auxiliary class 'x-a' is a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes 'x-b' to be implicitly added if is not already present.

Servers SHALL restrict modifications of this attribute to prevent superclasses of remaining 'objectClass' values from being deleted. That is, if the auxiliary class 'x-a' is a subclass of the auxiliary Zeilenga Standards Track [Page 18] RFC LDAP Models June class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b', an attempt to delete only 'x-b' from the 'objectClass' attribute is an error.

Operational Attributes Some attributes, termed operational attributes, are used or maintained by servers for administrative and operational purposes. As stated in [ X. This includes operational attributes maintained by the server e. Operational attributes are not normally visible. They are not returned in search results unless explicitly requested by name. Not all operational attributes are user modifiable. Entries may contain, among others, the following operational attributes: - creatorsName: the Distinguished Name of the user who added this entry to the directory, - createTimestamp: the time this entry was added to the directory, - modifiersName: the Distinguished Name of the user who last modified this entry, and - modifyTimestamp: the time this entry was last modified.

The value is the distinguished name of the creator. The value is the time the entry was added. The value is the distinguished name of the last modifier.

The value is the time the entry was last modified. Directory Schema As defined in [ X. NOTE 1 - The schema enables the Directory system to, for example: - prevent the creation of subordinate entries of the wrong object-class e. Schema Definitions Schema definitions in this section are described using ABNF and rely on the common productions specified in Section 1.

While specifications may suggest a descriptive string, there is no requirement that the suggested or any descriptive string be used. Implementors should note that future versions of this document may expand these definitions to include additional terms. Usage of userApplications, the default, indicates that attributes of this type represent user information. That is, they are user attributes. That is, they are operational attributes.

This is done using the 'matchingRuleUse' attribute described in Section 4. This document refines the schema description of X. This bound is not part of the syntax name itself. For instance, "1. Note that a single character of the Directory String syntax may be encoded in more than one octet since UTF-8 [ RFC ] is a variable-length encoding. Matching Rules Matching rules are used in performance of attribute value assertions, such as in performance of a Compare operation.

They are also used in evaluating search filters, determining which individual values are to be added or deleted during performance of a Modify operation, and in comparing distinguished names. Each matching rule is identified by an object identifier OID and, optionally, one or more short names descriptors. Matching Rule Uses A matching rule use lists the attribute types that are suitable for use with an extensibleMatch search filter.

For DIT entries of a particular structural object class, a DIT content rule specifies which auxiliary object classes the entries are allowed to belong to and which additional attributes by type are required, allowed, or not allowed to appear in the entries. The list of precluded attributes cannot include any attribute listed as mandatory in the rule, the structural object class, or any of the allowed auxiliary object classes.

An entry may only belong to auxiliary object classes listed in the governing content rule. An entry must contain all attributes required by the object classes the entry belongs to as well as all attributes required by the governing content rule. An entry may contain any non-precluded attributes allowed by the object classes the entry belongs to as well as all attributes allowed by the governing content rule. An entry cannot include any attribute precluded by the governing content rule.

An entry is governed by if present and active in the subschema the DIT content rule that applies to the structural object class of the entry see Section 2. If no active rule is present for the entry's structural object class, the entry's content is governed by the structural object class and possibly other aspects of user and system schema. DIT content rules for superclasses of the structural object class of an entry are not applicable to that entry.

DIT Structure Rules and Name Forms It is sometimes desirable to regulate where object and alias entries can be placed in the DIT and how they can be named based upon their structural object class.

A structure rule relates a name form, and therefore a structural object class, to superior structure rules. This permits entries of the structural object class identified by the name form to exist in the DIT as subordinates to entries governed by the indicated superior structure rules" [ X. Name Forms A name form "specifies a permissible RDN for entries of a particular structural object class.

A name form identifies a named object class and one or more attribute types to be used for naming i. Name forms are primitive pieces of specification used in the definition of DIT structure rules" [ X. Each name form indicates the structural object class to be named, a set of required attribute types, and a set of allowed attribute types. A particular attribute type cannot be in both sets.

Entries governed by the form must be named using a value from each required attribute type and zero or more values from the allowed attribute types. Each name form is identified by an object identifier OID and, optionally, one or more short names descriptors.

Subschema Subentries Subschema sub entries are used for administering information about the directory schema. A single subschema sub entry contains all schema definitions see Section 4.

Servers MAY allow subschema modification. Procedures for subschema modification are discussed in Section A server that masters entries and permits clients to modify these entries SHALL implement and provide access to these subschema sub entries including providing a 'subschemaSubentry' attribute in each modifiable entry.

This is so clients may discover the attributes and object classes that are permitted to be present. The value of the 'subschemaSubentry' attribute is the name of the subschema sub entry holding the subschema controlling the entry. Subschema is held in sub entries belonging to the subschema auxiliary object class. Servers SHOULD provide the attributes 'createTimestamp' and 'modifyTimestamp' in subschema sub entries, in order to allow clients to maintain their caches of schema information.

The following subsections provide attribute type definitions for each of schema definition attribute types. The set of allowed attribute types of this object class is implicitly the set of all attribute types of userApplications usage. Subschema Discovery To discover the DN of the subschema sub entry holding the subschema controlling a particular entry, a client reads that entry's 'subschemaSubentry' operational attribute.

Clients SHOULD NOT assume that a published subschema is complete, that the server supports all of the schema elements it publishes, or that the server does not support an unpublished element. The server holding the original information is called the "master" for that information. Servers that hold copies of the original information are referred to as "shadowing" or "caching" servers.

That is, a naming context is the largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries that are mastered by different servers.

The context prefix is the name of the initial entry. It is noted that root DSE attributes are operational and, like other operational attributes, are not returned in search requests unless requested by name. Servers may allow clients to modify attributes of the root DSE, where appropriate. The following attributes of the root DSE are defined below. Additional attributes may be defined in other documents.

The values provided for these attributes may depend on session- specific and other factors. See [ RFC ]. The root DSE may also include a 'subschemaSubentry' attribute. If it does, the attribute refers to the subschema sub entry holding the schema controlling the root DSE. General subschema discovery procedures are provided in Section 4.

Other kinds of URIs may be provided. If the server does not know of any other servers that could be used, this attribute will be absent. Clients may cache this information in case their preferred server later becomes unavailable. If the server is a first-level DSA [ X. If the server does not master or shadow any information e. If the server believes it masters or shadows the entire directory, the attribute will have a single value, and that value will be the empty string indicating the root of the DIT.

This attribute may be used, for example, to select a suitable entry name for subsequent operations with this server. If the server does not support any request controls, this attribute will be absent. Object identifiers identifying response controls need not be listed. If the server does not support any extended operations, this attribute will be absent. An extended operation generally consists of an extended request and an extended response but may also include other protocol data units such as intermediate responses.

The object identifier assigned to the extended request is used to identify the extended operation. Other object identifiers used in the extended operation need not be listed as values of this attribute. If the server does not support any discoverable elective features, this attribute will be absent. The contents of this attribute may depend on the current session state. If the server does not support any SASL mechanisms, this attribute will not be present. Other Considerations 6.

For example, a syntax containing digitally signed data can mandate that the server preserve both the value and form of value presented to ensure that the signature is not invalidated. And where a server is unable or unwilling to preserve the value of user information, the server SHALL ensure that an equivalent value per Section 2.

Short Names Short names, also known as descriptors, are used as more readable aliases for object identifiers and are used to identify various schema elements. However, it is not expected that LDAP implementations with human user interface would display these short names or the object identifiers they refer to to the user. Instead, they would most likely be performing translations such as expressing the short name in one of the local national languages.

For example, the short name "st" stateOrProvinceName might be displayed to a German-speaking user as "Land". The same short name might have different meaning in different subschemas, and, within a particular subschema, the same short name might refer to different object identifiers each identifying a different kind of schema element.

Implementations MUST be prepared that the same short name might be used in a subschema to refer to the different kinds of schema elements. That is, there might be an object class 'x-fubar' and an attribute type 'x-fubar' in a subschema. Implementations MUST be prepared that the same short name might be used in the different subschemas to refer to the different schema elements. That is, there might be two matching rules 'x-fubar', each in different subschemas.

Cache and Shadowing Some servers may hold cache or shadow copies of entries, which can be used to answer search and comparison queries, but will return referrals or contact other servers if modification operations are requested. Servers that perform shadowing or caching MUST ensure that they do not violate any access control constraints placed on the data by the originating server.

Implementation Guidelines 7. Server Guidelines Servers MUST recognize all names of attribute types and object classes defined in this document but, unless stated otherwise, need not support the associated functionality.

Servers MUST ensure that entries conform to user and system schema rules or other data model constraints. Servers MAY support alias entries. Servers MAY support the 'extensibleObject' object class. Servers MAY support subentries. Servers MAY implement additional schema elements. The client can retrieve subschema information as described in Section 4.

Security Considerations Attributes of directory entries are used to provide descriptive information about the real-world objects they represent, which can be people, organizations, or devices. Most countries have privacy laws regarding the publication of information about people.

Wahl, T. Howes, and S. Kille; RFC by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and RFC by M. This document is also based in part on "The Directory: Models" [ X. Additional text was borrowed from RFC by M. Zeilenga, Ed. Changes This appendix is non-normative. This rewrite was undertaken to improve overall clarity of technical specification.

This appendix provides a summary of substantive changes made to the portions of these documents incorporated into this document. Section 3. The previous specification relied on [ X. In LDAP, an attribute is better described as an attribute description, a type with zero or more options, and one or more associated values.

While generally all implementations that support X. The mandate was removed for consistency with X. The subschema discovery mechanism was also clarified to indicate that subschema controlling an entry is obtained by reading the sub entry referred to by that entry's 'subschemaSubentry' attribute.

This material, with changes, was incorporated in Section 5. Changes: - Clarify that attributes of the root DSE are subject to "other restrictions" in addition to access controls. The previous specification stated that the 'subschemaSubentry' attribute held in the root DSE referred to "subschema entries or subentries known by this server". This is inconsistent with the attribute's intended use as well as its formal definition as a single valued attribute [ X.

It is also noted that a simple possibly incomplete list of subschema sub entries is not terribly useful. This document in Section 5. It is noted that the general subschema discovery mechanism remains available see Section 4. Section 4 of RFC Portions of Section 4 of RFC detailing aspects of the information model used by LDAP were incorporated in this document, including: - Restriction of distinguished values to attributes whose descriptions have no options from Section 4.

Clarifications to these portions include: - Subtyping and AttributeDescriptions with options.