+++ /dev/null
-
-Internet Draft Mike Just, Entrust
- K. Leclair, Entrust
- Jim Sermersheim, Novell
- Mark Smith, Netscape
-Document: <draft-just-ldapv3-rescodes-02.txt> April, 2000
-Category: Standards Track
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use
- <draft-just-ldapv3-rescodes-02.txt>
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026 [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.
-
-1. Abstract
-
- The purpose of this document is to describe, in some detail, the
- meaning and use of the result codes used with the LDAPv3 protocol.
- Of particular importance are the error codes, which represent the
- majority of the result codes. This document provides definitions for
- each result code, and outlines the expected behaviour of the various
- operations with respect to how result codes and in particular, error
- conditions should be handled and which specific error code should be
- returned.
-
- It is hoped that this document will facilitate interoperability
- between clients and servers and the development of intelligent LDAP
- clients capable of acting upon the results received from the server.
-
-1.1 Relationship to X.500
-
- The LDAPv3 RFC [RFC2251] states that "An LDAP server MUST act in
- accordance with the X.500(1993) series of ITU recommendations when
- providing the service. However, it is not required that an LDAP
- server make use of any X.500 protocols in providing this service,
- e.g. LDAP can be mapped onto any other directory system so long as
- the X.500 data and service model as used in LDAP is not violated in
- the LDAP interface." This means that there are two types of LDAP
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 1
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- servers, those that act as a front end to an X.500 directory, and
- stand alone LDAP servers which use some other form of repository as
- the back end.
-
- Because of differences between X.500 and LDAP there may be some
- differences in behaviour between LDAP-only servers and LDAP servers
- that act as front ends to X.500 DSAs. One such difference is the
- definition of specific access controls for X.500. X.500 defines the
- discloseOnError permission, an access control parameter for which
- there is currently no equivalent defined for LDAP. If an LDAP server
- is acting as a front end to an X.500 DSA then it may return
- noSuchObject when the target entry is found but the client does not
- have permission to view or modify the entry. Unless the server
- implements X.500 style access controls LDAP-only servers should only
- return noSuchObject when the target entry is not found until such
- time that similar access controls are defined for LDAP only servers.
- Because the client may not know what sort of LDAP server it is
- communicating with it should not rely on the behaviour of the server
- in this respect.
-
-2. Conventions used in this document
-
- 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 [RFC2119].
-
-3. Overview
-
- This document collects and refines the definitions and descriptions
- for LDAPv3 result codes, as found in a variety of sources (see
- Section 8). In some cases, material from these sources was absent,
- inadequate or ambiguous. It is the hope of this document to present
- consistent definitions and descriptions of LDAPv3 result codes.
-
- This document consists of two major sections facilitating information
- searches based on either a particular result code, or LDAP operation.
-
- Section 5 presents a glossary for the result codes. Firstly, each is
- classified as either an erroneous or non-erroneous result. The
- erroneous results, or error codes, are further classified based on
- the types of error codes defined in X.511 [X511]. Some
- reclassification was performed where appropriate. For each result
- code, a definition, and list of operations that could return this
- code are given.
-
- Section 6 describes, for each operation, the result codes that could
- be returned for that operation. Firstly, Section 6.1 enumerates
- those result codes that are applicable to all operations. Within
- each remaining section (which is specific to each operation), the
- error codes that are specific to that operation (in addition to the
- result codes specified in Section 6.1) are presented.
-
- Also, Appendix A (Section 11) presents a simple matrix that indicates
- valid operation/result code pairs in LDAPv3.
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 2
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
-4. Table of Contents
-
- 1. Abstract........................................................1
- 1.1 Relationship to X.500...........................................1
- 2. Conventions used in this document...............................2
- 3. Overview........................................................2
- 4. Table of Contents...............................................3
- 5. Result Codes in LDAPv3..........................................4
- 5.1 Description of Non-Erroneous Result Codes.......................6
- 5.1.1 success(0)...................................................6
- 5.1.2 compareFalse(5)..............................................6
- 5.1.3 compareTrue(6)...............................................6
- 5.1.4 referral(10).................................................7
- 5.1.5 saslBindInProgress(14).......................................7
- 5.2 Description of Error Codes......................................7
- 5.2.1 General Error Codes..........................................7
- 5.2.1.1 other(80)................................................7
- 5.2.2 Specific Error Codes.........................................7
- 5.2.2.1 Attribute Problem Error Codes............................7
- 5.2.2.1.1 noSuchAttribute(16)...................................8
- 5.2.2.1.2 undefinedAttributeType(17)............................8
- 5.2.2.1.3 inappropriateMatching(18).............................8
- 5.2.2.1.4 constraintViolation(19)...............................8
- 5.2.2.1.5 attributeOrValueExists(20)............................8
- 5.2.2.1.6 invalidAttributeSyntax(21)............................8
- 5.2.2.2 NameProblem Error Codes..................................9
- 5.2.2.2.1 noSuchObject(32)......................................9
- 5.2.2.2.2 aliasProblem(33)......................................9
- 5.2.2.2.3 invalidDNSyntax(34)...................................9
- 5.2.2.3 SecurityProblem Error Codes..............................9
- 5.2.2.3.1 authMethodNotSupported(7).............................9
- 5.2.2.3.2 strongAuthRequired(8)................................10
- 5.2.2.3.3 confidentialityRequired(13)..........................10
- 5.2.2.3.4 aliasDereferencingProblem(36)........................10
- 5.2.2.3.5 inappropriateAuthentication(48)......................10
- 5.2.2.3.6 invalidCredentials(49)...............................11
- 5.2.2.3.7 insufficientAccessRights(50).........................11
- 5.2.2.4 ServiceProblem Error Codes..............................11
- 5.2.2.4.1 operationsError(1)...................................11
- 5.2.2.4.2 protocolError(2).....................................11
- 5.2.2.4.3 timeLimitExceeded(3).................................12
- 5.2.2.4.4 sizeLimitExceeded(4).................................12
- 5.2.2.4.5 adminLimitExceeded(11)...............................12
- 5.2.2.4.6 unavailableCriticalExtension(12).....................12
- 5.2.2.4.7 busy(51).............................................13
- 5.2.2.4.8 unavailable(52)......................................13
- 5.2.2.4.9 unwillingToPerform(53)...............................13
- 5.2.2.4.10 loopDetect(54)......................................13
- 5.2.2.5 UpdateProblem Error Codes...............................13
- 5.2.2.5.1 namingViolation(64)..................................13
- 5.2.2.5.2 objectClassViolation(65).............................14
- 5.2.2.5.3 notAllowedOnNonLeaf(66)..............................14
- 5.2.2.5.4 notAllowedOnRDN(67)..................................14
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 3
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- 5.2.2.5.5 entryAlreadyExists(68)...............................14
- 5.2.2.5.6 objectClassModsProhibited(69)........................14
- 5.2.2.5.7 affectsMultipleDSAs(71)..............................15
- 6 LDAP Operations.................................................15
- 6.1 Common Result Codes............................................16
- 6.1.1 Non-erroneous results.......................................16
- 6.1.2 Security Errors.............................................16
- 6.1.3 Service Errors..............................................16
- 6.1.4 General Errors..............................................16
- 6.2 Bind Operation Errors..........................................16
- 6.2.1 Non-erroneous results.......................................17
- 6.2.2 Name Errors.................................................17
- 6.2.3 Security Errors.............................................17
- 6.3 Search Operation Errors........................................17
- 6.3.1 Name Errors.................................................18
- 6.3.2 Attribute Errors............................................18
- 6.3.3 Security Errors.............................................18
- 6.3.4 Service Errors..............................................18
- 6.4 Modify Operation Errors........................................18
- 6.4.1 Name Errors.................................................19
- 6.4.2 Update Errors...............................................19
- 6.4.3 Attribute Errors............................................19
- 6.4.4 Security Errors.............................................19
- 6.5 Add Operation Errors...........................................19
- 6.5.1 Name Errors.................................................20
- 6.5.2 Update Errors...............................................20
- 6.5.3 Attribute Errors............................................20
- 6.5.4 Security Errors.............................................20
- 6.6 Delete Operation Errors........................................21
- 6.6.1 Name Errors.................................................21
- 6.6.2 Update Errors...............................................21
- 6.6.3 Security Errors.............................................21
- 6.7 ModifyDN Operation Errors......................................21
- 6.7.1 Name Errors.................................................22
- 6.7.2 Update Errors...............................................22
- 6.7.3 Attribute Errors............................................22
- 6.7.4 Security Errors.............................................22
- 6.8 Compare Operation Errors.......................................22
- 6.8.1 Name Errors.................................................23
- 6.8.2 Attribute Errors............................................23
- 6.8.3 Security Errors.............................................23
- 6.8.4 Example.....................................................23
- 6.9 Extended Operation Errors......................................24
- 6.10 Operations with no Server Response............................24
- 6.11 Unsolicited Notification......................................24
- 6.12 Controls......................................................25
- 7. Security Considerations........................................25
- 8. References.....................................................25
- 9. Acknowledgments................................................25
- 10. Author's Addresses............................................26
- 11 Appendix A: Operation/Response Matrix..........................27
- 12 Full Copyright Statement.......................................29
-
-5. Result Codes in LDAPv3
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 4
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
- In this section, a glossary of the result codes that may be returned
- from a server to a client is provided. This section is meant to
- provide a central, unified source for these definitions. RFC 2251
- [RFC2251] and X.511 [X511] were primary sources, forming the basis
- for the definitions given in this section.
-
- LDAP v3 [RFC2251] defines the following result message for return
- from the server to the client, where "new" indicates those codes that
- were not used in LDAP v2.
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongAuthRequired (8),
- -- 9 reserved --
- referral (10), -- new
- adminLimitExceeded (11), -- new
- unavailableCriticalExtension (12), -- new
- confidentialityRequired (13), -- new
- saslBindInProgress (14), -- new
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 5
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71), -- new
- -- 72-79 unused --
- other (80) },
- -- 81-90 reserved for APIs --
- matchedDN LDAPDN,
- errorMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- If a client receives a result code that is not listed above, it is to
- be treated as an unknown error condition. A server MUST NOT return an
- API result code (81-90).
-
- The LDAP result includes an errorMessage field, which may, at the
- server's option, be used to return a string containing a textual,
- human-readable error diagnostic. As this error diagnostic is not
- standardized, implementations MUST NOT rely on the values returned.
- If the server chooses not to return a textual diagnostic, the
- errorMessage field of the LDAPResult type MUST contain a zero length
- string.
-
- In the following subsections, definitions for each result code are
- provided. In addition, the operations that may return each result
- code are also identified. The set of all operations consists of the
- following: Bind; Search; Modify; Add; Delete; ModifyDN; Extended; and
- Compare.
-
-5.1 Description of Non-Erroneous Result Codes
-
- Five result codes that may be returned in LDAPResult are not used to
- indicate an error. These result codes are listed below. The first
- three codes, indicate to the client that no further action is
- required in order to satisfy their request. In contrast, the last
- two errors require further action by the client in order to complete
- their original operation request.
-
-5.1.1 success(0)
-
- Applicable operations: all except for Compare.
-
- This result code does not indicate an error. It is returned when the
- client operation completed successfully.
-
-5.1.2 compareFalse(5)
-
- Applicable operations: Compare.
-
- This result code does not indicate an error. It is used to indicate
- that the result of a Compare operation is FALSE.
-
-5.1.3 compareTrue(6)
-
- Applicable operations: Compare.
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 6
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
- This result code does not indicate an error. It is used to indicate
- that the result of a Compare operation is TRUE.
-
-5.1.4 referral(10)
-
- Applicable operations: all.
-
- This result code is new in LDAPv3. Rather than indicating an error,
- this result code is used to indicate that the server does not hold
- the target entry of the request but is able to provide alternative
- servers that may. A set of server(s) URLs may be returned in the
- referral field, which the client may subsequently query to attempt to
- complete their operation.
-
-5.1.5 saslBindInProgress(14)
-
- Applicable operations: Bind.
-
- This result code is new in LDAPv3. This result code is not an error
- response from the server, but rather, is a request for bind
- continuation. The server requires the client to send a new bind
- request, with the same SASL mechanism, to continue the authentication
- process [RFC2251, Section 4.2.3].
-
-5.2 Description of Error Codes
-
- General error codes (see Section 5.2.1) are typically returned only
- when no suitable specific error exists. Specific error codes (see
- Section 5.2.2) are meant to capture situations that are specific to
- the requested operation.
-
-5.2.1 General Error Codes
-
- A general error code typically specifies an error condition for which
- there is no suitable specific error code. If the server can return an
- error, which is more specific than the following general errors, then
- the specific error should be returned instead.
-
-5.2.1.1 other(80)
-
- Applicable operations: all.
-
- This error code should be returned only if no other error code is
- suitable. Use of this error code should be avoided if possible.
- Details of the error should be provided in the error message.
-
-5.2.2 Specific Error Codes
-
- Specific errors are used to indicate that a particular type of error
- has occurred. These error types are Name, Update, Attribute,
- Security, and Service.
-
-5.2.2.1 Attribute Problem Error Codes
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 7
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
- An attribute error reports a problem related to an attribute
- specified by the client in their request message.
-
-5.2.2.1.1 noSuchAttribute(16)
-
- Applicable operations: Modify, Compare.
-
- This error may be returned if the attribute specified as an argument
- of the operation does not exist in the entry.
-
-5.2.2.1.2 undefinedAttributeType(17)
-
- Applicable operations: Modify, Add.
-
- This error may be returned if the specified attribute is unrecognized
- by the server, since it is not present in the serverÆs defined
- schema. If the server doesnÆt recognize an attribute specified in a
- search request as the attribute to be returned the server should not
- return an error in this case - it should just return values for the
- requested attributes it does recognize. Note that this result code
- only applies to the Add and Modify operations [X.511, Section 12.4].
-
-5.2.2.1.3 inappropriateMatching(18)
-
- Applicable operations: Search.
-
- An attempt was made, e.g., in a filter, to use a matching rule not
- defined for the attribute type concerned [X511, Section 12.4].
-
-5.2.2.1.4 constraintViolation(19)
-
- Applicable operations: Modify, Add, ModifyDN.
-
- This error should be returned by the server if an attribute value
- specified by the client violates the constraints placed on the
- attribute as it was defined in the DSA - this may be a size
- constraint or a constraint on the content.
-
-5.2.2.1.5 attributeOrValueExists(20)
-
- Applicable operations: Modify, Add.
-
- This error should be returned by the server if the value specified by
- the client already exists within the attribute.
-
-5.2.2.1.6 invalidAttributeSyntax(21)
-
- Applicable operations: Modify, Add.
-
- This error should be returned by the server if the attribute syntax
- for the attribute value, specified as an argument of the operation,
- is unrecognized or invalid.
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 8
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-5.2.2.2 NameProblem Error Codes
-
- A name error reports a problem related to the distinguished name
- provided as an argument to an operation [X511, Section 12.5].
-
- For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
- aliasDereferencingProblem (see Section 5.2.2.3.7), the matchedDN
- field is set to the name of the lowest entry (object or alias) in the
- directory that was matched. If no aliases were dereferenced while
- attempting to locate the entry, this will be a truncated form of the
- name provided, or if aliases were dereferenced, of the resulting
- name, as defined in section 12.5 of X.511 [X511]. The matchedDN field
- is to be set to a zero length string with all other result codes
- [RFC2251, Section 4.1.10].
-
-5.2.2.2.1 noSuchObject(32)
-
- Applicable operations: all except for Bind.
-
- This error should only be returned if the target object cannot be
- found. For example, in a search operation if the search base can not
- be located in the DSA the server should return noSuchObject. If,
- however, the search base is found but does not match the search
- filter, success, with no resultant objects, should be returned
- instead of noSuchObject.
-
- If the LDAP server is a front end for an X.500 DSA then noSuchObject
- may also be returned if discloseOnError is not granted for an entry
- and the client does not have permission to view or modify the entry.
-
-5.2.2.2.2 aliasProblem(33)
-
- Applicable operations: Search.
-
- An alias has been dereferenced which names no object [X511, Section
- 12.5].
-
-5.2.2.2.3 invalidDNSyntax(34)
-
- Applicable operations: all.
-
- This error should be returned by the server if the DN syntax is
- incorrect. It should not be returned if the DN is correctly formed
- but represents an entry which is not permitted by the structure rules
- at the DSA; in this case namingViolation should be returned instead.
-
-5.2.2.3 SecurityProblem Error Codes
-
- A security error reports a problem in carrying out an operation for
- security reasons [X511, Section 12.7].
-
-5.2.2.3.1 authMethodNotSupported(7)
-
- Applicable operations: Bind.
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 9
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
- This error code should be returned if the client requests, in a Bind
- request, an authentication method which is not supported or
- recognized by the server.
-
-5.2.2.3.2 strongAuthRequired(8)
-
- Applicable operations: all.
-
- This error may be returned on a bind request if the server only
- accepts strong authentication or it may be returned when a client
- attempts an operation which requires the client to be strongly
- authenticated - for example Delete.
-
- This result code may also be returned in an unsolicited notice of
- disconnection if the server detects that an established underlying
- security association protecting communication between the client and
- server has unexpectedly failed or been compromised. [RFC2251, Section
- 4.4.1]
-
-5.2.2.3.3 confidentialityRequired(13)
-
- Applicable operations: all.
-
- This error code is new in LDAPv3. This error code may be returned if
- the session is not protected by a protocol which provides session
- confidentiality. For example, if the client did not establish a TLS
- connection using a cipher suite which provides confidentiality of the
- session before sending any other requests, and the server requires
- session confidentiality then the server may reject that request with
- a result code of confidentialityRequired.
-
-5.2.2.3.4 aliasDereferencingProblem(36)
-
- Applicable operations: Search.
-
- An alias was encountered in a situation where it was not allowed or
- where access was denied [X511, Section 12.5]. For example, if the
- client does not have read permission for the aliasedObjectName
- attribute and its value then the error aliasDereferencingProblem
- should be returned. [X511, Section 7.11.1.1]
-
- Notice that this error has similar meaning to
- insufficientAccessRights(50) (see Section 5.2.2.3.7), but is specific
- to Searching on an alias.
-
- (See note at start of Section 5.2.2.2 regarding this error code.)
-
-5.2.2.3.5 inappropriateAuthentication(48)
-
- Applicable operations: Bind.
-
- This error should be returned by the server when the client has tried
- to use a method of authentication that is inappropriate, that is a
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 10
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- method of authentication which the client is unable to use correctly.
- In other words, the level of security associated with the requestorÆs
- credentials is inconsistent with the level of protection requested,
- e.g. simple credentials were supplied while strong credentials were
- required [X511, Section 12.7].
-
-5.2.2.3.6 invalidCredentials(49)
-
- Applicable operations: Bind.
-
- This error code is returned if the DN or password used in a simple
- bind operation is incorrect, or if the DN or password is incorrect
- for some other reason, e.g. the password has expired. This result
- code only applies to Bind operations -- it should not be returned for
- other operations if the client does not have sufficient permission to
- perform the requested operation - in this case the return code should
- be insufficientAccessRights.
-
-5.2.2.3.7 insufficientAccessRights(50)
-
- Applicable operations: all except for Bind.
-
- The requestor does not have the right to carry out the requested
- operation [X511, Section 12.7]. Note that the more specific
- aliasDereferencingProblem (see Section 5.2.2.3.4) is returned in case
- of a Search on an alias where the requestor has
- insufficientAccessRights.
-
-5.2.2.4 ServiceProblem Error Codes
-
- A service error reports a problem related to the provision of the
- service [X511, Section 12.8].
-
-5.2.2.4.1 operationsError(1)
-
- Applicable operations: all except Bind.
-
- If the server requires that the client bind before browsing or
- modifying the directory, the server MAY reject a request other than
- binding, unbinding or an extended request with the "operationsError"
- result. [RFC2251, Section 4.2.1]
-
-5.2.2.4.2 protocolError(2)
-
- Applicable operations: all.
-
- A protocol error should be returned by the server when an invalid or
- malformed request is received from the client. This may be a request
- that is not recognized as an LDAP request, for example, if a
- nonexistent operation were specified in LDAPMessage. As well, it may
- be the result of a request that is missing a required parameter, such
- as a search filter in a search request. If the server can return an
- error, which is more specific than protocolError, then this error
- should be returned instead. For example if the server does not
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 11
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- recognize the authentication method requested by the client then the
- error authMethodNotSupported should be returned instead of
- protocolError. The server may return details of the error in the
- error string.
-
-5.2.2.4.3 timeLimitExceeded(3)
-
- Applicable operations: all.
-
- This error should be returned when the time to perform an operation
- has exceeded either the time limit specified by the client (which may
- only be set by the client in a search operation) or the limit
- specified by the server. If the time limit is exceeded on a search
- operation then the result is an arbitrary selection of the
- accumulated results [X511, Section 7.5]. Note that an arbitrary
- selection of results may mean that no results are returned to the
- client.
-
- If the LDAP server is a front end for an X.500 server, any operation
- that is chained may exceed the timelimit, therefore clients can
- expect to receive timelimitExceeded for all operations. For stand
- alone LDAP-Servers that do not implement chaining it is unlikely that
- operations other than search operations will exceed the defined
- timelimit.
-
-5.2.2.4.4 sizeLimitExceeded(4)
-
- Applicable operations: Search.
-
- This error should be returned when the number of results generated by
- a search exceeds the maximum number of results specified by either
- the client or the server. If the size limit is exceeded then the
- results of a search operation will be an arbitrary selection of the
- accumulated results, equal in number to the size limit [X511, Section
- 7.5].
-
-5.2.2.4.5 adminLimitExceeded(11)
-
- Applicable operations: all.
-
- This error code is new in LDAPv3. The server has reached some limit
- set by an administrative authority, and no partial results are
- available to return to the user [X511, Section 12.8]. For example,
- there may be an administrative limit to the number of entries a
- server will check when gathering potential search result candidates
- [Net].
-
-5.2.2.4.6 unavailableCriticalExtension(12)
-
- Applicable operations: all.
-
- This error code is new in LDAPv3. The server was unable to satisfy
- the request because one or more critical extensions were not
- available [X511, Section 12.8]. This error is returned, for example,
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 12
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- when a control submitted with a request is marked critical but is not
- recognized by a server or when such a control is not appropriate for
- the operation type. [RFC2251 section 4.1.12].
-
-5.2.2.4.7 busy(51)
-
- Applicable operations: all.
-
- This error code may be returned if the server is unable to process
- the clientÆs request at this time. This implies that if the client
- retries the request shortly the server will be able to process it
- then.
-
-5.2.2.4.8 unavailable(52)
-
- Applicable operations: all.
-
- This error code is returned when the server is unavailable to process
- the clientÆs request. This usually means that the LDAP server is
- shutting down [RFC2251, Section 4.2.3].
-
-5.2.2.4.9 unwillingToPerform(53)
-
- Applicable operations: all.
-
- This error code should be returned by the server when a client
- request is properly formed but which the server is unable to complete
- due to server-defined restrictions. For example, the server, or some
- part of it, is not prepared to execute this request, e.g. because it
- would lead to excessive consumption of resources or violates the
- policy of an Administrative Authority involved [X511, Section 12.8].
- If the server is able to return a more specific error code such as
- adminLimitExceeded it should. This error may also be returned if the
- client attempts to modify attributes which can not be modified by
- users, e.g., operational attributes such as creatorsName or
- createTimestamp [X511, Section 7.12]. If appropriate, details of the
- error should be provided in the error message.
-
-5.2.2.4.10 loopDetect(54)
-
- Applicable operations: all.
-
- This error may be returned by the server if it detects an alias or
- referral loop, and is unable to satisfy the clientÆs request.
-
-5.2.2.5 UpdateProblem Error Codes
-
- An update error reports problems related to attempts to add, delete,
- or modify information in the DIB [X511, Section 12.9].
-
-5.2.2.5.1 namingViolation(64)
-
- Applicable operations: Add, ModifyDN.
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 13
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- The attempted addition or modification would violate the structure
- rules of the DIT as defined in the directory schema and X.501. That
- is, it would place an entry as the subordinate of an alias entry, or
- in a region of the DIT not permitted to a member of its object class,
- or would define an RDN for an entry to include a forbidden attribute
- type [X511, Section 12.9].
-
-5.2.2.5.2 objectClassViolation(65)
-
- Applicable operations: Modify, Add, ModifyDN.
-
- This error should be returned if the operation requested by the user
- would violate the objectClass requirements for the entry if carried
- out. On an add or modify operation this would result from trying to
- add an object class without a required attribute, or by trying to add
- an attribute which is not permitted by the current object class set
- in the entry. On a modify operation this may result from trying to
- remove a required attribute without removing the associated auxiliary
- object class, or by attempting to remove an object class while the
- attributes it permits are still present.
-
-5.2.2.5.3 notAllowedOnNonLeaf(66)
-
- Applicable operations: Delete, ModifyDN.
-
- This operation should be returned if the client attempts to perform
- an operation which is permitted only on leaf entries - e.g., if the
- client attempts to delete a non-leaf entry. If the directory does
- not permit ModifyDN for non-leaf entries then this error may be
- returned if the client attempts to change the DN of a non-leaf entry.
- (Note that 1988 edition X.500 servers only permitted change of the
- RDN of an entry's DN [X.511, Section 11.4.1]).
-
-5.2.2.5.4 notAllowedOnRDN(67)
-
- Applicable operations: Modify.
-
- The attempted operation would affect the RDN (e.g., removal of an
- attribute which is a part of the RDN) [X511, Section 12.9]. If the
- client attempts to remove from an entry any of its distinguished
- values, those values which form the entry's relative distinguished
- name the server should return the error notAllowedOnRDN. [RFC2251,
- Section 4.6]
-
-5.2.2.5.5 entryAlreadyExists(68)
-
- Applicable operations: Add, ModifyDN.
-
- This error should be returned by the server when the client attempts
- to add an entry which already exists, or if the client attempts to
- rename an entry with the name of an entry which exists.
-
-5.2.2.5.6 objectClassModsProhibited(69)
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 14
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- Applicable operations: Modify.
-
- An operation attempted to modify an object class that should not be
- modified, e.g., the structural object class of an entry. Some
- servers may not permit object class modifications, especially
- modifications to the structural object class since this may change
- the entry entirely, name forms, structure rules etc. [X.511, Section
- 12.9].
-
-5.2.2.5.7 affectsMultipleDSAs(71)
-
- Applicable operations: ModifyDN.
-
- This error code is new for LDAPv3. This error code should be returned
- to indicate that the operation could not be performed since it
- affects more than one DSA.
-
- X.500 restricts the ModifyDN operation to only affect entries that
- are contained within a single server. If the LDAP server is mapped
- onto DAP, then this restriction will apply, and the resultCode
- affectsMultipleDSAs will be returned if this error occurred. In
- general clients MUST NOT expect to be able to perform arbitrary
- movements of entries and subtrees between servers [RFC2251, Section
- 4.9].
-
-6 LDAP Operations
-
- LDAP v3 [RFC2251] defines the following LDAPMessage for conveyance of
- the intended operation request from the client to the server.
-
- LDAPMessage ::= SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse },
- controls [0] Controls OPTIONAL }
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 15
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -
-
- Starting in Section 6.2, behaviour regarding the return of each
- result code is specified for each operation. Section 6.1 indicates
- those result codes that are typically applicable to all operations.
-
-6.1 Common Result Codes
-
- The following result codes are applicable to, and may be returned in
- response to all operations (except where stated otherwise).
-
-6.1.1 Non-erroneous results
-
- For all but a Compare operation, a success(0) result code will be
- returned in the case that the requested operation succeeds; a
- compareTrue would be returned for a Compare operation. For each
- operation, the server may return referral(10), as defined in Section
- 5.1.4.
-
-6.1.2 Security Errors
-
- Of the six possible security errors, two may be returned in response
- to every operation. These two errors are strongAuthRequired(8) and
- confidentialityRequired(13).
-
-6.1.3 Service Errors
-
- All service errors, except operationsError(1), and
- sizeLimitExceeded(4) may be returned in response to any LDAP v3
- operation. operationsError(1) is applicable to all operations except
- Bind. sizeLimitExceeded is only applicable to the Search operation.
-
-6.1.4 General Errors
-
- The general error other(80)is applicable to all operations.
-
-6.2 Bind Operation Errors
-
- If the bind operation succeeds then a result code of success will be
- returned to the client. If the server does not hold the target entry
- of the request, a referral(10) may be returned. If the operation
- fails then the result code will be one of the following from the set
- of non-erroneous result, name errors, security errors, service
- errors, and general errors.
-
- If the server does not support the client's requested protocol
- version, it MUST set the resultCode to protocolError.
- If the client receives a BindResponse response where the resultCode
- was protocolError, it MUST close the connection as the server will be
- unwilling to accept further operations. (This is for compatibility
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 16
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- with earlier versions of LDAP, in which the bind was always the first
- operation, and there was no negotiation.) [RFC2251, Section 5.2.3]
-
- The remaining errors listed in this section are operation-specific.
- An operation may also result in the return of any of the common
- errors, as listed in Section 6.1.
-
-6.2.1 Non-erroneous results
-
- In addition to success or referral, the following non-erroneous
- result code may be returned:
-
- saslBindInProgress: the server requires the client to send a new bind
- request, with the same sasl mechanism, to continue the authentication
- process,
-
-6.2.2 Name Errors
-
- invalidDNSyntax: the DN provided does not have the correct syntax,
-
-6.2.3 Security Errors
-
- As stated in Section 6.1.2, strongAuthRequired(8) and
- confidentialityRequired(13) may be returned for any operation.
-
- authMethodNotSupported: unrecognized SASL mechanism name,
-
- inappropriateAuthentication: the server requires the client which had
- attempted to bind anonymously or without supplying credentials to
- provide some form of credentials,
-
- invalidCredentials: the wrong password was supplied or the SASL
- credentials could not be processed, [RFC2251, Section 4.2.3]
-
-6.3 Search Operation Errors
-
- X.500 provides three separate operations for searching the directory
- - Read of a single entry, List of an entryÆs children and search of
- an entire sub-tree. LDAP provides a single search operation, however
- the X.500 operations can be simulated by using base, one-level and
- sub-tree scope restrictions respectively.
-
- If the Search operation succeeds then zero or more search entries
- will be returned followed by a search result of success. If the
- server does not hold the target entry of the request, a referral(10)
- may be returned. If the search operation fails then zero or more
- search entries will be returned followed by a search result
- containing one of the following result codes from the set of name
- errors, attribute errors, security errors, service errors, and
- general errors.
-
- The remaining errors listed in this section are operation-specific.
- An operation may also result in the return of any of the common
- errors, as listed in Section 6.1.
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 17
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
-6.3.1 Name Errors
-
- noSuchObject: the base object, for the search, does not exist.
-
- aliasProblem: an alias was dereferenced which named no object.
-
- invalidDNSyntax: the DN provided for the search base does not have
- the correct syntax,
-
-6.3.2 Attribute Errors
-
- inappropriateMatching: an attempt was made to use a matching rule not
- defined for an attribute in the search filter.
-
-6.3.3 Security Errors
-
- As stated in Section 6.1.2, strongAuthRequired(8) and
- confidentialityRequired(13) may be returned for any operation.
-
- aliasDereferenceProblem: The client does not have permission for the
- aliasedObjectName attribute or to search the dereferenced alias
- object.
-
- insufficientAccessRights: The requestor does not have sufficient
- permissions to perform the search. aliasDereferenceProblem should be
- returned in this case, if applicable.
-
-6.3.4 Service Errors
-
- In addition to the common service errors indicated in Section 6.1.3,
- the following service error may also be returned:
-
- sizeLimitExceeded: the number of search results exceeds the size
- limit specified by the client or the server. If the server has
- defined a maximum PDU size, this error may also be returned if the
- size of the combined results exceeds this limit.
-
-6.4 Modify Operation Errors
-
- The Modify operation cannot be used to remove from an entry any of
- its distinguished values, those values that form the entry's relative
- distinguished name. An attempt to do so will result in the server
- returning the error notAllowedOnRDN. The Modify DN Operation
- described in section 5.9 is used to rename an entry. [RFC2251,
- Section 4.6]
-
- If the modify operation succeeds, a result code of success will be
- returned to the client. If the server does not hold the target entry
- of the request, a referral(10) may be returned. If the operation
- fails, the result code will be one of the following from the set of
- name errors, update errors, attribute errors, security errors,
- service errors, and general errors.
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 18
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- The remaining errors listed in this section, are operation-specific.
- An operation may also result in the return of any of the common
- errors, as listed in Section 6.1.
-
-6.4.1 Name Errors
-
- noSuchObject: the target object does not exist.
-
- invalidDNSyntax: the DN provided does not have the correct syntax,
-
-6.4.2 Update Errors
-
- objectClassViolation: An attempt was made to modify an object which
- is illegal according to its object class definition in the schema or
- DIT content rules for that object class.
-
- notAllowedOnRDN: An attempt was made to modify the object entryÆs
- distinguished name
-
- objectClassModsProhibited: The modification attempted to change an
- entryÆs object class which is not allowed.
-
-6.4.3 Attribute Errors
-
- noSuchAttribute: the attribute to be modified does not exist in the
- target entry.
-
- undefinedAttributeType: The attribute specified does not exist in the
- server's defined schema.
-
- constraintViolation: The modification would create an attribute value
- outside the normal bounds.
-
- attributeOrValueExists: The modification would create a value which
- already exists within the attribute.
-
- invalidAttributeSyntax: The value specified doesnÆt adhere to the
- syntax definition for that attribute.
-
-6.4.4 Security Errors
-
- As stated in Section 6.1.2, strongAuthRequired(8) and
- confidentialityRequired(13) may be returned for any operation.
-
- insufficientAccessRights: The requestor does not have sufficient
- permissions to modify the entry.
-
-6.5 Add Operation Errors
-
- The superior of the entry must exist for the operation to succeed. If
- not, a noSuchObject error is returned and the matchedDN field will
- contain the name of the lowest entry in the directory that was
- matched.
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 19
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- If the add operation succeeds, a result code of success will be
- returned to the client. If the server does not hold the target entry
- of the request, a referral(10) may be returned. If the operation
- fails, the result code will be one of the following from the set of
- name errors, update errors, attribute errors, security errors,
- service errors, and general errors.
-
- The remaining errors listed in this section, are operation-specific.
- An operation may also result in the return of any of the common
- errors, as listed in Section 6.1.
-
-6.5.1 Name Errors
-
- noSuchObject: One or more superiors to the target entry do not exist.
-
- invalidDNSyntax: the DN provided does not have the correct syntax,
-
-6.5.2 Update Errors
-
- namingViolation: Either the target entry cannot be created under the
- specified superior due to DIT structure rules, or the target entry is
- named by an RDN not permitted by the DIT name form rule for its
- object class.
-
- objectClassViolation: An attempt was made to add an entry and one of
- the following conditions existed: A required attribute was not
- specified; an attribute was specified which is not permitted by the
- current object class set in the entry; a structural object class
- value was not specified; an object class value was specified that
- doesnÆt exist in the schema.
-
- entryAlreadyExists: The target entry already exists.
-
-6.5.3 Attribute Errors
-
- undefinedAttributeType: The attribute specified does not exist in the
- server's defined schema.
-
- constraintViolation: The attribute value falls outside the bounds
- specified by the attribute syntax.
-
- attributeOrValueExists: A duplicate attribute value appears in the
- list of attributes for the entry.
-
- invalidAttributeSyntax: The value specified doesnÆt adhere to the
- syntax definition for that attribute.
-
-6.5.4 Security Errors
-
- As stated in Section 6.1.2, strongAuthRequired(8) and
- confidentialityRequired(13) may be returned for any operation.
-
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 20
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- insufficientAccessRights: The requestor does not have sufficient
- permissions to either add the entry or to add one or more of the
- attributes specified.
-
-6.6 Delete Operation Errors
-
- If the delete operation succeeds, a result code of success will be
- returned to the client. If the server does not hold the target entry
- of the request, a referral(10) may be returned. If the operation
- fails, the result code will be one of the following from the set of
- name errors, update errors, security errors, service errors, and
- general errors.
-
- The remaining errors listed in this section, are operation-specific.
- An operation may also result in the return of any of the common
- errors, as listed in Section 6.1.
-
-6.6.1 Name Errors
-
- noSuchObject: The target entry does not exist.
-
- invalidDNSyntax: the DN provided does not have the correct syntax,
-
-6.6.2 Update Errors
-
- notAllowedOnNonLeaf: The target entry is not a leaf object. Only
- objects having no subordinate objects in the tree may be deleted.
-
-6.6.3 Security Errors
-
- As stated in Section 6.1.2, strongAuthRequired(8) and
- confidentialityRequired(13) may be returned for any operation.
-
- insufficientAccessRights: The requestor does not have sufficient
- permissions to delete the entry.
-
-6.7 ModifyDN Operation Errors
-
- Note that X.500 restricts the ModifyDN operation to only affect
- entries that are contained within a single server. If the LDAP server
- is mapped onto DAP, then this restriction will apply, and the
- resultCode affectsMultipleDSAs will be returned if this error
- occurred. In general clients MUST NOT expect to be able to perform
- arbitrary movements of entries and subtrees between servers.
- [RFC2251, Section 4.9]
-
- If the Modify DN operation succeeds then a result code of success
- will be returned to the client. If the server does not hold the
- target entry of the request, a referral(10) may be returned. If the
- operation fails then the result code will be one of the following
- from the set of name errors, update errors, attribute errors,
- security errors, service errors, and general errors.
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 21
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- The remaining errors listed in this section, are operation-specific.
- An operation may also result in the return of any of the common
- errors, as listed in Section 6.1.
-
-6.7.1 Name Errors
-
- noSuchObject: the target object does not exist or a new superior
- object was specified that does not exist.
-
- invalidDNSyntax: the DN provided does not have the correct syntax.
-
-6.7.2 Update Errors
-
- namingViolation: Either the target entry cannot be moved to the
- specified superior due to DIT structure rules, or the target entry is
- named by an RDN not permitted by the DIT name form rule for its
- object class.
-
- objectClassViolation: The client has specified that the old RDN
- values should be removed from the entry (using the 'deleteOldRdn'
- parameter) but the removal of these values would violate the entry's
- schema. [RFC 2251 Section 4.9]
-
- notAllowedOnNonLeaf: If the server does not permit the ModifyDN
- operation on non-leaf entries this error will be returned if the
- client attempts to rename a non-leaf entry
-
- entryAlreadyExists: The target entry already exists.
-
- AffectsMultipleDSAs: X.500 restricts the ModifyDN operation to only
- affect entries that are contained within a single server. If the LDAP
- server is mapped onto DAP, then this restriction will apply, and the
- resultCode affectsMultipleDSAs will be returned if this error
- occurred. In general clients MUST NOT expect to be able to perform
- arbitrary movements of entries and sub-trees between servers.
- [RFC2251, Section 4.9]
-
-6.7.3 Attribute Errors
-
- constraintViolation: The operation would create an attribute value
- outside the normal bounds.
-
-6.7.4 Security Errors
-
- As stated in Section 6.1.2, strongAuthRequired(8) and
- confidentialityRequired(13) may be returned for any operation.
-
- insufficientAccessRights: The requestor does not have sufficient
- permissions to either add the entry or to add one or more of the
- attributes specified.
-
-6.8 Compare Operation Errors
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 22
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- If there exists a value within the attribute being compared that
- matches the purported argument and for which compare permissions is
- granted, the operation returns the value compareTrue in the result,
- otherwise, the operation returns compareFalse. [X511, Section 9.2.4]
- If the server does not hold the target entry of the request, a
- referral(10) may be returned.
-
- If the compare operation can not be completed, then the server may
- return one of the following results from the set of name errors,
- attribute errors, security errors, service errors, and general
- errors.
-
- The remaining errors listed in this section are operation-specific.
- An operation may also result in the return of any of the common
- errors, as listed in Section 6.1.
-
-6.8.1 Name Errors
-
- noSuchObject: the entry to be compared does not exist in the
- directory.
-
- invalidDNSyntax: the DN provided for the entry to be compared does
- not have the correct syntax.
-
-6.8.2 Attribute Errors
-
- noSuchAttribute: the attribute to be compared does not exist in the
- target entry.
-
- invalidAttributeSyntax: The value specified doesnÆt adhere to the
- syntax definition for that attribute.
-
-6.8.3 Security Errors
-
- As stated in Section 6.1.2, strongAuthRequired(8) and
- confidentialityRequired(13) may be returned for any operation.
-
- insufficientAccessRights: If the client does not have read permission
- for the entry to be compared, or for the attribute then
- insufficientAccessRights should be returned, [X511, Section 9.2.4]
-
-6.8.4 Example
-
- The following example is included to demonstrate the expected
- responses for the compare operation.
- Given the following entry:
-
- dn: cn=Foo
- objectClass: top
- objectClass: person
- sn: bar
- userPassword: xyz
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 23
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- i) Compare with userPassword=xyz results in a compareTrue because the
- requested value exists in the entry.
-
- ii) Compare with userPassword=abc results in a compareFalse because
- the entry contains a userPassword attribute but the value abc is not
- present.
-
- iii) Compare with telephoneNumber=123-456-7890 results in a
- noSuchAttribute. The attribute telephoneNumber is permissible in the
- entry based on the schema defined in the server but because it is
- empty it does not exist in the target entry.
-
- iv) Compare with ou=myOrg results in noSuchAttribute. The requested
- attribute is a recognized attribute but it is neither present nor is
- it valid for the target entry.
-
- v) Compare with bogusAttr=abc results in noSuchAttribute. The
- requested attribute is not a recognized attribute nor is it present
- in the target entry.
-
- Note that the response for scenarios 3 through 5 is always
- noSuchAttribute. The semantics of the compare operation is simply
- "does the target entry contain the specified value?" and so no
- distinction is made between a request for an unknown, invalid, or,
- valid but empty attribute. In all cases if the attribute is not
- present in the entry then the result is noSuchAttribute.
-
-6.9 Extended Operation Errors
-
- The results returned for an extended operation vary, depending on the
- particular operation. In any case, extended Operations MAY return any
- result code (excepting 81-90).
-
- If the server does not recognize the request name, it MUST return
- only the response fields from LDAPResult, containing the
- protocolError result code [RFC2251, Section 4.12]
-
-6.10 Operations with no Server Response
-
- The LDAP v3 protocol has two client operations for which no server
- response is returned. Specifically, these are unbindRequest, and
- abandonRequest. Since no response is returned, there is no need to
- consider possible result codes for these operations.
-
-6.11 Unsolicited Notification
-
- In some situations, a server may issue a "response" to a client for
- which there was no client request. This notification "is used to
- signal an extraordinary condition in the server or in the connection
- 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." [RFC2251, Section 4.4]
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 24
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
- RFC 2251 [RFC2251] describes a notice of disconnection in which a
- protocolError, strongAuthRequired, or unavailable result code may be
- returned. The reader is directed there for further information.
-
-6.12 Controls
-
- Section 4.1.12 of [RFC2251] specifies the syntax for controls that
- may be sent as part of a request. [RFC2251] defines no specific
- controls. It should be noted that the semantics of a control may
- alter the result code that might otherwise have been returned for the
- requested operation (see Section 5.2.2.4.6 for example).
-
-7. Security Considerations
-
- This draft is meant to complement and enhance the coverage of result
- codes for LDAP v3, as described in RFC 2251 [RFC2251]. Section 7 of
- RFC 2251 [RFC2251] lists a number of security considerations specific
- to LDAP v3.
-
- Note that in X.500 if the discloseOnError permission is not granted
- then many operations will return noSuchObject instead of a more
- specific error. As there is currently no equivalent for this
- permission in LDAP, LDAP-only servers should return the appropriate
- error code in the event of an error.
-
-8. References
-
- [RFC2026] S. Bradner, "The Internet Standards Process - Revision
- 3", RFC 2026, October 1996.
-
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
- Access Protocol", RFC 2251, December 1997.
-
- [X511] ITU-T Recommendation X.511, "The Directory: Abstract
- Service Definition", 1993.
-
- [TLS] J. Hodges, R.L. Morgan, M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer
- Security", June 1999. <draft-ietf-ldapext-ldapv3-tls-
- 05.txt> "work in progress"
-
- [Net] Netscape Directory SDK 3.0 for C ProgrammerÆs Guide,
- Chapter 19: Result Codes. Available at Error! Bookmark
- not defined.
-
-
-9. Acknowledgments
-
- The production of this document relied heavily on the information
- available from RFC 2251 [RFC2251] and ITU-T Recommendation X.511
- [X511].
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 25
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
-10. Author's Addresses
-
- Mike Just
- Entrust Technologies
- 750 Heron Rd, Tower E
- Ottawa, Ontario, Canada
- mike.just@entrust.com
-
- Kristianne Leclair
- Entrust Technologies
- 750 Heron Rd, Tower E
- Ottawa, Ontario, Canada
- kristianne.leclair@entrust.com
-
- Jim Sermersheim
- Novell
- 122 East 1700 South
- Provo, Utah 84606, USA
- Error! Bookmark not defined.
-
- Mark Smith
- Netscape
- 501 Ellis Street
- Mountain View, CA 94043
- Error! Bookmark not defined.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 26
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
-11 Appendix A: Operation/Response Matrix
-
-
- Result Codes Operations
-
- B S M A D M C
- i e o d e o o
- n a d d l d m
- d r i e D p
- c f t N a
- h y e r
- e
-
- Non-erroneous results
-
- success (0) X X X X X X
-
- compareFalse (5) X
-
- compareTrue (6) X
-
- referral (10) X X X X X X X
-
- saslBindInProgress (14) X
-
- Name errors
-
- noSuchObject (32) X X X X X X
-
- aliasProblem (33) X
-
- invalidDNSyntax (34) X X X X X X X
-
- Update errors
-
- namingViolation (64) X X
-
- objectClassViolation (65) X X X
-
- notAllowedOnNonLeaf (66) X X
-
- notAllowedonRDN (67) X
-
- entryAlreadyExists (68) X X
-
- objectClassModesProhibite X
- d (69)
-
- affectsMultipleDSAs (71) X
-
- Attribute errors
-
- noSuchAttribute(16) X X
-
- undefinedAttributeType X X
- (17)
-
- inappropriateMatching X
- (18)
-
- constraintViolation (19) X X X
-
- attributeOrValueExists X X
- (20)
-
- invalidAttributeSyntax X X
- (21)
-
- Security errors
-
- authMethodNotSupported X
- (7)
-
- strongAuthRequired (8) X X X X X X X
-
- confidentialityRequred(13 X X X X X X X
- )
-
- aliasDereferencingProblem X
- (36)
-
- inappropriateAuthenticati X
- on (48)
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 27
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
- invalidCredentials (49) X
-
- insufficientAccessRights X X X X X X
- (50)
-
- Service errors
-
- operationsError (1) X X X X X X
-
- protocolError (2) X X X X X X X
-
- timeLimitExceeded (3) X X X X X X X
-
- sizeLimitExceeded (4) X
-
- adminLimitExceeded (11) X X X X X X X
-
- unavailableCriticialExten X X X X X X X
- sion (12)
-
- busy (51) X X X X X X X
-
- unavailable (52) X X X X X X X
-
- unwillingToPerform (53) X X X X X X X
-
- loopDetect (54) X X X X X X X
-
- General errors
-
- other (80) X X X X X X X
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 28
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000
-
-
-12 Full Copyright Statement
-
- Copyright (C) The Internet Society (Oct 1999). 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
- ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 29
-
+++ /dev/null
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires: 11 January 2001 11 July 2000
-
-
- LDAP Authentication Password Attribute
- <draft-zeilenga-ldap-authpasswd-03.txt>
-
-
-
-1. Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extension Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- 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.
-
- Copyright 2000, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-2. Abstract
-
- This document describes schema for storing information in support of
- user/password authentication in a LDAP [RFC2251] directory. The
- document defines the authPassword attribute type and related schema.
- The attribute type is used to store values derived from the user's
- password(s) (commonly using cryptographic strength one-way hash).
- authPassword is intended to used instead of clear text password
-
-
-
-Zeilenga [Page 1]
-\f
-INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
-
-
- storage mechanisms such as userPassword [RFC2256]. The values of
- authPassword may be used to support both LDAP "simple" and SASL
- [RFC2222] password authentication mechanisms [RFC2829].
-
- The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
- NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
- this document are to be interpreted as described in RFC 2119
- [RFC2119].
-
-
-3. Background and Intended Use
-
- The userPassword attribute type [RFC 2256] is intended be used to used
- to support the LDAP [RFC2251] "simple" bind operation. However,
- values of userPassword must be clear text passwords. It is often
- desirable to store values derived from the user's password(s) instead
- of actual passwords.
-
- The authPassword attribute type is intended to be used to store
- information used to implement password based authentication. The
- attribute type may be used by LDAP servers to implement user/password
- authentication operations [RFC2829] such "simple" and SASL [RFC2222] /
- DIGEST-MD5 [RFC2831].
-
- The attribute type supports multiple storage schemes. A matching rule
- is provided for use with extensible search filters to allow clients to
- assert that a clear text password "matches" one of the attribute's
- values. Storage schemes often use of cryptographic strength one-way
- hashing.
-
- This attribute may be used in conjunction with server side password
- generation mechanisms (such as [PW-EXOP]).
-
- Access to this attribute may governed by administrative controls such
- as those which implement password change policies.
-
-
-4. Schema Definitions
-
- The following schema definitions are described in terms of LDAPv3
- Attribute Syntax Definitions [RFC2252] with specific syntax detailed
- using Augmented BNF [RFC2234].
-
- Editor's Note: object identifiers (OIDs) will be assigned before this
- document is published as an RFC.
-
-4.1. authPasswordSyntax
-
-
-
-
-Zeilenga [Page 2]
-\f
-INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
-
-
- ( authPasswordSyntaxOID
- DESC 'authentication password syntax' )
-
- Values of this syntax are encoded according to the following BNF:
-
- authPasswordValue = w scheme s [authInfo] s authValue w
- scheme = <an IA5 string of uppercase letters, numbers,
- and "-", "_", and "/">
- authInfo = schemeSpecificValue
- authValue = schemeSpecfiicValue
- schemeSpecificValue = <an IA5 printable string
- not containing "$" or " ">
- s = w sep w
- w = *sp
- sep = "$" ; an IA5 dollar sign (36)
- sp = " " ; an IA5 space (20)
-
- where scheme describes the storage mechanism, authInfo and authValue
- are a scheme specific. The authInfo field is often a base64 encoded
- salt. The authValue field is often a base64 encoded value derived
- from a user's password(s). Values of this attribute are case
- sensitive.
-
- This document describes a number of schemes, as well as requirements
- for the scheme naming, in section 5.
-
-
-4.2. authPasswordMatch
-
- ( authPasswordMatchOID
- NAME 'authPasswordMatch'
- DESC 'authentication password matching rule'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
-
- This matching rule allows a client to assert that a password matches
- values of authPasswordSyntax using an extensibleMatch filter
- component. Each value is matched per its scheme. The assertion is
- TRUE if one or more attribute values matches the asserted value, FALSE
- if all values do not matches, and Undefined otherwise.
-
- Servers which support use of this matching rule SHOULD publish
- appropriate matchingRuleUse values per [RFC2252], 4.4.
-
- Transfer of authPasswordMatch assertion values is strongly discouraged
- where the underlying transport service cannot guarantee
- confidentiality and may result in disclosure of the values to
- unauthorized parties.
-
-
-
-
-Zeilenga [Page 3]
-\f
-INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
-
-
-4.3. supportedAuthPasswordSchemes
-
- ( supportedAuthPasswordSchemesOID
- NAME 'supportedAuthPasswordSchemes'
- DESC 'supported password storage schemes'
- EQUALITY caseExactIA5Match
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
- USAGE dSAOperation )
-
- The values of this attribute are names of supported authentication
- password schemes which the server supports. The syntax of a scheme
- name is described in section 4.1. This attribute may only be present
- in the root DSE. If the server does not support any mechanisms this
- attribute will not be present.
-
-
-4.4. authPassword
-
- ( authPasswordOID NAME 'authPassword'
- SYNTAX authPasswordSyntaxOID )
-
- The values of this attribute are representative of the user's
- password(s) and conform to the authPasswordSyntax described in 4.1.
- The values of this attribute may be used for authentication purposes.
-
- This attribute type is defined without any built-in matching rules.
- The absence of an EQUALITY matching rules disallows modification of
- individual values.
-
- Transfer of authPassword values is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the values to unauthorized parties.
-
-
-4.5. authPasswordObject
-
- ( authPasswordObjectOID NAME 'authPasswordObject'
- DESC 'authentication password mix in class'
- MAY 'authPassword' AUXILIARY )
-
- Entries of this object class may contain authPassword attribute types.
-
-
-5. Schemes
-
- This section describes the "MD5", "SHA1", and "SASL/DIGEST-MD5".
- Other schemes may be defined by other documents. Schemes starting
- with string "SASL/" indicate association with a SASL mechanism.
-
-
-
-Zeilenga [Page 4]
-\f
-INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
-
-
- Schemes which are not described by standard track documents SHOULD be
- named with a leading "X-" or, if associated with a SASL mechanism,
- "SASL/X-" to indicate they are a private or implementation specific
- mechanism, or may be named using the dotted-decimal representation
- [RFC2252] of an OID assigned to the mechanism.
-
-
-5.1. MD5 scheme
-
- The MD5 [RFC1321] scheme name is "MD5".
-
- The authValue is the base64 encoding of an MD5 digest of the
- concatenation the user password and optional salt. The base64
- encoding of the salt is provided in the authInfo field.
- Implementations of this scheme must support salts up to 128-bit in
- length. Use with a 64-bit or larger salt is RECOMMENDED.
-
- Example:
- Given a user "joe" who's password is "mary" and a salt of "salt",
- the authInfo field would be the base64 encoding of "salt" and the
- authValue field would be the base64 encoding of the MD5 digest of
- "marysalt".
-
- A match against an asserted password and an attribute value of this
- scheme SHALL be true if and only if the MD5 digest of concatenation of
- the asserted value and the salt is equal to the MD5 digest contained
- in AuthValue. The match SHALL be undefined if the server is unable to
- complete the equality test for any reason. Otherwise the match SHALL
- be false.
-
- Values of this scheme SHOULD only be used to implement simple
- user/password authentication.
-
- It is RECOMMENDED that values of this scheme be protected as if they
- were clear text passwords.
-
-
-5.2. SHA1 scheme
-
- The SHA1 [SHA1] scheme name is "SHA1".
-
- The authValue is the base64 encoding of an SHA1 digest of the
- concatenation the user password and the optional salt. The base64
- encoding of the salt is provided in the authInfo field.
- Implementations of this scheme must support salts up to 128-bit in
- length. Use with a 64-bit or larger salt is RECOMMENDED.
-
- Example:
-
-
-
-Zeilenga [Page 5]
-\f
-INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
-
-
- Given a user "joe" who's password is "mary" and a salt of "salt",
- the authInfo field would be the base64 encoding of "salt" and the
- authValue field would be the base64 encoding of the SHA1 digest of
- "marysalt".
-
- A match against an asserted password and an attribute value of this
- scheme SHALL be true if and only if the SHA1 digest of concatenation
- of the asserted value and the salt is equal to the SHA1 digest
- contained in AuthValue. The match SHALL be undefined if the server is
- unable to complete the equality test for any reason. Otherwise the
- match SHALL be false.
-
- Values of this scheme SHOULD only be used to implement simple
- user/password authentication.
-
- It is RECOMMENDED that values of this scheme be protected as if they
- were clear text passwords.
-
-
-5.3. DIGEST-MD5 scheme
-
- The DIGEST-MD5 scheme name is "SASL/DIGEST-MD5".
-
- The authValue is the base64 encoding of
- H( { username-value, ":", realm-value, ":", passwd } )
-
- and authInfo is the base64 encoding of
- { username-value, ":", realm-value }
-
- as defined by RFC2831.
-
- Example:
- Given a user "joe" within the realm "localhost" who's password is
- "mary", the info field would be the base64 encoding of
- "joe:localhost" and the authValue field would be the base64 encoding
- of the MD5 digest of "joe:localhost:mary".
-
- Values of this scheme SHOULD only be used to implement the
- SASL/DIGEST-MD5 as described by the Authentication Methods for LDAP
- [RFC2829]. A simple password assertion against a value of this scheme
- SHALL be considered undefined.
-
- Values of this scheme MUST be protected as if it the values were clear
- text passwords per reasons detailed in DIGEST-MD5, Section 3.9,
- "Storing Passwords."
-
-
-6. Implementation Issues
-
-
-
-Zeilenga [Page 6]
-\f
-INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
-
-
- For implementations of this specification:
-
- Servers MAY restrict which schemes are used in conjunction with a
- particular authentication process but SHOULD use all values of
- selected schemes. If the asserted password matches any of the
- stored values, the asserted password SHOULD be considered valid.
- Servers MAY use other authentication storage mechanisms, such as
- userPassword or an external password store, in conjunction with
- authPassword to support the authentication process.
-
- Servers that support simple bind MUST support the MD5 scheme and
- SHOULD support the SHA1 scheme.
-
- Servers SHOULD not publish values of authPassword nor allow
- operations which expose authPassword or AuthPasswordMatch values to
- unless confidentiality protection is in place.
-
- Clients SHOULD not initiate operations which provide or request
- values of authPassword or make authPasswordMatch assertions unless
- confidentiality protection is in place.
-
- Clients SHOULD not assume that a successful AuthPasswordMatch,
- whether by compare or search, is sufficient to gain directory
- access. The bind operation MUST be used to authentication to the
- directory.
-
-
-7. Security Considerations
-
- This document describes how authentication information may be stored
- in a directory. Authentication information must be adequately
- protected as unintended disclosure will allow attackers to gain
- immediate access to the directory as described by [RFC2829].
-
- Values of authPassword SHOULD be protected as if they were clear text
- passwords. When values are transferred, privacy protections, such as
- IPSEC or TLS, SHOULD be in place.
-
- Clients SHOULD use strong authentication mechanisms [RFC2829].
-
- AuthPasswordMatch matching rule allows applications to test the
- validity of a user password and, hence, may be used to mount a
- dictionary attack. Servers SHOULD take appropriate measures to
- protect the directory from such attacks.
-
- Some password schemes may require CPU intensive operations. Servers
- SHOULD take appropriate measures to protect against Denial of Service
- attacks.
-
-
-
-Zeilenga [Page 7]
-\f
-INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
-
-
- AuthPassword does not restrict an authentication identity to a single
- password. An attacker who gains write access to this attribute may
- store additional values without disabling the user's true password(s).
- Use of policy aware clients and servers is RECOMMENDED.
-
- The level of protection offered against various attacks differ from
- scheme to scheme. It is RECOMMENDED that servers support scheme
- selection as a configuration item. This allows for a scheme to be
- easily disabled if a significant security flaw is discovered.
-
-
-8. Copyright
-
- Copyright 2000, The Internet Society. 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 AUTHORS, 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.
-
-
-9. Acknowledgment
-
- This document borrows from a number of IETF documents and is based
- upon input from the IETF LDAPext working group.
-
-
-10. Bibliography
-
- [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
-
-
-
-Zeilenga [Page 8]
-\f
-INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
-
-
- April 1992
-
- [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)",
- RFC 2222, October 1997.
-
- [RFC2234] D. Crocker (editor), P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [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.
-
- [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC2307] L. Howard, "An Approach for Using LDAP as a Network
- Information Service", RFC 2307, March 1998.
-
- [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
- "Authentication Methods for LDAP", RFC 2829, June 2000.
-
- [RFC2831] P. Leach, C. Newman, "Using Digest Authentication as a SASL
- Mechanism", RFC 2831, June 2000.
-
- [PW-EXOP] K. Zeilenga, "LDAP Password Modify Extended Operation"
- draft-zeilenga-ldap-passwd-exop-xx.txt, a work in progress.
-
- [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
-
-
-11. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-
-
-
-
-
-
-
-
-Zeilenga [Page 9]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires: 4 January 2001 4 July 2000
-
-
- LDAPv3: Grouping of Related Operations
- <draft-zeilenga-ldap-grouping-00.txt>
-
-
-Status of Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extension Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- 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.
-
- Copyright 2000, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-1. Abstract
-
- This document provides a general mechanisms for grouping related LDAP
- operations. Grouping of operations may be used to support
- replication, proxies, and higher level operations such as
- transactions. This document describes a set of LDAP [RFC2251]
- extended operations and other protocol and schema elements to support
- grouping of related operations.
-
-
-
-
-Zeilenga [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
-2. Overview
-
- This document provides a mechanism to allow clients to group
- operations.
-
- A group of operations is defined as a set of operations upon a common
- session identified by a unique cookie. All requests which are
- initiated with the same cookie belong to same grouping. The cookie is
- obtained using the create group operation and is normally valid until
- the end group operation is issued. A group may be ended by a server
- prematurely as noted described below.
-
- Operations regardless of their grouping (or lack of grouping) may be
- intermixed. Groups may be nested.
-
- Each group is of a particular type. This type defines the semantics
- of the group and is specified when the group is created.
-
- The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
- "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
- interpreted as described in [RFC2119].
-
-
-3. Protocol Elements
-
- This document describes two extended operations, one unsolicited
- notification, and one control. Extended operations and controls are
- described by LDAP [RFC2251] as follows:
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL
- }
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS of LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL
- }
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL
- }
-
-
- Editor's Note:
-
-
-
-Zeilenga [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- OID which appear in this document are fictious. Actual OIDs will be
- assigned before this document is progressed.
-
-3.1 Common Protocol Elements
-
- groupCookie :== OCTET STRING
-
- A groupCookie is an arbitrary octet string uniquely identify a
- grouping of related operations within the session.
-
- A groupCookie is a notational convenience.
-
-
-
-3.2 createGrouping Operation
-
- The createGrouping extended operation is used to create or start a
- grouping of related operations. The operation consists of the
- createGroupingRequest and the createGroupingResponse. The OID
- createGroupingOID identifies this operation and SHOULD be listed as a
- value of supportedExtensions in the root DSE of servers which support
- this operation.
-
- createGroupingOID ::= "1.1.1"
-
-
-3.2.1 createGroupingRequest
-
- The client initiates this operation by sending a
- createGroupingRequest. This request is an ExtendedRequest where the
- requestName is the value createGroupOID and requestValue is BER
- encoded createGroupingRequestValue
-
- createGroupingRequestValue ::= SEQUENCE {
- createGroupType [0] LDAPOID,
- createGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where createGroupType is an OID that describes the specific type of
- grouping and createGroupValue contains a type specific payload.
-
-
-3.2.1 createGroupingResponse
-
- The createGroupingResponse is sent in response to a
- createGroupingRequest. This response is an ExtendedResponse where the
- responseName MUST be the value of the requestName provided in request
- and the response is a BER encoded createGroupingResponseValue.
-
-
-
-Zeilenga [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- createGroupingResponseValue ::= SEQUENCE {
- createGroupCookie [0] groupCookie,
- createGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where createGroupCookie is a cookie uniquely identifying the grouping
- and createGroupValue is a type specific payload.
-
-
-3.3 endGrouping Operation
-
- The endGrouping extended operation is used to end or stop a grouping
- of related operations. The operation consists of the
- endGroupingRequest and the endGroupingResponse. The OID
- endGroupingOID identifies this operation and SHOULD be listed as a
- value of supportedExtensions in the root DSE of servers which support
- this operation.
-
- endGroupingOID ::= "1.1.2"
-
-
-3.3.1 endGroupingRequest
-
- The client initiates this operation by sending an endGroupingRequest.
- This request is an ExtendedRequest where the requestName is the value
- endGroupOID and requestValue is BER encoded endGroupingRequestValue
-
- endGroupingRequestValue ::= SEQUENCE {
- endGroupCookie [0] groupCookie,
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where endGroupCookie is an cookie identifying the grouping and
- groupValue contains a type specific payload.
-
-
-3.3.2 endGroupingResponse
-
- The endGroupingResponse is sent in response to a endGroupingRequest.
- This response is an ExtendedResponse where the responseName MUST be
- the value of the requestName provided in request and the response is a
- BER encoded endGroupingResponseValue
-
- endGroupingResponseValue ::= SEQUENCE {
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where groupValue is a type specific payload.
-
-
-
-Zeilenga [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
-3.4 endGroupingNotice
-
- The endGroupingNotice is an LDAP unsolicited notification. The
- notification may be sent to the client to end a grouping which the
- server is unable or unwilling to continue to process. The notice is
- an extendedResponse where the responseName is the OID
- endGroupingNoticeOID and the response is a BER encoded
- endGroupingNoticeValue
-
- endGroupingNoticeOID ::= "1.1.3"
-
- endGroupingNoticeValue ::= SEQUENCE {
- endGroupingCookie [0] groupCookie,
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where endGroupingCookie is a cookie uniquely identifying the grouping
- and groupingValue contains a type specific payload.
-
-
-3.5 groupingControl
-
- The groupingControl is used to identify requests and responses as
- belonging to grouping of operations. The groupingControl is a Control
- where the controlType is the OID groupingControlOID and the
- criticalValue is a BER encoded groupingControlValue
-
- groupingControlOID ::= "1.1.4"
-
- groupingControlValue ::= SEQUENCE {
- groupingCookie [0] groupCookie,
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where groupingCookie is a cookie uniquely identifying the grouping,
- the critical is TRUE, and groupingValue contains a type specific
- payload.
-
- The value groupingControlOID SHOULD be listed as a value of
- supportedControls in the root DSE by servers which support this
- control.
-
- The control MAY be present on add, compare, delete, moddn, modify, and
- search requests and responses. The control SHALL NOT be present on a
- abandon, bind, unbind. The control SHALL NOT be present on any
- extended operation which affects the behavior of the session such as
- the Start TLS [RFC2830] operation. The control SHALL NOT be present
- if the operation includes any control which likewise causes the
-
-
-
-Zeilenga [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- operation to affects the behavior of the session.
-
- The control SHALL NOT appear multiple times in the same LDAP PDU and.
- If multiple occurrences of the control are detected, the PDU MUST be
- treated as a protocol error.
-
-4. Schema Elements
-
-4.1. supportedGroupingTypes
-
- Servers SHOULD publish grouping types they support listing their OID
- as values of the supportedGrouping attribute type in the root DSE.
- The supportedGrouping attribute type is defined as:
-
- ( 1.1.5 NAME 'supportedGroupingTypes'
- DESC 'supported types of groupings of operations'
- EQUALITY objectIdentifierMatch
- SYNTAX ObjectIdentifierSyntax )
-
-
-5. Operational Semantics
-
- This section needs work.
-
-
-5.1 Grouping Operations
-
-
-5.1.1 createGrouping
-
- To group related operations, the client MUST request a groupCookie
- from the server by sending a createGroupingRequest as described in
- 3.2.1. The client SHALL provide type specific payload in
- createGroupValue if so required by the grouping type.
-
- The server SHALL respond with a createGroupingResponse as described in
- 3.2.2. If the server is willing and able to create the grouping as
- requested (and per type requirements), it SHALL respond with success,
- provide a session-unique groupCookie and, if appropriate, a type
- specific payload. Otherwise the server SHALL respond with a non-
- successful response and provide no groupCookie, but MAY, if
- appropriate, provide a type specific payload.
-
-
-5.1.2 endGrouping
-
- When the client wishes to end the grouping, the client SHALL send a
- endGroupingRequest as described in 3.3.1. The client SHALL provide
-
-
-
-Zeilenga [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- the groupCookie of the grouping to be ended and MAY provided a type
- specific payload.
-
- The server SHALL respond with an endGroupingResponse as described in
- 3.3.2.
-
-
-5.1.3 endGroupNotice
-
- The server MAY end a group without solicitation for any reason but
- MUST send a endGrouping Notice, as described in 3.4, indicating this
- action. The server SHALL provide the groupCookie of the group it
- terminated and MAY provide a type specific payload. The notice SHALL
- have a non-success resultCode.
-
-
-5.1.4 grouped operations
-
- Operations with a group are carry a groupingControl as described in
- 3.5.
-
- Group type specifications MAY restrict the types and/or number of
- operations which may be related. Servers MAY also place restrictions
- upon groupings. Clients SHOULD NOT assume arbitrary support for
- grouping.
-
-
-5.1.5 nested groupings
-
- Groups of the same or different types may be nested. A nested group
- is instantiated by providing a groupingControl containing the parent
- group with the createGroupingRequest.
-
- Group type specifications MAY restrict the types of groupings which
- may be nested. Servers MAY also place restrictions upon nesting.
- Clients SHOULD NOT assume arbitrary support for nesting.
-
-
-5.3 Other Operations
-
- Upon issuing of any grouping operation, semantics of non-grouping
- operations listed is modified as described below.
-
-5.3.1 bind
-
- The client SHOULD end all outstanding groupings before issuing a bind
- request.
-
-
-
-
-Zeilenga [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- The bind operation MUST, in addition to the behavior described in RFC
- 2251, must abandon all outstanding groups.
-
-
-5.3.2 unbind
-
- The unbind operation MUST, in addition to the behavior described in
- RFC 2251, must abandon all outstanding groups.
-
-
-5.3.3 Start TLS
-
- The client SHALL end all outstanding groupings before issuing a Start
- TLS request.
-
- The Start TLS operation MUST, in addition to the behavior described in
- RFC 2830, return operationsError if there are any outstanding
- groupings.
-
-
-7. Security Considerations
-
- This mechanism may be used to support complex groupings of related
- operations for arbitrary purposes. This document places no
- restrictions on how the grouped operations relate to each other.
-
- It is conceived that different groups of operations may have different
- authorization and/or access controls associated with them (when used
- to multiplex proxied directory sessions). Authors of specifications
- for such groupings take special care in addressing security issues.
-
- It is conceived that different groups of operations may form complex
- super-operations such as transactions. Authors of specifications for
- such groupings should take special care to address denial of service
- issues.
-
-
-8. References
-
- [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
- Requirement Levels", Harvard University, RFC 2119, March
- 1997.
-
- [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
-
-9. Acknowledgments
-
-
-
-Zeilenga [Page 8]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-00 4 July 2000
-
-
- The author gratefully acknowledge the contributions of the IETF LDUP
- and LDAPext working group.
-
-
-10. Additional Information
-
- Discussions regarding these suggestions may directed to the author:
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
- or the LDAPext Working Group mailing list:
-
- <ietf-ldapext@netscape.com>
-
-
-Copyright 2000, The Internet Society. 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 AUTHORS, 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.
-
-
-
-
-
-
-
-
-Zeilenga [Page 9]
-\f
projects / thirdparty / openldap.git / commitdiff
