diff options
| author | Simo Sorce <idra@samba.org> | 2006-08-06 18:05:43 +0000 |
|---|---|---|
| committer | Gerald (Jerry) Carter <jerry@samba.org> | 2007-10-10 14:15:25 -0500 |
| commit | a72a455e29fa695d06699cbca449ba84ce5fc43a (patch) | |
| tree | c4d58f632a612fb7fa6a3be58c657fddb4c994a6 /source4/ldap_server | |
| parent | c3e837eaafffcfcbd8f477ab653cb8e38ec6b67c (diff) | |
| download | samba-a72a455e29fa695d06699cbca449ba84ce5fc43a.tar.gz | |
r17433: remove obsoleted RFCs
(This used to be commit 7dffabc744271b0ab98d00c0cc23600d1b536d29)
Diffstat (limited to 'source4/ldap_server')
| -rw-r--r-- | source4/ldap_server/devdocs/Index | 10 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/rfc1777.txt | 1235 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/rfc1779.txt | 451 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/rfc2251.txt | 2803 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/rfc2252.txt | 1795 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/rfc2253.txt | 563 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/rfc2254.txt | 451 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/rfc2255.txt | 563 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/rfc2256.txt | 1123 |
9 files changed, 1 insertions, 8993 deletions
diff --git a/source4/ldap_server/devdocs/Index b/source4/ldap_server/devdocs/Index index 6a83af13ac4..3be797ea5b6 100644 --- a/source4/ldap_server/devdocs/Index +++ b/source4/ldap_server/devdocs/Index @@ -1,13 +1,4 @@ -RFC 1777 - Lightweight Directory Access Protocol -RFC 1778 - The String Representation of Standard Attribute Syntaxes -RFC 1779 - A String Representation of Distinguished Names RFC 1823 - The LDAP Application Program Interface -RFC 2251 - Lightweight Directory Access Protocol (v3) -RFC 2252 - LDAPv3: Attribute Syntax Definitions -RFC 2253 - LDAPv3: UTF-8 String Representation of Distinguished Names -RFC 2254 - The String Representation of LDAP Search Filters -RFC 2255 - The LDAP URL Format -RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3 RFC 2307 - An Approach for Using LDAP as a Network Information Service RFC 2696 - LDAP Control Extension for Simple Paged Results Manipulation RFC 2849 - The LDAP Data Interchange Format (LDIF) - Technical Specification @@ -17,3 +8,4 @@ RFC 3296 - Named Subordinate References in LDAP Directories Expired but used Draft: ldapext-ldapv3-vlv-04: LDAP Extensions for Scrolling View Browsing of Search Results +RFC 4510 diff --git a/source4/ldap_server/devdocs/rfc1777.txt b/source4/ldap_server/devdocs/rfc1777.txt deleted file mode 100644 index f5593e72a20..00000000000 --- a/source4/ldap_server/devdocs/rfc1777.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -Network Working Group W. Yeong -Request for Comments: 1777 Performance Systems International -Obsoletes: 1487 T. Howes -Category: Standards Track University of Michigan - S. Kille - ISODE Consortium - March 1995 - - - Lightweight Directory Access Protocol - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The protocol described in this document is designed to provide access - to the X.500 Directory while not incurring the resource requirements - of the Directory Access Protocol (DAP). This protocol is specifically - targeted at simple management applications and browser applications - that provide simple read/write interactive access to the X.500 - Directory, and is intended to be a complement to the DAP itself. - - Key aspects of LDAP are: - - - Protocol elements are carried directly over TCP or other transport, - bypassing much of the session/presentation overhead. - - - Many protocol data elements are encoding as ordinary strings (e.g., - Distinguished Names). - - - A lightweight BER encoding is used to encode all protocol elements. - -1. History - - The tremendous interest in X.500 [1,2] technology in the Internet has - lead to efforts to reduce the high "cost of entry" associated with - use of the technology, such as the Directory Assistance Service [3] - and DIXIE [4]. While efforts such as these have met with success, - they have been solutions based on particular implementations and as - such have limited applicability. This document continues the efforts - to define Directory protocol alternatives but departs from previous - efforts in that it consciously avoids dependence on particular - - - -Yeong, Howes & Kille [Page 1] - -RFC 1777 LDAP March 1995 - - - implementations. - -2. Protocol Model - - The general model adopted by this protocol is one of clients - performing protocol operations against servers. In this model, this - is accomplished by a client transmitting a protocol request - describing the operation to be performed to a server, which is then - responsible for performing the necessary operations on the Directory. - Upon completion of the necessary operations, the server returns a - response containing any results or errors to the requesting client. - In keeping with the goal of easing the costs associated with use of - the Directory, it is an objective of this protocol to minimize the - complexity of clients so as to facilitate widespread deployment of - applications capable of utilizing the Directory. - - Note that, although servers are required to return responses whenever - such responses are defined in the protocol, there is no requirement - for synchronous behavior on the part of either client or server - implementations: requests and responses for multiple operations may - be exchanged by client and servers in any order, as long as clients - eventually receive a response for every request that requires one. - - Consistent with the model of servers performing protocol operations - on behalf of clients, it is also to be noted that protocol servers - are expected to handle referrals without resorting to the return of - such referrals to the client. This protocol makes no provisions for - the return of referrals to clients, as the model is one of servers - ensuring the performance of all necessary operations in the - Directory, with only final results or errors being returned by - servers to clients. - - Note that this protocol can be mapped to a strict subset of the - directory abstract service, so it can be cleanly provided by the DAP. - -3. Mapping Onto Transport Services - - This protocol is designed to run over connection-oriented, reliable - transports, with all 8 bits in an octet being significant in the data - stream. Specifications for two underlying services are defined here, - though others are also possible. - -3.1. Transmission Control Protocol (TCP) - - The LDAPMessage PDUs are mapped directly onto the TCP bytestream. - Server implementations running over the TCP should provide a protocol - listener on port 389. - - - - -Yeong, Howes & Kille [Page 2] - -RFC 1777 LDAP March 1995 - - -3.2. Connection Oriented Transport Service (COTS) - - The connection is established. No special use of T-Connect is made. - Each LDAPMessage PDU is mapped directly onto T-Data. - -4. Elements of Protocol - - For the purposes of protocol exchanges, all protocol operations are - encapsulated in a common envelope, the LDAPMessage, which is defined - as follows: - - LDAPMessage ::= - SEQUENCE { - messageID MessageID, - protocolOp CHOICE { - bindRequest BindRequest, - bindResponse BindResponse, - unbindRequest UnbindRequest, - searchRequest SearchRequest, - searchResponse SearchResponse, - modifyRequest ModifyRequest, - modifyResponse ModifyResponse, - addRequest AddRequest, - addResponse AddResponse, - delRequest DelRequest, - delResponse DelResponse, - modifyRDNRequest ModifyRDNRequest, - modifyRDNResponse ModifyRDNResponse, - compareDNRequest CompareRequest, - compareDNResponse CompareResponse, - abandonRequest AbandonRequest - } - } - - MessageID ::= INTEGER (0 .. maxInt) - - The function of the LDAPMessage is to provide an envelope containing - common fields required in all protocol exchanges. At this time the - only common field is a message ID, which is required to have a value - different from the values of any other requests outstanding in the - LDAP session of which this message is a part. - - The message ID value must be echoed in all LDAPMessage envelopes - encapsulting responses corresponding to the request contained in the - LDAPMessage in which the message ID value was originally used. - - In addition to the LDAPMessage defined above, the following - definitions are also used in defining protocol operations: - - - -Yeong, Howes & Kille [Page 3] - -RFC 1777 LDAP March 1995 - - - LDAPString ::= OCTET STRING - - The LDAPString is a notational convenience to indicate that, although - strings of LDAPString type encode as OCTET STRING types, the legal - character set in such strings is limited to the IA5 character set. - - LDAPDN ::= LDAPString - - RelativeLDAPDN ::= LDAPString - - An LDAPDN and a RelativeLDAPDN are respectively defined to be the - representation of a Distinguished Name and a Relative Distinguished - Name after encoding according to the specification in [5], such that - - <distinguished-name> ::= <name> - - <relative-distinguished-name> ::= <name-component> - - where <name> and <name-component> are as defined in [5]. - - AttributeValueAssertion ::= - SEQUENCE { - attributeType AttributeType, - attributeValue AttributeValue - } - - The AttributeValueAssertion type definition is similar to the one in - the X.500 Directory standards. - - AttributeType ::= LDAPString - - AttributeValue ::= OCTET STRING - - An AttributeType value takes on as its value the textual string - associated with that AttributeType in the X.500 Directory standards. - For example, the AttributeType 'organizationName' with object - identifier 2.5.4.10 is represented as an AttributeType in this - protocol by the string "organizationName". In the event that a - protocol implementation encounters an Attribute Type with which it - cannot associate a textual string, an ASCII string encoding of the - object identifier associated with the Attribute Type may be - subsitituted. For example, the organizationName AttributeType may be - represented by the ASCII string "2.5.4.10" if a protocol - implementation is unable to associate the string "organizationName" - with it. - - - - - - -Yeong, Howes & Kille [Page 4] - -RFC 1777 LDAP March 1995 - - - A field of type AttributeValue takes on as its value an octet string - encoding of a Directory AttributeValue type. The definition of these - string encodings for different Directory AttributeValue types may be - found in companions to this document that define the encodings of - various attribute syntaxes such as [6]. - - LDAPResult ::= - SEQUENCE { - resultCode ENUMERATED { - success (0), - operationsError (1), - protocolError (2), - timeLimitExceeded (3), - sizeLimitExceeded (4), - compareFalse (5), - compareTrue (6), - authMethodNotSupported (7), - strongAuthRequired (8), - noSuchAttribute (16), - undefinedAttributeType (17), - inappropriateMatching (18), - constraintViolation (19), - attributeOrValueExists (20), - invalidAttributeSyntax (21), - noSuchObject (32), - aliasProblem (33), - invalidDNSyntax (34), - isLeaf (35), - aliasDereferencingProblem (36), - inappropriateAuthentication (48), - invalidCredentials (49), - insufficientAccessRights (50), - busy (51), - unavailable (52), - unwillingToPerform (53), - loopDetect (54), - namingViolation (64), - objectClassViolation (65), - notAllowedOnNonLeaf (66), - notAllowedOnRDN (67), - entryAlreadyExists (68), - objectClassModsProhibited (69), - other (80) - }, - matchedDN LDAPDN, - errorMessage LDAPString - } - - - - -Yeong, Howes & Kille [Page 5] - -RFC 1777 LDAP March 1995 - - - The LDAPResult is the construct used in this protocol to return - success or failure indications from servers to clients. In response - to various requests, servers will return responses containing fields - of type LDAPResult to indicate the final status of a protocol - operation request. The errorMessage field of this construct may, at - the servers option, be used to return an ASCII string containing a - textual, human-readable error diagnostic. As this error diagnostic is - not standardized, implementations should not rely on the values - returned. If the server chooses not to return a textual diagnostic, - the errorMessage field of the LDAPResult type should contain a zero - length string. - - For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax, - isLeaf, and aliasDereferencingProblem, the matchedDN field is set to - the name of the lowest entry (object or alias) in the DIT that was - matched and is a truncated form of the name provided or, if an alias - has been dereferenced, of the resulting name. The matchedDN field - should be set to NULL DN (a zero length string) in all other cases. - -4.1. Bind Operation - - The function of the Bind Operation is to initiate a protocol session - between a client and a server, and to allow the authentication of the - client to the server. The Bind Operation must be the first operation - request received by a server from a client in a protocol session. - The Bind Request is defined as follows: - - BindRequest ::= - [APPLICATION 0] SEQUENCE { - version INTEGER (1 .. 127), - name LDAPDN, - authentication CHOICE { - simple [0] OCTET STRING, - krbv42LDAP [1] OCTET STRING, - krbv42DSA [2] OCTET STRING - } - } - - Parameters of the Bind Request are: - - - version: A version number indicating the version of the protocol to - be used in this protocol session. This document describes version - 2 of the LDAP protocol. Note that there is no version negotiation, - and the client should just set this parameter to the version it - desires. - - - - - - -Yeong, Howes & Kille [Page 6] - -RFC 1777 LDAP March 1995 - - - - name: The name of the Directory object that the client wishes to - bind as. This field may take on a null value (a zero length - string) for the purposes of anonymous binds. - - - authentication: information used to authenticate the name, if any, - provided in the Bind Request. The "simple" authentication option - provides minimal authentication facilities, with the contents of - the authentication field consisting only of a cleartext password. - This option should also be used when unauthenticated or anonymous - binds are to be performed, with the field containing a zero length - string in such cases. Kerberos version 4 [7] authentication to the - LDAP server and the DSA is accomplished by using the "krbv42LDAP" - and "krbv42DSA" authentication options, respectively. Note that - though they are referred to as separate entities here, there is no - requirement these two entities be distinct (i.e., a DSA could speak - LDAP directly). Two separate authentication options are provided - to support all implementations. Each octet string should contain - the kerberos ticket (e.g., as returned by krb_mk_req()) for the - appropriate service. The suggested service name for authentication - to the LDAP server is "ldapserver". The suggested service name for - authentication to the DSA is "x500dsa". In both cases, the - suggested instance name for the service is the name of the host on - which the service is running. Of course, the actual service names - and instances will depend on what is entered in the local kerberos - principle database. - - The Bind Operation requires a response, the Bind Response, which is - defined as: - - BindResponse ::= [APPLICATION 1] LDAPResult - - A Bind Response consists simply of an indication from the server of - the status of the client's request for the initiation of a protocol - session. - - Upon receipt of a Bind Request, a protocol server will authenticate - the requesting client if necessary, and attempt to set up a protocol - session with that client. The server will then return a Bind Response - to the client indicating the status of the session setup request. - -4.2. Unbind Operation - - The function of the Unbind Operation is to terminate a protocol - session. The Unbind Operation is defined as follows: - - UnbindRequest ::= [APPLICATION 2] NULL - - - - - -Yeong, Howes & Kille [Page 7] - -RFC 1777 LDAP March 1995 - - - The Unbind Operation has no response defined. Upon transmission of an - UnbindRequest, a protocol client may assume that the protocol session - is terminated. Upon receipt of an UnbindRequest, a protocol server - may assume that the requesting client has terminated the session and - that all outstanding requests may be discarded. - -4.3. Search Operation - - The Search Operation allows a client to request that a search be - performed on its behalf by a server. The Search Request is defined as - follows: - - SearchRequest ::= - [APPLICATION 3] SEQUENCE { - baseObject LDAPDN, - scope ENUMERATED { - baseObject (0), - singleLevel (1), - wholeSubtree (2) - }, - derefAliases ENUMERATED { - neverDerefAliases (0), - derefInSearching (1), - derefFindingBaseObj (2), - derefAlways (3) - }, - sizeLimit INTEGER (0 .. maxInt), - timeLimit INTEGER (0 .. maxInt), - attrsOnly BOOLEAN, - filter Filter, - attributes SEQUENCE OF AttributeType - } - - Filter ::= - CHOICE { - and [0] SET OF Filter, - or [1] SET OF Filter, - not [2] Filter, - equalityMatch [3] AttributeValueAssertion, - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeType, - approxMatch [8] AttributeValueAssertion - } - - SubstringFilter - SEQUENCE { - - - -Yeong, Howes & Kille [Page 8] - -RFC 1777 LDAP March 1995 - - - type AttributeType, - SEQUENCE OF CHOICE { - initial [0] LDAPString, - any [1] LDAPString, - final [2] LDAPString - } - } - - Parameters of the Search Request are: - - - baseObject: An LDAPDN that is the base object entry relative to - which the search is to be performed. - - - scope: An indicator of the scope of the search to be performed. The - semantics of the possible values of this field are identical to the - semantics of the scope field in the Directory Search Operation. - - - derefAliases: An indicator as to how alias objects should be - handled in searching. The semantics of the possible values of - this field are, in order of increasing value: - - neverDerefAliases: do not dereference aliases in searching - or in locating the base object of the search; - - derefInSearching: dereference aliases in subordinates of - the base object in searching, but not in locating the - base object of the search; - - derefFindingBaseObject: dereference aliases in locating - the base object of the search, but not when searching - subordinates of the base object; - - derefAlways: dereference aliases both in searching and in - locating the base object of the search. - - - sizelimit: A sizelimit that restricts the maximum number of entries - to be returned as a result of the search. A value of 0 in this - field indicates that no sizelimit restrictions are in effect for - the search. - - - timelimit: A timelimit that restricts the maximum time (in seconds) - allowed for a search. A value of 0 in this field indicates that no - timelimit restrictions are in effect for the search. - - - attrsOnly: An indicator as to whether search results should contain - both attribute types and values, or just attribute types. Setting - this field to TRUE causes only attribute types (no values) to be - returned. Setting this field to FALSE causes both attribute types - - - -Yeong, Howes & Kille [Page 9] - -RFC 1777 LDAP March 1995 - - - and values to be returned. - - - filter: A filter that defines the conditions that must be fulfilled - in order for the search to match a given entry. - - - attributes: A list of the attributes from each entry found as a - result of the search to be returned. An empty list signifies that - all attributes from each entry found in the search are to be - returned. - - The results of the search attempted by the server upon receipt of a - Search Request are returned in Search Responses, defined as follows: - - Search Response ::= - CHOICE { - entry [APPLICATION 4] SEQUENCE { - objectName LDAPDN, - attributes SEQUENCE OF SEQUENCE { - AttributeType, - SET OF AttributeValue - } - }, - resultCode [APPLICATION 5] LDAPResult - } - - Upon receipt of a Search Request, a server will perform the necessary - search of the DIT. - - The server will return to the client a sequence of responses - comprised of: - - - Zero or more Search Responses each consisting of an entry found - during the search; with the response sequence terminated by - - - A single Search Response containing an indication of success, or - detailing any errors that have occurred. - - Each entry returned will contain all attributes, complete with - associated values if necessary, as specified in the 'attributes' - field of the Search Request. - - Note that an X.500 "list" operation can be emulated by a one-level - LDAP search operation with a filter checking for the existence of the - objectClass attribute, and that an X.500 "read" operation can be - emulated by a base object LDAP search operation with the same filter. - - - - - - -Yeong, Howes & Kille [Page 10] - -RFC 1777 LDAP March 1995 - - -4.4. Modify Operation - - The Modify Operation allows a client to request that a modification - of the DIB be performed on its behalf by a server. The Modify - Request is defined as follows: - -ModifyRequest ::= - [APPLICATION 6] SEQUENCE { - object LDAPDN, - modification SEQUENCE OF SEQUENCE { - operation ENUMERATED { - add (0), - delete (1), - replace (2) - }, - modification SEQUENCE { - type AttributeType, - values SET OF - AttributeValue - } - } - } - - Parameters of the Modify Request are: - - - object: The object to be modified. The value of this field should - name the object to be modified after all aliases have been - dereferenced. The server will not perform any alias dereferencing - in determining the object to be modified. - - - A list of modifications to be performed on the entry to be modified. - The entire list of entry modifications should be performed - in the order they are listed, as a single atomic operation. While - individual modifications may violate the Directory schema, the - resulting entry after the entire list of modifications is performed - must conform to the requirements of the Directory schema. The - values that may be taken on by the 'operation' field in each - modification construct have the following semantics respectively: - - add: add values listed to the given attribute, creating - the attribute if necessary; - - delete: delete values listed from the given attribute, - - removing the entire attribute if no values are listed, or - if all current values of the attribute are listed for - deletion; - - - - -Yeong, Howes & Kille [Page 11] - -RFC 1777 LDAP March 1995 - - - replace: replace existing values of the given attribute - with the new values listed, creating the attribute if - necessary. - - The result of the modify attempted by the server upon receipt of a - Modify Request is returned in a Modify Response, defined as follows: - - ModifyResponse ::= [APPLICATION 7] LDAPResult - - Upon receipt of a Modify Request, a server will perform the necessary - modifications to the DIB. - - The server will return to the client a single Modify Response - indicating either the successful completion of the DIB modification, - or the reason that the modification failed. Note that due to the - requirement for atomicity in applying the list of modifications in - the Modify Request, the client may expect that no modifications of - the DIB have been performed if the Modify Response received indicates - any sort of error, and that all requested modifications have been - performed if the Modify Response indicates successful completion of - the Modify Operation. - -4.5. Add Operation - - The Add Operation allows a client to request the addition of an entry - into the Directory. The Add Request is defined as follows: - - AddRequest ::= - [APPLICATION 8] SEQUENCE { - entry LDAPDN, - attrs SEQUENCE OF SEQUENCE { - type AttributeType, - values SET OF AttributeValue - } - } - - Parameters of the Add Request are: - - - entry: the Distinguished Name of the entry to be added. Note that - all components of the name except for the last RDN component must - exist for the add to succeed. - - - attrs: the list of attributes that make up the content of the entry - being added. - - The result of the add attempted by the server upon receipt of a Add - Request is returned in the Add Response, defined as follows: - - - - -Yeong, Howes & Kille [Page 12] - -RFC 1777 LDAP March 1995 - - - AddResponse ::= [APPLICATION 9] LDAPResult - - Upon receipt of an Add Request, a server will attempt to perform the - add requested. The result of the add attempt will be returned to the - client in the Add Response. - -4.6. Delete Operation - - The Delete Operation allows a client to request the removal of an - entry from the Directory. The Delete Request is defined as follows: - - DelRequest ::= [APPLICATION 10] LDAPDN - - The Delete Request consists only of the Distinguished Name of the - entry to be deleted. The result of the delete attempted by the - server upon receipt of a Delete Request is returned in the Delete - Response, defined as follows: - - DelResponse ::= [APPLICATION 11] LDAPResult - - Upon receipt of a Delete Request, a server will attempt to perform - the entry removal requested. The result of the delete attempt will be - returned to the client in the Delete Response. Note that only leaf - objects may be deleted with this operation. - -4.7. Modify RDN Operation - - The Modify RDN Operation allows a client to change the last component - of the name of an entry in the Directory. The Modify RDN Request is - defined as follows: - - ModifyRDNRequest ::= - [APPLICATION 12] SEQUENCE { - entry LDAPDN, - newrdn RelativeLDAPDN, - deleteoldrdn BOOLEAN - } - - Parameters of the Modify RDN Request are: - - - entry: the name of the entry to be changed. - - - newrdn: the RDN that will form the last component of the new name. - - - deleteoldrdn: a boolean parameter that controls whether the old RDN - attribute values should be retained as attributes of the entry or - deleted from the entry. - - - - -Yeong, Howes & Kille [Page 13] - -RFC 1777 LDAP March 1995 - - - The result of the name change attempted by the server upon receipt of - a Modify RDN Request is returned in the Modify RDN Response, defined - as follows: - - ModifyRDNResponse ::= [APPLICATION 13] LDAPResult - - Upon receipt of a Modify RDN Request, a server will attempt to - perform the name change. The result of the name change attempt will - be returned to the client in the Modify RDN Response. The attributes - that make up the old RDN are deleted from the entry, or kept, - depending on the setting of the deleteoldrdn parameter. - -4.8. Compare Operation - - The Compare Operation allows a client to compare an assertion - provided with an entry in the Directory. The Compare Request is - defined as follows: - - CompareRequest ::= - [APPLICATION 14] SEQUENCE { - entry LDAPDN, - ava AttributeValueAssertion - } - - Parameters of the Compare Request are: - - - entry: the name of the entry to be compared with. - - - ava: the assertion with which the entry is to be compared. - - The result of the compare attempted by the server upon receipt of a - Compare Request is returned in the Compare Response, defined as - follows: - - CompareResponse ::= [APPLICATION 15] LDAPResult - - Upon receipt of a Compare Request, a server will attempt to perform - the requested comparison. The result of the comparison will be - returned to the client in the Compare Response. Note that errors and - the result of comparison are all returned in the same construct. - -6.9. Abandon Operation - - The function of the Abandon Operation is to allow a client to request - that the server abandon an outstanding operation. The Abandon - Request is defined as follows: - - AbandonRequest ::= [APPLICATION 16] MessageID - - - -Yeong, Howes & Kille [Page 14] - -RFC 1777 LDAP March 1995 - - - There is no response defined in the Abandon Operation. Upon - transmission of an Abandon Operation, a client may expect that the - operation identityfied by the Message ID in the Abandon Request has - been abandoned. In the event that a server receives an Abandon - Request on a Search Operation in the midst of transmitting responses - to that search, that server should cease transmitting responses to - the abandoned search immediately. - -5. Protocol Element Encodings - - The protocol elements of LDAP are encoded for exchange using the - Basic Encoding Rules (BER) [12] of ASN.1 [11]. However, due to the - high overhead involved in using certain elements of the BER, the - following additional restrictions are placed on BER-encodings of LDAP - protocol elements: - - (1) Only the definite form of length encoding will be used. - - (2) Bitstrings and octet strings and all character string types - will be encoded in the primitive form only. - -6. Security Considerations - - This version of the protocol provides facilities only for simple - authentication using a cleartext password, and for kerberos version 4 - authentication. Future versions of LDAP will likely include support - for other authentication methods. - -7. Bibliography - - [1] The Directory: Overview of Concepts, Models and Service. CCITT - Recommendation X.500, 1988. - - [2] Information Processing Systems -- Open Systems Interconnection -- - The Directory: Overview of Concepts, Models and Service. ISO/IEC - JTC 1/SC21; International Standard 9594-1, 1988 - - [3] Rose, M., "Directory Assistance Service", RFC 1202, Performance - Systems International, Inc., February 1991. - - [4] Howes, T., Smith, M., and B. Beecher, "DIXIE Protocol - Specification, RFC 1249, University of Michigan, August 1991. - - [5] Kille, S., "A String Representation of Distinguished Names", RFC - 1779, ISODE Consortium, March 1995. - - - - - - -Yeong, Howes & Kille [Page 15] - -RFC 1777 LDAP March 1995 - - - [6] Howes, T., Kille, S., Yeong, W., and C. Robbins, "Lightweight - Directory Access Protocol", RFC 1488, University of Michigan, - ISODE Consortium, Performance Systems International, NeXor Ltd., - July 1993. - - [7] Kerberos Authentication and Authorization System. S.P. Miller, - B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena - Documentation Section E.2.1, December 1987. - - [8] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC - 1/SC21; International Standard 9594-2, 1988. - - [10] The Directory: Abstract Service Definition. CCITT Recommendation - X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988. - - [11] Specification of Abstract Syntax Notation One (ASN.1). CCITT - Recommendation X.208, 1988. - - [12] Specification of Basic Encoding Rules for Abstract Syntax - Notation One (ASN.1). CCITT Recommendation X.209, 1988. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Yeong, Howes & Kille [Page 16] - -RFC 1777 LDAP March 1995 - - -10. Authors' Addresses - - Wengyik Yeong - PSI Inc. - 510 Huntmar Park Drive - Herndon, VA 22070 - USA - - Phone: +1 703-450-8001 - EMail: yeongw@psilink.com - - - Tim Howes - University of Michigan - ITD Research Systems - 535 W William St. - Ann Arbor, MI 48103-4943 - USA - - Phone: +1 313 747-4454 - EMail: tim@umich.edu - - - Steve Kille - ISODE Consortium - PO Box 505 - London - SW11 1DX - UK - - Phone: +44-71-223-4062 - EMail: S.Kille@isode.com - - - - - - - - - - - - - - - - - - - -Yeong, Howes & Kille [Page 17] - -RFC 1777 LDAP March 1995 - - -Appendix A - Complete ASN.1 Definition - -Lightweight-Directory-Access-Protocol DEFINITIONS IMPLICIT TAGS ::= - -BEGIN - -LDAPMessage ::= - SEQUENCE { - messageID MessageID, - -- unique id in request, - -- to be echoed in response(s) - protocolOp CHOICE { - searchRequest SearchRequest, - searchResponse SearchResponse, - modifyRequest ModifyRequest, - modifyResponse ModifyResponse, - addRequest AddRequest, - addResponse AddResponse, - delRequest DelRequest, - delResponse DelResponse, - modifyDNRequest ModifyDNRequest, - modifyDNResponse ModifyDNResponse, - compareDNRequest CompareRequest, - compareDNResponse CompareResponse, - bindRequest BindRequest, - bindResponse BindResponse, - abandonRequest AbandonRequest, - unbindRequest UnbindRequest - } - } - -BindRequest ::= - [APPLICATION 0] SEQUENCE { - version INTEGER (1 .. 127), - -- current version is 2 - name LDAPDN, - -- null name implies an anonymous bind - authentication CHOICE { - simple [0] OCTET STRING, - -- a zero length octet string - -- implies an unauthenticated - -- bind. - krbv42LDAP [1] OCTET STRING, - krbv42DSA [2] OCTET STRING - -- values as returned by - -- krb_mk_req() - -- Other values in later versions - -- of this protocol. - - - -Yeong, Howes & Kille [Page 18] - -RFC 1777 LDAP March 1995 - - - } - } - -BindResponse ::= [APPLICATION 1] LDAPResult - -UnbindRequest ::= [APPLICATION 2] NULL - -SearchRequest ::= - [APPLICATION 3] SEQUENCE { - baseObject LDAPDN, - scope ENUMERATED { - baseObject (0), - singleLevel (1), - wholeSubtree (2) - }, - derefAliases ENUMERATED { - neverDerefAliases (0), - derefInSearching (1), - derefFindingBaseObj (2), - alwaysDerefAliases (3) - }, - sizeLimit INTEGER (0 .. maxInt), - -- value of 0 implies no sizelimit - timeLimit INTEGER (0 .. maxInt), - -- value of 0 implies no timelimit - attrsOnly BOOLEAN, - -- TRUE, if only attributes (without values) - -- to be returned. - filter Filter, - attributes SEQUENCE OF AttributeType - } - -SearchResponse ::= - CHOICE { - entry [APPLICATION 4] SEQUENCE { - objectName LDAPDN, - attributes SEQUENCE OF SEQUENCE { - AttributeType, - SET OF - AttributeValue - } - }, - resultCode [APPLICATION 5] LDAPResult - } - -ModifyRequest ::= - [APPLICATION 6] SEQUENCE { - object LDAPDN, - - - -Yeong, Howes & Kille [Page 19] - -RFC 1777 LDAP March 1995 - - - modifications SEQUENCE OF SEQUENCE { - operation ENUMERATED { - add (0), - delete (1), - replace (2) - }, - modification SEQUENCE { - type AttributeType, - values SET OF - AttributeValue - } - } - } - - -ModifyResponse ::= [APPLICATION 7] LDAPResult - -AddRequest ::= - [APPLICATION 8] SEQUENCE { - entry LDAPDN, - attrs SEQUENCE OF SEQUENCE { - type AttributeType, - values SET OF AttributeValue - } - } - -AddResponse ::= [APPLICATION 9] LDAPResult - -DelRequest ::= [APPLICATION 10] LDAPDN - -DelResponse ::= [APPLICATION 11] LDAPResult - -ModifyRDNRequest ::= - [APPLICATION 12] SEQUENCE { - entry LDAPDN, - newrdn RelativeLDAPDN -- old RDN always deleted - } - -ModifyRDNResponse ::= [APPLICATION 13] LDAPResult - -CompareRequest ::= - [APPLICATION 14] SEQUENCE { - entry LDAPDN, - ava AttributeValueAssertion - } - -CompareResponse ::= [APPLICATION 15] LDAPResult - - - - -Yeong, Howes & Kille [Page 20] - -RFC 1777 LDAP March 1995 - - -AbandonRequest ::= [APPLICATION 16] MessageID - -MessageID ::= INTEGER (0 .. maxInt) - -LDAPDN ::= LDAPString - -RelativeLDAPDN ::= LDAPString - -Filter ::= - CHOICE { - and [0] SET OF Filter, - or [1] SET OF Filter, - not [2] Filter, - equalityMatch [3] AttributeValueAssertion, - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeType, - approxMatch [8] AttributeValueAssertion - } - -LDAPResult ::= - SEQUENCE { - resultCode ENUMERATED { - success (0), - operationsError (1), - protocolError (2), - timeLimitExceeded (3), - sizeLimitExceeded (4), - compareFalse (5), - compareTrue (6), - authMethodNotSupported (7), - strongAuthRequired (8), - noSuchAttribute (16), - undefinedAttributeType (17), - inappropriateMatching (18), - constraintViolation (19), - attributeOrValueExists (20), - invalidAttributeSyntax (21), - noSuchObject (32), - aliasProblem (33), - invalidDNSyntax (34), - isLeaf (35), - aliasDereferencingProblem (36), - inappropriateAuthentication (48), - invalidCredentials (49), - insufficientAccessRights (50), - busy (51), - - - -Yeong, Howes & Kille [Page 21] - -RFC 1777 LDAP March 1995 - - - unavailable (52), - unwillingToPerform (53), - loopDetect (54), - namingViolation (64), - objectClassViolation (65), - notAllowedOnNonLeaf (66), - notAllowedOnRDN (67), - entryAlreadyExists (68), - objectClassModsProhibited (69), - other (80) - }, - matchedDN LDAPDN, - errorMessage LDAPString - } - -AttributeType ::= LDAPString - -- text name of the attribute, or dotted - -- OID representation - -AttributeValue ::= OCTET STRING - -AttributeValueAssertion ::= - SEQUENCE { - attributeType AttributeType, - attributeValue AttributeValue - } - -SubstringFilter ::= - SEQUENCE { - type AttributeType, - SEQUENCE OF CHOICE { - initial [0] LDAPString, - any [1] LDAPString, - final [2] LDAPString - } - } - -LDAPString ::= OCTET STRING - -maxInt INTEGER ::= 65535 -END - - - - - - - - - - -Yeong, Howes & Kille [Page 22] - diff --git a/source4/ldap_server/devdocs/rfc1779.txt b/source4/ldap_server/devdocs/rfc1779.txt deleted file mode 100644 index a487e9e7885..00000000000 --- a/source4/ldap_server/devdocs/rfc1779.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group S. Kille -Request for Comments: 1779 ISODE Consortium -Obsoletes: 1485 March 1995 -Category: Standards Track - - - A String Representation of Distinguished Names - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The OSI Directory uses distinguished names as the primary keys to - entries in the directory. Distinguished Names are encoded in ASN.1. - When a distinguished name is communicated between to users not using - a directory protocol (e.g., in a mail message), there is a need to - have a user-oriented string representation of distinguished name. - This specification defines a string format for representing names, - which is designed to give a clean representation of commonly used - names, whilst being able to represent any distinguished name. - -Table of Contents - - 1. Why a notation is needed ................................... 2 - 2. A notation for Distinguished Name .......................... 2 - 2.1 Goals ................................................ 2 - 2.2 Informal definition .................................. 2 - 2.3 Formal definition .................................... 4 - 3. Examples ................................................... 6 - 4. Acknowledgements ........................................... 7 - 5. References ................................................. 7 - 6. Security Considerations .................................... 8 - 7. Author's Address ........................................... 8 - - - - - - - - - - - - -Kille [Page 1] - -RFC 1779 DN Representation March 1995 - - -1. Why a notation is needed - - Many OSI Applications make use of Distinguished Names (DN) as defined - in the OSI Directory, commonly known as X.500 [1]. This - specification assumes familiarity with X.500, and the concept of - Distinguished Name. It is important to have a common format to be - able to unambiguously represent a distinguished name. This might be - done to represent a directory name on a business card or in an email - message. There is a need for a format to support human to human - communication, which must be string based (not ASN.1) and user - oriented. This notation is targeted towards a general user oriented - system, and in particular to represent the names of humans. Other - syntaxes may be more appropriate for other uses of the directory. - For example, the OSF Syntax may be more appropriate for some system - oriented uses. (The OSF Syntax uses "/" as a separator, and forms - names in a manner intended to resemble UNIX filenames). - -2. A notation for Distinguished Name - -2.1 Goals - - The following goals are laid out: - - o To provide an unambiguous representation of a distinguished name - - o To be an intuitive format for the majority of names - - o To be fully general, and able to represent any distinguished name - - o To be amenable to a number of different layouts to achieve an - attractive representation. - - o To give a clear representation of the contents of the - distinguished name - -2.2 Informal definition - - This notation is designed to be convenient for common forms of name. - Some examples are given. The author's directory distinguished name - would be written: - - CN=Steve Kille, - O=ISODE Consortium, C=GB - - - - - - - - -Kille [Page 2] - -RFC 1779 DN Representation March 1995 - - - This may be folded, perhaps to display in multi-column format. For - example: - - CN=Steve Kille, - O=ISODE Consortium, - C=GB - - Another name might be: - - CN=Christian Huitema, O=INRIA, C=FR - - Semicolon (";") may be used as an alternate separator. The - separators may be mixed, but this usage is discouraged. - - CN=Christian Huitema; O=INRIA; C=FR - - In running text, this would be written as <CN=Christian Huitema; - O=INRIA; C=FR>. Another example, shows how different attribute types - are handled: - - CN=James Hacker, - L=Basingstoke, - O=Widget Inc, - C=GB - - Here is an example of a multi-valued Relative Distinguished Name, - where the namespace is flat within an organisation, and department is - used to disambiguate certain names: - - OU=Sales + CN=J. Smith, O=Widget Inc., C=US - - The final examples show both methods quoting of a comma in an - Organisation name: - - CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB - - CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB - - - - - - - - - - - - - - -Kille [Page 3] - -RFC 1779 DN Representation March 1995 - - -2.3 Formal definition - - A formal definition can now be given. The structure is specified in - a BNF grammar in Figure 1. This BNF uses the grammar defined in RFC - 822, with the terminals enclosed in <> [2]. This definition is in an - abstract character set, and so may be written in any character set - supporting the explicitly defined special characters. The quoting - mechanism is used for the following cases: - - o Strings containing ",", "+", "=" or """ , <CR>, "<", - ">", "#", or ";". - - o Strings with leading or trailing spaces - - o Strings containing consecutive spaces - - There is an escape mechanism from the normal user oriented form, so - that this syntax may be used to print any valid distinguished name. - This is ugly. It is expected to be used only in pathological cases. - There are two parts to this mechanism: - - 1. Attributes types are represented in a (big-endian) dotted - notation. (e.g., OID.2.6.53). - - 2. Attribute values are represented in hexadecimal (e.g. #0A56CF). - Each pair of hex digits defines an octet, which is the ASN.1 Basic - Encoding Rules value of the Attribute Value. - - The keyword specification is optional in the BNF, but mandatory for - this specification. This is so that the same BNF may be used for the - related specification on User Friendly Naming [5]. When this - specification is followed, the attribute type keywords must always be - present. - - A list of valid keywords for well known attribute types used in - naming is given in Table 1. Keywords may contain spaces, but shall - not have leading or trailing spaces. This is a list of keywords - which must be supported. These are chosen because they appear in - common forms of name, and can do so in a place which does not - correspond to the default schema used. A register of valid keywords - is maintained by the IANA. - - - - - - - - - - -Kille [Page 4] - -RFC 1779 DN Representation March 1995 - - - <name> ::= <name-component> ( <spaced-separator> ) - | <name-component> <spaced-separator> <name> - - <spaced-separator> ::= <optional-space> - <separator> - <optional-space> - - <separator> ::= "," | ";" - - <optional-space> ::= ( <CR> ) *( " " ) - - <name-component> ::= <attribute> - | <attribute> <optional-space> "+" - <optional-space> <name-component> - - <attribute> ::= <string> - | <key> <optional-space> "=" <optional-space> <string> - - <key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid> - <keychar> ::= letters, numbers, and space - - <oid> ::= <digitstring> | <digitstring> "." <oid> - <digitstring> ::= 1*<digit> - <digit> ::= digits 0-9 - - <string> ::= *( <stringchar> | <pair> ) - | '"' *( <stringchar> | <special> | <pair> ) '"' - | "#" <hex> - - - <special> ::= "," | "=" | <CR> | "+" | "<" | ">" - | "#" | ";" - - <pair> ::= "\" ( <special> | "\" | '"') - <stringchar> ::= any character except <special> or "\" or '"' - - - <hex> ::= 2*<hexchar> - <hexchar> ::= 0-9, a-f, A-F - - - - Figure 1: BNF Grammar for Distinguished Name - - - - - - - - -Kille [Page 5] - -RFC 1779 DN Representation March 1995 - - - Key Attribute (X.520 keys) - ------------------------------ - CN CommonName - L LocalityName - ST StateOrProvinceName - O OrganizationName - OU OrganizationalUnitName - C CountryName - STREET StreetAddress - - - Table 1: Standardised Keywords - - - Only string type attributes are considered, but other attribute - syntaxes could be supported locally (e.g., by use of the syntexes - defined in [3].) It is assumed that the interface will translate - from the supplied string into an appropriate Directory String - encoding. The "+" notation is used to specify multi-component RDNs. - In this case, the types for attributes in the RDN must be explicit. - - The name is presented/input in a little-endian order (most - significant component last). When an address is written in a context - where there is a need to delimit the entire address (e.g., in free - text), it is recommended that the delimiters <> are used. The - terminator > is a special in the notation to facilitate this - delimitation. - -3. Examples - - This section gives a few examples of distinguished names written - using this notation: - - CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara, - ST=California, C=US - - CN=FTAM Service, CN=Bells, OU=Computer Science, - O=University College London, C=GB - - CN=Markus Kuhn, O=University of Erlangen, C=DE - - CN=Steve Kille, - O=ISODE Consortium, - C=GB - - - - - - - -Kille [Page 6] - -RFC 1779 DN Representation March 1995 - - - CN=Steve Kille , - - O = ISODE Consortium, - C=GB - - CN=Steve Kille, O=ISODE Consortium, C=GB - -4. Acknowledgements - - This work was based on research work done at University College - London [4], and evolved by the IETF OSI-DS WG. - - Input for this version of the document was received from: Allan - Cargille (University of Wisconsin); John Dale (COS); Philip Gladstone - (Onsett); John Hawthorne (US Air Force); Roland Hedberg (University - of Umea); Kipp Hickman (Mosaic Communications Corp.) Markus Kuhn - (University of Erlangen); Elisabeth Roudier (E3X); Mark Wahl (ISODE - Consortium). - -5. References - - [1] The Directory --- overview of concepts, models and services, - 1993. CCITT X.500 Series Recommendations. - - [2] Crocker, D., "Standard of the Format of ARPA-Internet Text - Messages", STD 11, RFC 822, University of Delaware, August 1982. - - [3] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access - Protocol", RFC 1777, Performance Systems International, - University of Michigan, ISODE Consortium, March 1995. - - [4] S.E. Kille. Using the OSI directory to achieve user friendly - naming. Research Note RN/20/29, Department of Computer Science, - University College London, February 1990. - - [5] Kille, S., "Using the OSI Directory to Achieve User Friendly - Naming", RFC 1781, ISODE Consortium, March 1995. - - - - - - - - - - - - - - -Kille [Page 7] - -RFC 1779 DN Representation March 1995 - - -6. Security Considerations - - Security issues are not discussed in this memo. - -7. Author's Address - - Steve Kille - ISODE Consortium - The Dome - The Square - Richmond, Surrey - TW9 1DT - England - - Phone: +44-181-332-9091 - EMail: S.Kille@ISODE.COM - - DN: CN=Steve Kille, - O=ISODE Consortium, C=GB - - UFN: S. Kille, - ISODE Consortium, GB - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kille [Page 8] - diff --git a/source4/ldap_server/devdocs/rfc2251.txt b/source4/ldap_server/devdocs/rfc2251.txt deleted file mode 100644 index 88844cbf38b..00000000000 --- a/source4/ldap_server/devdocs/rfc2251.txt +++ /dev/null @@ -1,2803 +0,0 @@ - - - - - - -Network Working Group M. Wahl -Request for Comments: 2251 Critical Angle Inc. -Category: Standards Track T. Howes - Netscape Communications Corp. - S. Kille - Isode Limited - December 1997 - - - Lightweight Directory Access Protocol (v3) - -1. Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -IESG Note - - This document describes a directory access protocol that provides - both read and update access. Update access requires secure - authentication, but this document does not mandate implementation of - any satisfactory authentication mechanisms. - - In accordance with RFC 2026, section 4.4.1, this specification is - being approved by IESG as a Proposed Standard despite this - limitation, for the following reasons: - - a. to encourage implementation and interoperability testing of - these protocols (with or without update access) before they - are deployed, and - - b. to encourage deployment and use of these protocols in read-only - applications. (e.g. applications where LDAPv3 is used as - a query language for directories which are updated by some - secure mechanism other than LDAP), and - - c. to avoid delaying the advancement and deployment of other Internet - standards-track protocols which require the ability to query, but - not update, LDAPv3 directory servers. - - - - - -Wahl, et. al. Standards Track [Page 1] - -RFC 2251 LDAPv3 December 1997 - - - Readers are hereby warned that until mandatory authentication - mechanisms are standardized, clients and servers written according to - this specification which make use of update functionality are - UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION - IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. - - Implementors are hereby discouraged from deploying LDAPv3 clients or - servers which implement the update functionality, until a Proposed - Standard for mandatory authentication in LDAPv3 has been approved and - published as an RFC. - -Table of Contents - - 1. Status of this Memo .................................... 1 - Copyright Notice ....................................... 1 - IESG Note .............................................. 1 - 2. Abstract ............................................... 3 - 3. Models ................................................. 4 - 3.1. Protocol Model ........................................ 4 - 3.2. Data Model ............................................ 5 - 3.2.1. Attributes of Entries ............................... 5 - 3.2.2. Subschema Entries and Subentries .................... 7 - 3.3. Relationship to X.500 ................................. 8 - 3.4. Server-specific Data Requirements ..................... 8 - 4. Elements of Protocol ................................... 9 - 4.1. Common Elements ....................................... 9 - 4.1.1. Message Envelope .................................... 9 - 4.1.1.1. Message ID ........................................ 11 - 4.1.2. String Types ........................................ 11 - 4.1.3. Distinguished Name and Relative Distinguished Name .. 11 - 4.1.4. Attribute Type ...................................... 12 - 4.1.5. Attribute Description ............................... 13 - 4.1.5.1. Binary Option ..................................... 14 - 4.1.6. Attribute Value ..................................... 14 - 4.1.7. Attribute Value Assertion ........................... 15 - 4.1.8. Attribute ........................................... 15 - 4.1.9. Matching Rule Identifier ............................ 15 - 4.1.10. Result Message ..................................... 16 - 4.1.11. Referral ........................................... 18 - 4.1.12. Controls ........................................... 19 - 4.2. Bind Operation ........................................ 20 - 4.2.1. Sequencing of the Bind Request ...................... 21 - 4.2.2. Authentication and Other Security Services .......... 22 - 4.2.3. Bind Response ....................................... 23 - 4.3. Unbind Operation ...................................... 24 - 4.4. Unsolicited Notification .............................. 24 - 4.4.1. Notice of Disconnection ............................. 24 - 4.5. Search Operation ...................................... 25 - - - -Wahl, et. al. Standards Track [Page 2] - -RFC 2251 LDAPv3 December 1997 - - - 4.5.1. Search Request ...................................... 25 - 4.5.2. Search Result ....................................... 29 - 4.5.3. Continuation References in the Search Result ........ 31 - 4.5.3.1. Example ........................................... 31 - 4.6. Modify Operation ...................................... 32 - 4.7. Add Operation ......................................... 34 - 4.8. Delete Operation ...................................... 35 - 4.9. Modify DN Operation ................................... 36 - 4.10. Compare Operation .................................... 37 - 4.11. Abandon Operation .................................... 38 - 4.12. Extended Operation ................................... 38 - 5. Protocol Element Encodings and Transfer ................ 39 - 5.1. Mapping Onto BER-based Transport Services ............. 39 - 5.2. Transfer Protocols .................................... 40 - 5.2.1. Transmission Control Protocol (TCP) ................. 40 - 6. Implementation Guidelines .............................. 40 - 6.1. Server Implementations ................................ 40 - 6.2. Client Implementations ................................ 40 - 7. Security Considerations ................................ 41 - 8. Acknowledgements ....................................... 41 - 9. Bibliography ........................................... 41 - 10. Authors' Addresses ..................................... 42 - Appendix A - Complete ASN.1 Definition ..................... 44 - Full Copyright Statement ................................... 50 - -2. Abstract - - The protocol described in this document is designed to provide access - to directories supporting the X.500 models, while not incurring the - resource requirements of the X.500 Directory Access Protocol (DAP). - This protocol is specifically targeted at management applications and - browser applications that provide read/write interactive access to - directories. When used with a directory supporting the X.500 - protocols, it is intended to be a complement to the X.500 DAP. - - 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 [10]. - - Key aspects of this version of LDAP are: - - - All protocol elements of LDAPv2 (RFC 1777) are supported. The - protocol is carried directly over TCP or other transport, bypassing - much of the session/presentation overhead of X.500 DAP. - - - Most protocol data elements can be encoded as ordinary strings - (e.g., Distinguished Names). - - - - -Wahl, et. al. Standards Track [Page 3] - -RFC 2251 LDAPv3 December 1997 - - - - Referrals to other servers may be returned. - - - SASL mechanisms may be used with LDAP to provide association - security services. - - - Attribute values and Distinguished Names have been - internationalized through the use of the ISO 10646 character set. - - - The protocol can be extended to support new operations, and - controls may be used to extend existing operations. - - - Schema is published in the directory for use by clients. - -3. Models - - Interest in X.500 [1] directory technologies in the Internet has led - to efforts to reduce the high cost of entry associated with use of - these technologies. This document continues the efforts to define - directory protocol alternatives, updating the LDAP [2] protocol - specification. - -3.1. Protocol Model - - The general model adopted by this protocol is one of clients - performing protocol operations against servers. In this model, a - client transmits a protocol request describing the operation to be - performed to a server. The server is then responsible for performing - the necessary operation(s) in the directory. Upon completion of the - operation(s), the server returns a response containing any results or - errors to the requesting client. - - In keeping with the goal of easing the costs associated with use of - the directory, it is an objective of this protocol to minimize the - complexity of clients so as to facilitate widespread deployment of - applications capable of using the directory. - - Note that although servers are required to return responses whenever - such responses are defined in the protocol, there is no requirement - for synchronous behavior on the part of either clients or servers. - Requests and responses for multiple operations may be exchanged - between a client and server in any order, provided the client - eventually receives a response for every request that requires one. - - In LDAP versions 1 and 2, no provision was made for protocol servers - returning referrals to clients. However, for improved performance - and distribution this version of the protocol permits servers to - return to clients referrals to other servers. This allows servers to - offload the work of contacting other servers to progress operations. - - - -Wahl, et. al. Standards Track [Page 4] - -RFC 2251 LDAPv3 December 1997 - - - Note that the core protocol operations defined in this document can - be mapped to a strict subset of the X.500(1997) directory abstract - service, so it can be cleanly provided by the DAP. However there is - not a one-to-one mapping between LDAP protocol operations and DAP - operations: server implementations acting as a gateway to X.500 - directories may need to make multiple DAP requests. - -3.2. Data Model - - This section provides a brief introduction to the X.500 data model, - as used by LDAP. - - The LDAP protocol assumes there are one or more servers which jointly - provide access to a Directory Information Tree (DIT). The tree is - made up of entries. Entries have names: one or more attribute values - from the entry form its relative distinguished name (RDN), which MUST - be unique among all its siblings. The concatenation of the relative - distinguished names of the sequence of entries from a particular - entry to an immediate subordinate of the root of the tree forms that - entry's Distinguished Name (DN), which is unique in the tree. An - example of a Distinguished Name is - - CN=Steve Kille, O=Isode Limited, C=GB - - Some servers may hold cache or shadow copies of entries, which can be - used to answer search and comparison queries, but will return - referrals or contact other servers if modification operations are - requested. - - Servers which perform caching or shadowing MUST ensure that they do - not violate any access control constraints placed on the data by the - originating server. - - The largest collection of entries, starting at an entry that is - mastered by a particular server, and including all its subordinates - and their subordinates, down to the entries which are mastered by - different servers, is termed a naming context. The root of the DIT - is a DSA-specific Entry (DSE) and not part of any naming context: - each server has different attribute values in the root DSE. (DSA is - an X.500 term for the directory server). - -3.2.1. Attributes of Entries - - Entries consist of a set of attributes. An attribute is a type with - one or more associated values. The attribute type is identified by a - short descriptive name and an OID (object identifier). The attribute - - - - - -Wahl, et. al. Standards Track [Page 5] - -RFC 2251 LDAPv3 December 1997 - - - type governs whether there can be more than one value of an attribute - of that type in an entry, the syntax to which the values must - conform, the kinds of matching which can be performed on values of - that attribute, and other functions. - - An example of an attribute is "mail". There may be one or more values - of this attribute, they must be IA5 (ASCII) strings, and they are - case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). - - Schema is the collection of attribute type definitions, object class - definitions and other information which a server uses to determine - how to match a filter or attribute value assertion (in a compare - operation) against the attributes of an entry, and whether to permit - add and modify operations. The definition of schema for use with - LDAP is given in [5] and [6]. Additional schema elements may be - defined in other documents. - - Each entry MUST have an objectClass attribute. The objectClass - attribute specifies the object classes of an entry, which along with - the system and user schema determine the permitted attributes of an - entry. Values of this attribute may be modified by clients, but the - objectClass attribute cannot be removed. Servers may restrict the - modifications of this attribute to prevent the basic structural class - of the entry from being changed (e.g. one cannot change a person into - a country). When creating an entry or adding an objectClass value to - an entry, all superclasses of the named classes are implicitly added - as well if not already present, and the client must supply values for - any mandatory attributes of new superclasses. - - Some attributes, termed operational attributes, are used by servers - for administering the directory system itself. They are not returned - in search results unless explicitly requested by name. Attributes - which are not operational, such as "mail", will have their schema and - syntax constraints enforced by servers, but servers will generally - not make use of their values. - - Servers MUST NOT permit clients to add attributes to an entry unless - those attributes are permitted by the object class definitions, the - schema controlling that entry (specified in the subschema - see - below), or are operational attributes known to that server and used - for administrative purposes. Note that there is a particular - objectClass 'extensibleObject' defined in [5] which permits all user - attributes to be present in an entry. - - Entries MAY contain, among others, the following operational - attributes, defined in [5]. These attributes are maintained - automatically by the server and are not modifiable by clients: - - - - -Wahl, et. al. Standards Track [Page 6] - -RFC 2251 LDAPv3 December 1997 - - - - creatorsName: the Distinguished Name of the user who added this - entry to the directory. - - - createTimestamp: the time this entry was added to the directory. - - - modifiersName: the Distinguished Name of the user who last modified - this entry. - - - modifyTimestamp: the time this entry was last modified. - - - subschemaSubentry: the Distinguished Name of the subschema entry - (or subentry) which controls the schema for this entry. - -3.2.2. Subschema Entries and Subentries - - Subschema entries are used for administering information about the - directory schema, in particular the object classes and attribute - types supported by directory servers. A single subschema entry - contains all schema definitions used by entries in a particular part - of the directory tree. - - Servers which follow X.500(93) models SHOULD implement subschema - using the X.500 subschema mechanisms, and so these subschemas are not - ordinary entries. LDAP clients SHOULD NOT assume that servers - implement any of the other aspects of X.500 subschema. A server - which masters entries and permits clients to modify these entries - MUST implement and provide access to these subschema entries, so that - its clients may discover the attributes and object classes which are - permitted to be present. It is strongly recommended that all other - servers implement this as well. - - The following four attributes MUST be present in all subschema - entries: - - - cn: this attribute MUST be used to form the RDN of the subschema - entry. - - - objectClass: the attribute MUST have at least the values "top" and - "subschema". - - - objectClasses: each value of this attribute specifies an object - class known to the server. - - - attributeTypes: each value of this attribute specifies an attribute - type known to the server. - - These are defined in [5]. Other attributes MAY be present in - subschema entries, to reflect additional supported capabilities. - - - -Wahl, et. al. Standards Track [Page 7] - -RFC 2251 LDAPv3 December 1997 - - - These include matchingRules, matchingRuleUse, dITStructureRules, - dITContentRules, nameForms and ldapSyntaxes. - - Servers SHOULD provide the attributes createTimestamp and - modifyTimestamp in subschema entries, in order to allow clients to - maintain their caches of schema information. - - Clients MUST only retrieve attributes from a subschema entry by - requesting a base object search of the entry, where the search filter - is "(objectClass=subschema)". (This will allow LDAPv3 servers which - gateway to X.500(93) to detect that subentry information is being - requested.) - -3.3. Relationship to X.500 - - This document defines LDAP in terms of X.500 as an X.500 access - mechanism. 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. - -3.4. Server-specific Data Requirements - - An LDAP server MUST provide information about itself and other - information that is specific to each server. This is represented as - a group of attributes located in the root DSE (DSA-Specific Entry), - which is named with the zero-length LDAPDN. These attributes are - retrievable if a client performs a base object search of the root - with filter "(objectClass=*)", however they are subject to access - control restrictions. The root DSE MUST NOT be included if the - client performs a subtree search starting from the root. - - Servers may allow clients to modify these attributes. - - The following attributes of the root DSE are defined in section 5 of - [5]. Additional attributes may be defined in other documents. - - - namingContexts: naming contexts held in the server. Naming contexts - are defined in section 17 of X.501 [6]. - - - subschemaSubentry: subschema entries (or subentries) known by this - server. - - - altServer: alternative servers in case this one is later - unavailable. - - - - -Wahl, et. al. Standards Track [Page 8] - -RFC 2251 LDAPv3 December 1997 - - - - supportedExtension: list of supported extended operations. - - - supportedControl: list of supported controls. - - - supportedSASLMechanisms: list of supported SASL security features. - - - supportedLDAPVersion: LDAP versions implemented by the server. - - If the server does not master entries and does not know the locations - of schema information, the subschemaSubentry attribute is not present - in the root DSE. If the server masters directory entries under one - or more schema rules, there may be any number of values of the - subschemaSubentry attribute in the root DSE. - -4. Elements of Protocol - - The LDAP protocol is described using Abstract Syntax Notation 1 - (ASN.1) [3], and is typically transferred using a subset of ASN.1 - Basic Encoding Rules [11]. In order to support future extensions to - this protocol, clients and servers MUST ignore elements of SEQUENCE - encodings whose tags they do not recognize. - - Note that unlike X.500, each change to the LDAP protocol other than - through the extension mechanisms will have a different version - number. A client will indicate the version it supports as part of - the bind request, described in section 4.2. If a client has not sent - a bind, the server MUST assume that version 3 is supported in the - client (since version 2 required that the client bind first). - - Clients may determine the protocol version a server supports by - reading the supportedLDAPVersion attribute from the root DSE. Servers - which implement version 3 or later versions MUST provide this - attribute. Servers which only implement version 2 may not provide - this attribute. - -4.1. Common Elements - - This section describes the LDAPMessage envelope PDU (Protocol Data - Unit) format, as well as data type definitions which are used in the - protocol operations. - -4.1.1. Message Envelope - - For the purposes of protocol exchanges, all protocol operations are - encapsulated in a common envelope, the LDAPMessage, which is defined - as follows: - - LDAPMessage ::= SEQUENCE { - - - -Wahl, et. al. Standards Track [Page 9] - -RFC 2251 LDAPv3 December 1997 - - - 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 } - - MessageID ::= INTEGER (0 .. maxInt) - - maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- - - The function of the LDAPMessage is to provide an envelope containing - common fields required in all protocol exchanges. At this time the - only common fields are the message ID and the controls. - - If the server receives a PDU from the client in which the LDAPMessage - SEQUENCE tag cannot be recognized, the messageID cannot be parsed, - the tag of the protocolOp is not recognized as a request, or the - encoding structures or lengths of data fields are found to be - incorrect, then the server MUST return the notice of disconnection - described in section 4.4.1, with resultCode protocolError, and - immediately close the connection. In other cases that the server - cannot parse the request received by the client, the server MUST - return an appropriate response to the request, with the resultCode - set to protocolError. - - If the client receives a PDU from the server which cannot be parsed, - the client may discard the PDU, or may abruptly close the connection. - - The ASN.1 type Controls is defined in section 4.1.12. - - - - -Wahl, et. al. Standards Track [Page 10] - -RFC 2251 LDAPv3 December 1997 - - -4.1.1.1. Message ID - - All LDAPMessage envelopes encapsulating responses contain the - messageID value of the corresponding request LDAPMessage. - - The message ID of a request MUST have a value different from the - values of any other requests outstanding in the LDAP session of which - this message is a part. - - A client MUST NOT send a second request with the same message ID as - an earlier request on the same connection if the client has not - received the final response from the earlier request. Otherwise the - behavior is undefined. Typical clients increment a counter for each - request. - - A client MUST NOT reuse the message id of an abandonRequest or of the - abandoned operation until it has received a response from the server - for another request invoked subsequent to the abandonRequest, as the - abandonRequest itself does not have a response. - -4.1.2. String Types - - The LDAPString is a notational convenience to indicate that, although - strings of LDAPString type encode as OCTET STRING types, the ISO - 10646 [13] character set (a superset of Unicode) is used, encoded - following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm - characters which are the same as ASCII (0x0000 through 0x007F) are - represented as that same ASCII character in a single byte. The other - byte values are used to form a variable-length encoding of an - arbitrary character. - - LDAPString ::= OCTET STRING - - The LDAPOID is a notational convenience to indicate that the - permitted value of this string is a (UTF-8 encoded) dotted-decimal - representation of an OBJECT IDENTIFIER. - - LDAPOID ::= OCTET STRING - - For example, - - 1.3.6.1.4.1.1466.1.2.3 - -4.1.3. Distinguished Name and Relative Distinguished Name - - An LDAPDN and a RelativeLDAPDN are respectively defined to be the - representation of a Distinguished Name and a Relative Distinguished - Name after encoding according to the specification in [4], such that - - - -Wahl, et. al. Standards Track [Page 11] - -RFC 2251 LDAPv3 December 1997 - - - <distinguished-name> ::= <name> - - <relative-distinguished-name> ::= <name-component> - - where <name> and <name-component> are as defined in [4]. - - LDAPDN ::= LDAPString - - RelativeLDAPDN ::= LDAPString - - Only Attribute Types can be present in a relative distinguished name - component; the options of Attribute Descriptions (next section) MUST - NOT be used in specifying distinguished names. - -4.1.4. Attribute Type - - An AttributeType takes on as its value the textual string associated - with that AttributeType in its specification. - - AttributeType ::= LDAPString - - Each attribute type has a unique OBJECT IDENTIFIER which has been - assigned to it. This identifier may be written as decimal digits - with components separated by periods, e.g. "2.5.4.10". - - A specification may also assign one or more textual names for an - attribute type. These names MUST begin with a letter, and only - contain ASCII letters, digit characters and hyphens. They are case - insensitive. (These ASCII characters are identical to ISO 10646 - characters whose UTF-8 encoding is a single byte between 0x00 and - 0x7F.) - - If the server has a textual name for an attribute type, it MUST use a - textual name for attributes returned in search results. The dotted- - decimal OBJECT IDENTIFIER is only used if there is no textual name - for an attribute type. - - Attribute type textual names are non-unique, as two different - specifications (neither in standards track RFCs) may choose the same - name. - - A server which masters or shadows entries SHOULD list all the - attribute types it supports in the subschema entries, using the - attributeTypes attribute. Servers which support an open-ended set of - attributes SHOULD include at least the attributeTypes value for the - 'objectClass' attribute. Clients MAY retrieve the attributeTypes - value from subschema entries in order to obtain the OBJECT IDENTIFIER - and other information associated with attribute types. - - - -Wahl, et. al. Standards Track [Page 12] - -RFC 2251 LDAPv3 December 1997 - - - Some attribute type names which are used in this version of LDAP are - described in [5]. Servers may implement additional attribute types. - -4.1.5. Attribute Description - - An AttributeDescription is a superset of the definition of the - AttributeType. It has the same ASN.1 definition, but allows - additional options to be specified. They are also case insensitive. - - AttributeDescription ::= LDAPString - - A value of AttributeDescription is based on the following BNF: - - <AttributeDescription> ::= <AttributeType> [ ";" <options> ] - - <options> ::= <option> | <option> ";" <options> - - <option> ::= <opt-char> <opt-char>* - - <opt-char> ::= ASCII-equivalent letters, numbers and hyphen - - Examples of valid AttributeDescription: - - cn - userCertificate;binary - - One option, "binary", is defined in this document. Additional - options may be defined in IETF standards-track and experimental RFCs. - Options beginning with "x-" are reserved for private experiments. - Any option could be associated with any AttributeType, although not - all combinations may be supported by a server. - - An AttributeDescription with one or more options is treated as a - subtype of the attribute type without any options. Options present - in an AttributeDescription are never mutually exclusive. - Implementations MUST generate the <options> list sorted in ascending - order, and servers MUST treat any two AttributeDescription with the - same AttributeType and options as equivalent. A server will treat an - AttributeDescription with any options it does not implement as an - unrecognized attribute type. - - The data type "AttributeDescriptionList" describes a list of 0 or - more attribute types. (A list of zero elements has special - significance in the Search request.) - - AttributeDescriptionList ::= SEQUENCE OF - AttributeDescription - - - - -Wahl, et. al. Standards Track [Page 13] - -RFC 2251 LDAPv3 December 1997 - - -4.1.5.1. Binary Option - - If the "binary" option is present in an AttributeDescription, it - overrides any string-based encoding representation defined for that - attribute in [5]. Instead the attribute is to be transferred as a - binary value encoded using the Basic Encoding Rules [11]. The syntax - of the binary value is an ASN.1 data type definition which is - referenced by the "SYNTAX" part of the attribute type definition. - - The presence or absence of the "binary" option only affects the - transfer of attribute values in protocol; servers store any - particular attribute in a single format. If a client requests that a - server return an attribute in the binary format, but the server - cannot generate that format, the server MUST treat this attribute - type as an unrecognized attribute type. Similarly, clients MUST NOT - expect servers to return an attribute in binary format if the client - requested that attribute by name without the binary option. - - This option is intended to be used with attributes whose syntax is a - complex ASN.1 data type, and the structure of values of that type is - needed by clients. Examples of this kind of syntax are "Certificate" - and "CertificateList". - -4.1.6. Attribute Value - - A field of type AttributeValue takes on as its value either a string - encoding of a AttributeValue data type, or an OCTET STRING containing - an encoded binary value, depending on whether the "binary" option is - present in the companion AttributeDescription to this AttributeValue. - - The definition of string encodings for different syntaxes and types - may be found in other documents, and in particular [5]. - - AttributeValue ::= OCTET STRING - - Note that there is no defined limit on the size of this encoding; - thus protocol values may include multi-megabyte attributes (e.g. - photographs). - - Attributes may be defined which have arbitrary and non-printable - syntax. Implementations MUST NEITHER simply display nor attempt to - decode as ASN.1 a value if its syntax is not known. The - implementation may attempt to discover the subschema of the source - entry, and retrieve the values of attributeTypes from it. - - Clients MUST NOT send attribute values in a request which are not - valid according to the syntax defined for the attributes. - - - - -Wahl, et. al. Standards Track [Page 14] - -RFC 2251 LDAPv3 December 1997 - - -4.1.7. Attribute Value Assertion - - The AttributeValueAssertion type definition is similar to the one in - the X.500 directory standards. It contains an attribute description - and a matching rule assertion value suitable for that type. - - AttributeValueAssertion ::= SEQUENCE { - attributeDesc AttributeDescription, - assertionValue AssertionValue } - - AssertionValue ::= OCTET STRING - - If the "binary" option is present in attributeDesc, this signals to - the server that the assertionValue is a binary encoding of the - assertion value. - - For all the string-valued user attributes described in [5], the - assertion value syntax is the same as the value syntax. Clients may - use attribute values as assertion values in compare requests and - search filters. - - Note however that the assertion syntax may be different from the - value syntax for other attributes or for non-equality matching rules. - These may have an assertion syntax which contains only part of the - value. See section 20.2.1.8 of X.501 [6] for examples. - -4.1.8. Attribute - - An attribute consists of a type and one or more values of that type. - (Though attributes MUST have at least one value when stored, due to - access control restrictions the set may be empty when transferred in - protocol. This is described in section 4.5.2, concerning the - PartialAttributeList type.) - - Attribute ::= SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - - Each attribute value is distinct in the set (no duplicates). The - order of attribute values within the vals set is undefined and - implementation-dependent, and MUST NOT be relied upon. - -4.1.9. Matching Rule Identifier - - A matching rule is a means of expressing how a server should compare - an AssertionValue received in a search filter with an abstract data - value. The matching rule defines the syntax of the assertion value - and the process to be performed in the server. - - - -Wahl, et. al. Standards Track [Page 15] - -RFC 2251 LDAPv3 December 1997 - - - An X.501(1993) Matching Rule is identified in the LDAP protocol by - the printable representation of its OBJECT IDENTIFIER, either as one - of the strings given in [5], or as decimal digits with components - separated by periods, e.g. "caseIgnoreIA5Match" or - "1.3.6.1.4.1.453.33.33". - - MatchingRuleId ::= LDAPString - - Servers which support matching rules for use in the extensibleMatch - search filter MUST list the matching rules they implement in - subschema entries, using the matchingRules attributes. The server - SHOULD also list there, using the matchingRuleUse attribute, the - attribute types with which each matching rule can be used. More - information is given in section 4.4 of [5]. - -4.1.10. Result Message - - The LDAPResult is the construct used in this protocol to return - success or failure indications from servers to clients. In response - to various requests servers will return responses containing fields - of type LDAPResult to indicate the final status of a protocol - operation request. - - 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 -- - - - -Wahl, et. al. Standards Track [Page 16] - -RFC 2251 LDAPv3 December 1997 - - - 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), - 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 } - - All the result codes with the exception of success, compareFalse and - compareTrue are to be treated as meaning the operation could not be - completed in its entirety. - - Most of the result codes are based on problem indications from X.511 - error data types. Result codes from 16 to 21 indicate an - AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem, - codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54 - indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an - UpdateProblem. - - If a client receives a result code which is not listed above, it is - to be treated as an unknown error condition. - - The errorMessage field of this construct may, at the server's option, - be used to return a string containing a textual, human-readable - (terminal control and page formatting characters should be avoided) - error diagnostic. As this error diagnostic is not standardized, - - - - -Wahl, et. al. Standards Track [Page 17] - -RFC 2251 LDAPv3 December 1997 - - - 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. - - For result codes of noSuchObject, aliasProblem, invalidDNSyntax and - aliasDereferencingProblem, 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 [8]. The matchedDN field is to be set to a zero length - string with all other result codes. - -4.1.11. Referral - - The referral error indicates that the contacted server does not hold - the target entry of the request. The referral field is present in an - LDAPResult if the LDAPResult.resultCode field value is referral, and - absent with all other result codes. It contains a reference to - another server (or set of servers) which may be accessed via LDAP or - other protocols. Referrals can be returned in response to any - operation request (except unbind and abandon which do not have - responses). At least one URL MUST be present in the Referral. - - The referral is not returned for a singleLevel or wholeSubtree search - in which the search scope spans multiple naming contexts, and several - different servers would need to be contacted to complete the - operation. Instead, continuation references, described in section - 4.5.3, are returned. - - Referral ::= SEQUENCE OF LDAPURL -- one or more - - LDAPURL ::= LDAPString -- limited to characters permitted in URLs - - If the client wishes to progress the operation, it MUST follow the - referral by contacting any one of servers. All the URLs MUST be - equally capable of being used to progress the operation. (The - mechanisms for how this is achieved by multiple servers are outside - the scope of this document.) - - URLs for servers implementing the LDAP protocol are written according - to [9]. If an alias was dereferenced, the <dn> part of the URL MUST - be present, with the new target object name. If the <dn> part is - present, the client MUST use this name in its next request to - progress the operation, and if it is not present the client will use - the same name as in the original request. Some servers (e.g. - participating in distributed indexing) may provide a different filter - in a referral for a search operation. If the filter part of the URL - - - -Wahl, et. al. Standards Track [Page 18] - -RFC 2251 LDAPv3 December 1997 - - - is present in an LDAPURL, the client MUST use this filter in its next - request to progress this search, and if it is not present the client - MUST use the same filter as it used for that search. Other aspects - of the new request may be the same or different as the request which - generated the referral. - - Note that UTF-8 characters appearing in a DN or search filter may not - be legal for URLs (e.g. spaces) and MUST be escaped using the % - method in RFC 1738 [7]. - - Other kinds of URLs may be returned, so long as the operation could - be performed using that protocol. - -4.1.12. Controls - - A control is a way to specify extension information. Controls which - are sent as part of a request apply only to that request and are not - saved. - - Controls ::= SEQUENCE OF Control - - Control ::= SEQUENCE { - controlType LDAPOID, - criticality BOOLEAN DEFAULT FALSE, - controlValue OCTET STRING OPTIONAL } - - The controlType field MUST be a UTF-8 encoded dotted-decimal - representation of an OBJECT IDENTIFIER which uniquely identifies the - control. This prevents conflicts between control names. - - The criticality field is either TRUE or FALSE. - - If the server recognizes the control type and it is appropriate for - the operation, the server will make use of the control when - performing the operation. - - If the server does not recognize the control type and the criticality - field is TRUE, the server MUST NOT perform the operation, and MUST - instead return the resultCode unsupportedCriticalExtension. - - If the control is not appropriate for the operation and criticality - field is TRUE, the server MUST NOT perform the operation, and MUST - instead return the resultCode unsupportedCriticalExtension. - - If the control is unrecognized or inappropriate but the criticality - field is FALSE, the server MUST ignore the control. - - - - - -Wahl, et. al. Standards Track [Page 19] - -RFC 2251 LDAPv3 December 1997 - - - The controlValue contains any information associated with the - control, and its format is defined for the control. The server MUST - be prepared to handle arbitrary contents of the controlValue octet - string, including zero bytes. It is absent only if there is no value - information which is associated with a control of its type. - - This document does not define any controls. Controls may be defined - in other documents. The definition of a control consists of: - - - the OBJECT IDENTIFIER assigned to the control, - - - whether the control is always noncritical, always critical, or - critical at the client's option, - - - the format of the controlValue contents of the control. - - Servers list the controls which they recognize in the - supportedControl attribute in the root DSE. - -4.2. Bind Operation - - The function of the Bind Operation is to allow authentication - information to be exchanged between the client and server. - - The Bind Request is defined as follows: - - BindRequest ::= [APPLICATION 0] SEQUENCE { - version INTEGER (1 .. 127), - name LDAPDN, - authentication AuthenticationChoice } - - AuthenticationChoice ::= CHOICE { - simple [0] OCTET STRING, - -- 1 and 2 reserved - sasl [3] SaslCredentials } - - SaslCredentials ::= SEQUENCE { - mechanism LDAPString, - credentials OCTET STRING OPTIONAL } - - Parameters of the Bind Request are: - - - version: A version number indicating the version of the protocol to - be used in this protocol session. This document describes version - 3 of the LDAP protocol. Note that there is no version negotiation, - and the client just sets this parameter to the version it desires. - If the client requests protocol version 2, a server that supports - the version 2 protocol as described in [2] will not return any v3- - - - -Wahl, et. al. Standards Track [Page 20] - -RFC 2251 LDAPv3 December 1997 - - - specific protocol fields. (Note that not all LDAP servers will - support protocol version 2, since they may be unable to generate - the attribute syntaxes associated with version 2.) - - - name: The name of the directory object that the client wishes to - bind as. This field may take on a null value (a zero length - string) for the purposes of anonymous binds, when authentication - has been performed at a lower layer, or when using SASL credentials - with a mechanism that includes the LDAPDN in the credentials. - - - authentication: information used to authenticate the name, if any, - provided in the Bind Request. - - Upon receipt of a Bind Request, a protocol server will authenticate - the requesting client, if necessary. The server will then return a - Bind Response to the client indicating the status of the - authentication. - - Authorization is the use of this authentication information when - performing operations. Authorization MAY be affected by factors - outside of the LDAP Bind request, such as lower layer security - services. - -4.2.1. Sequencing of the Bind Request - - For some SASL authentication mechanisms, it may be necessary for the - client to invoke the BindRequest multiple times. If at any stage the - client wishes to abort the bind process it MAY unbind and then drop - the underlying connection. Clients MUST NOT invoke operations - between two Bind requests made as part of a multi-stage bind. - - A client may abort a SASL bind negotiation by sending a BindRequest - with a different value in the mechanism field of SaslCredentials, or - an AuthenticationChoice other than sasl. - - If the client sends a BindRequest with the sasl mechanism field as an - empty string, the server MUST return a BindResponse with - authMethodNotSupported as the resultCode. This will allow clients to - abort a negotiation if it wishes to try again with the same SASL - mechanism. - - Unlike LDAP v2, the client need not send a Bind Request in the first - PDU of the connection. The client may request any operations and the - server MUST treat these as unauthenticated. 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. - - - - -Wahl, et. al. Standards Track [Page 21] - -RFC 2251 LDAPv3 December 1997 - - - If the client did not bind before sending a request and receives an - operationsError, it may then send a Bind Request. If this also fails - or the client chooses not to bind on the existing connection, it will - close the connection, reopen it and begin again by first sending a - PDU with a Bind Request. This will aid in interoperating with - servers implementing other versions of LDAP. - - Clients MAY send multiple bind requests on a connection to change - their credentials. A subsequent bind process has the effect of - abandoning all operations outstanding on the connection. (This - simplifies server implementation.) Authentication from earlier binds - are subsequently ignored, and so if the bind fails, the connection - will be treated as anonymous. If a SASL transfer encryption or - integrity mechanism has been negotiated, and that mechanism does not - support the changing of credentials from one identity to another, - then the client MUST instead establish a new connection. - -4.2.2. Authentication and Other Security Services - - The simple authentication option provides minimal authentication - facilities, with the contents of the authentication field consisting - only of a cleartext password. Note that the use of cleartext - passwords is not recommended over open networks when there is no - authentication or encryption being performed by a lower layer; see - the "Security Considerations" section. - - If no authentication is to be performed, then the simple - authentication option MUST be chosen, and the password be of zero - length. (This is often done by LDAPv2 clients.) Typically the DN is - also of zero length. - - The sasl choice allows for any mechanism defined for use with SASL - [12]. The mechanism field contains the name of the mechanism. The - credentials field contains the arbitrary data used for - authentication, inside an OCTET STRING wrapper. Note that unlike - some Internet application protocols where SASL is used, LDAP is not - text-based, thus no base64 transformations are performed on the - credentials. - - If any SASL-based integrity or confidentiality services are enabled, - they take effect following the transmission by the server and - reception by the client of the final BindResponse with resultCode - success. - - The client can request that the server use authentication information - from a lower layer protocol by using the SASL EXTERNAL mechanism. - - - - - -Wahl, et. al. Standards Track [Page 22] - -RFC 2251 LDAPv3 December 1997 - - -4.2.3. Bind Response - - The Bind Response is defined as follows. - - BindResponse ::= [APPLICATION 1] SEQUENCE { - COMPONENTS OF LDAPResult, - serverSaslCreds [7] OCTET STRING OPTIONAL } - - BindResponse consists simply of an indication from the server of he - status of the client's request for authentication. - - f the bind was successful, the resultCode will be success, therwise - it will be one of: - - - operationsError: server encountered an internal error, - - - protocolError: unrecognized version number or incorrect PDU - structure, - - - authMethodNotSupported: unrecognized SASL mechanism name, - - - strongAuthRequired: the server requires authentication be - performed with a SASL mechanism, - - - referral: this server cannot accept this bind and the client - should try another, - - - saslBindInProgress: the server requires the client to send a - new bind request, with the same sasl mechanism, to continue the - authentication process, - - - 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, - - - unavailable: the server is shutting down. - - 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 - with earlier versions of LDAP, in which the bind was always the first - operation, and there was no negotiation.) - - - -Wahl, et. al. Standards Track [Page 23] - -RFC 2251 LDAPv3 December 1997 - - - The serverSaslCreds are used as part of a SASL-defined bind mechanism - to allow the client to authenticate the server to which it is - communicating, or to perform "challenge-response" authentication. If - the client bound with the password choice, or the SASL mechanism does - not require the server to return information to the client, then this - field is not to be included in the result. - -4.3. Unbind Operation - - The function of the Unbind Operation is to terminate a protocol - session. The Unbind Operation is defined as follows: - - UnbindRequest ::= [APPLICATION 2] NULL - - The Unbind Operation has no response defined. Upon transmission of an - UnbindRequest, a protocol client may assume that the protocol session - is terminated. Upon receipt of an UnbindRequest, a protocol server - may assume that the requesting client has terminated the session and - that all outstanding requests may be discarded, and may close the - connection. - -4.4. Unsolicited Notification - - An unsolicited notification is an LDAPMessage sent from the server to - the client which is not in response to any LDAPMessage received by - the server. It 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. - - The unsolicited notification is structured as an LDAPMessage in which - the messageID is 0 and protocolOp is of the extendedResp form. The - responseName field of the ExtendedResponse is present. The LDAPOID - value MUST be unique for this notification, and not be used in any - other situation. - - One unsolicited notification is defined in this document. - -4.4.1. Notice of Disconnection - - This notification may be used by the server to advise the client that - the server is about to close the connection due to an error - condition. Note that this notification is NOT a response to an - unbind requested by the client: the server MUST follow the procedures - of section 4.3. This notification is intended to assist clients in - distinguishing between an error condition and a transient network - - - - - -Wahl, et. al. Standards Track [Page 24] - -RFC 2251 LDAPv3 December 1997 - - - failure. As with a connection close due to network failure, the - client MUST NOT assume that any outstanding requests which modified - the directory have succeeded or failed. - - The responseName is 1.3.6.1.4.1.1466.20036, the response field is - absent, and the resultCode is used to indicate the reason for the - disconnection. - - The following resultCode values are to be used in this notification: - - - protocolError: The server has received data from the client in - which - the LDAPMessage structure could not be parsed. - - - strongAuthRequired: The server has detected that an established - underlying security association protecting communication between - the client and server has unexpectedly failed or been compromised. - - - unavailable: This server will stop accepting new connections and - operations on all existing connections, and be unavailable for an - extended period of time. The client may make use of an alternative - server. - - After sending this notice, the server MUST close the connection. - After receiving this notice, the client MUST NOT transmit any further - on the connection, and may abruptly close the connection. - -4.5. Search Operation - - The Search Operation allows a client to request that a search be - performed on its behalf by a server. This can be used to read - attributes from a single entry, from entries immediately below a - particular entry, or a whole subtree of entries. - -4.5.1. Search Request - - The Search Request is defined as follows: - - SearchRequest ::= [APPLICATION 3] SEQUENCE { - baseObject LDAPDN, - scope ENUMERATED { - baseObject (0), - singleLevel (1), - wholeSubtree (2) }, - derefAliases ENUMERATED { - neverDerefAliases (0), - derefInSearching (1), - derefFindingBaseObj (2), - - - -Wahl, et. al. Standards Track [Page 25] - -RFC 2251 LDAPv3 December 1997 - - - derefAlways (3) }, - sizeLimit INTEGER (0 .. maxInt), - timeLimit INTEGER (0 .. maxInt), - typesOnly BOOLEAN, - filter Filter, - attributes AttributeDescriptionList } - - Filter ::= CHOICE { - and [0] SET OF Filter, - or [1] SET OF Filter, - not [2] Filter, - equalityMatch [3] AttributeValueAssertion, - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeDescription, - approxMatch [8] AttributeValueAssertion, - extensibleMatch [9] MatchingRuleAssertion } - - SubstringFilter ::= SEQUENCE { - type AttributeDescription, - -- at least one must be present - substrings SEQUENCE OF CHOICE { - initial [0] LDAPString, - any [1] LDAPString, - final [2] LDAPString } } - - MatchingRuleAssertion ::= SEQUENCE { - matchingRule [1] MatchingRuleId OPTIONAL, - type [2] AttributeDescription OPTIONAL, - matchValue [3] AssertionValue, - dnAttributes [4] BOOLEAN DEFAULT FALSE } - - Parameters of the Search Request are: - - - baseObject: An LDAPDN that is the base object entry relative to - which the search is to be performed. - - - scope: An indicator of the scope of the search to be performed. The - semantics of the possible values of this field are identical to the - semantics of the scope field in the X.511 Search Operation. - - - derefAliases: An indicator as to how alias objects (as defined in - X.501) are to be handled in searching. The semantics of the - possible values of this field are: - - neverDerefAliases: do not dereference aliases in searching - or in locating the base object of the search; - - - -Wahl, et. al. Standards Track [Page 26] - -RFC 2251 LDAPv3 December 1997 - - - derefInSearching: dereference aliases in subordinates of - the base object in searching, but not in locating the - base object of the search; - - derefFindingBaseObj: dereference aliases in locating - the base object of the search, but not when searching - subordinates of the base object; - - derefAlways: dereference aliases both in searching and in - locating the base object of the search. - - - sizelimit: A sizelimit that restricts the maximum number of entries - to be returned as a result of the search. A value of 0 in this - field indicates that no client-requested sizelimit restrictions are - in effect for the search. Servers may enforce a maximum number of - entries to return. - - - timelimit: A timelimit that restricts the maximum time (in seconds) - allowed for a search. A value of 0 in this field indicates that no - client-requested timelimit restrictions are in effect for the - search. - - - typesOnly: An indicator as to whether search results will contain - both attribute types and values, or just attribute types. Setting - this field to TRUE causes only attribute types (no values) to be - returned. Setting this field to FALSE causes both attribute types - and values to be returned. - - - filter: A filter that defines the conditions that must be fulfilled - in order for the search to match a given entry. - - The 'and', 'or' and 'not' choices can be used to form combinations of - filters. At least one filter element MUST be present in an 'and' or - 'or' choice. The others match against individual attribute values of - entries in the scope of the search. (Implementor's note: the 'not' - filter is an example of a tagged choice in an implicitly-tagged - module. In BER this is treated as if the tag was explicit.) - - A server MUST evaluate filters according to the three-valued logic - of X.511(93) section 7.8.1. In summary, a filter is evaluated to - either "TRUE", "FALSE" or "Undefined". If the filter evaluates - to TRUE for a particular entry, then the attributes of that entry - are returned as part of the search result (subject to any applicable - access control restrictions). If the filter evaluates to FALSE or - Undefined, then the entry is ignored for the search. - - - - - - -Wahl, et. al. Standards Track [Page 27] - -RFC 2251 LDAPv3 December 1997 - - - A filter of the "and" choice is TRUE if all the filters in the SET - OF evaluate to TRUE, FALSE if at least one filter is FALSE, and - otherwise Undefined. A filter of the "or" choice is FALSE if all - of the filters in the SET OF evaluate to FALSE, TRUE if at least - one filter is TRUE, and Undefined otherwise. A filter of the "not" - choice is TRUE if the filter being negated is FALSE, FALSE if it is - TRUE, and Undefined if it is Undefined. - - The present match evaluates to TRUE where there is an attribute or - subtype of the specified attribute description present in an entry, - and FALSE otherwise (including a presence test with an unrecognized - attribute description.) - - The extensibleMatch is new in this version of LDAP. If the - matchingRule field is absent, the type field MUST be present, and - the equality match is performed for that type. If the type field is - absent and matchingRule is present, the matchValue is compared - against all attributes in an entry which support that matchingRule, - and the matchingRule determines the syntax for the assertion value - (the filter item evaluates to TRUE if it matches with at least - one attribute in the entry, FALSE if it does not match any attribute - in the entry, and Undefined if the matchingRule is not recognized - or the assertionValue cannot be parsed.) If the type field is - present and matchingRule is present, the matchingRule MUST be one - permitted for use with that type, otherwise the filter item is - undefined. If the dnAttributes field is set to TRUE, the match is - applied against all the attributes in an entry's distinguished name - as well, and also evaluates to TRUE if there is at least one - attribute in the distinguished name for which the filter item - evaluates to TRUE. (Editors note: The dnAttributes field is present - so that there does not need to be multiple versions of generic - matching rules such as for word matching, one to apply to entries - and another to apply to entries and dn attributes as well). - - A filter item evaluates to Undefined when the server would not - be able to determine whether the assertion value matches an - entry. If an attribute description in an equalityMatch, substrings, - greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch - filter is not recognized by the server, a matching rule id in the - extensibleMatch is not recognized by the server, the assertion - value cannot be parsed, or the type of filtering requested is not - implemented, then the filter is Undefined. Thus for example if a - server did not recognize the attribute type shoeSize, a filter of - (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12), - (shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined. - - - - - - -Wahl, et. al. Standards Track [Page 28] - -RFC 2251 LDAPv3 December 1997 - - - Servers MUST NOT return errors if attribute descriptions or matching - rule ids are not recognized, or assertion values cannot be parsed. - More details of filter processing are given in section 7.8 of X.511 - [8]. - - - attributes: A list of the attributes to be returned from each entry - which matches the search filter. There are two special values which - may be used: an empty list with no attributes, and the attribute - description string "*". Both of these signify that all user - attributes are to be returned. (The "*" allows the client to - request all user attributes in addition to specific operational - attributes). - - Attributes MUST be named at most once in the list, and are returned - at most once in an entry. If there are attribute descriptions in - the list which are not recognized, they are ignored by the server. - - If the client does not want any attributes returned, it can specify - a list containing only the attribute with OID "1.1". This OID was - chosen arbitrarily and does not correspond to any attribute in use. - - Client implementors should note that even if all user attributes are - requested, some attributes of the entry may not be included in - search results due to access control or other restrictions. - Furthermore, servers will not return operational attributes, such - as objectClasses or attributeTypes, unless they are listed by name, - since there may be extremely large number of values for certain - operational attributes. (A list of operational attributes for use - in LDAP is given in [5].) - - Note that an X.500 "list"-like operation can be emulated by the client - requesting a one-level LDAP search operation with a filter checking - for the existence of the objectClass attribute, and that an X.500 - "read"-like operation can be emulated by a base object LDAP search - operation with the same filter. A server which provides a gateway to - X.500 is not required to use the Read or List operations, although it - may choose to do so, and if it does must provide the same semantics - as the X.500 search operation. - -4.5.2. Search Result - - The results of the search attempted by the server upon receipt of a - Search Request are returned in Search Responses, which are LDAP - messages containing either SearchResultEntry, SearchResultReference, - ExtendedResponse or SearchResultDone data types. - - SearchResultEntry ::= [APPLICATION 4] SEQUENCE { - objectName LDAPDN, - - - -Wahl, et. al. Standards Track [Page 29] - -RFC 2251 LDAPv3 December 1997 - - - attributes PartialAttributeList } - - PartialAttributeList ::= SEQUENCE OF SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - -- implementors should note that the PartialAttributeList may - -- have zero elements (if none of the attributes of that entry - -- were requested, or could be returned), and that the vals set - -- may also have zero elements (if types only was requested, or - -- all values were excluded from the result.) - - SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL - -- at least one LDAPURL element must be present - - SearchResultDone ::= [APPLICATION 5] LDAPResult - - Upon receipt of a Search Request, a server will perform the necessary - search of the DIT. - - If the LDAP session is operating over a connection-oriented transport - such as TCP, the server will return to the client a sequence of - responses in separate LDAP messages. There may be zero or more - responses containing SearchResultEntry, one for each entry found - during the search. There may also be zero or more responses - containing SearchResultReference, one for each area not explored by - this server during the search. The SearchResultEntry and - SearchResultReference PDUs may come in any order. Following all the - SearchResultReference responses and all SearchResultEntry responses - to be returned by the server, the server will return a response - containing the SearchResultDone, which contains an indication of - success, or detailing any errors that have occurred. - - Each entry returned in a SearchResultEntry will contain all - attributes, complete with associated values if necessary, as - specified in the attributes field of the Search Request. Return of - attributes is subject to access control and other administrative - policy. Some attributes may be returned in binary format (indicated - by the AttributeDescription in the response having the binary option - present). - - Some attributes may be constructed by the server and appear in a - SearchResultEntry attribute list, although they are not stored - attributes of an entry. Clients MUST NOT assume that all attributes - can be modified, even if permitted by access control. - - LDAPMessage responses of the ExtendedResponse form are reserved for - returning information associated with a control requested by the - client. These may be defined in future versions of this document. - - - -Wahl, et. al. Standards Track [Page 30] - -RFC 2251 LDAPv3 December 1997 - - -4.5.3. Continuation References in the Search Result - - If the server was able to locate the entry referred to by the - baseObject but was unable to search all the entries in the scope at - and under the baseObject, the server may return one or more - SearchResultReference, each containing a reference to another set of - servers for continuing the operation. A server MUST NOT return any - SearchResultReference if it has not located the baseObject and - thus has not searched any entries; in this case it would return a - SearchResultDone containing a referral resultCode. - - In the absence of indexing information provided to a server from - servers holding subordinate naming contexts, SearchResultReference - responses are not affected by search filters and are always returned - when in scope. - - The SearchResultReference is of the same data type as the Referral. - URLs for servers implementing the LDAP protocol are written according - to [9]. The <dn> part MUST be present in the URL, with the new target - object name. The client MUST use this name in its next request. - Some servers (e.g. part of a distributed index exchange system) may - provide a different filter in the URLs of the SearchResultReference. - If the filter part of the URL is present in an LDAP URL, the client - MUST use the new filter in its next request to progress the search, - and if the filter part is absent the client will use again the same - filter. Other aspects of the new search request may be the same or - different as the search which generated the continuation references. - - Other kinds of URLs may be returned so long as the operation could be - performed using that protocol. - - The name of an unexplored subtree in a SearchResultReference need not - be subordinate to the base object. - - In order to complete the search, the client MUST issue a new search - operation for each SearchResultReference that is returned. Note that - the abandon operation described in section 4.11 applies only to a - particular operation sent on a connection between a client and server, - and if the client has multiple outstanding search operations to - different servers, it MUST abandon each operation individually. - -4.5.3.1. Example - - For example, suppose the contacted server (hosta) holds the entry - "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that - either LDAP-capable servers (hostb) or (hostc) hold - "OU=People,O=MNN,C=WW" (one is the master and the other server a - - - - -Wahl, et. al. Standards Track [Page 31] - -RFC 2251 LDAPv3 December 1997 - - - shadow), and that LDAP-capable server (hostd) holds the subtree - "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is - requested to the contacted server, it may return the following: - - SearchResultEntry for O=MNN,C=WW - SearchResultEntry for CN=Manager,O=MNN,C=WW - SearchResultReference { - ldap://hostb/OU=People,O=MNN,C=WW - ldap://hostc/OU=People,O=MNN,C=WW - } - SearchResultReference { - ldap://hostd/OU=Roles,O=MNN,C=WW - } - SearchResultDone (success) - - Client implementors should note that when following a - SearchResultReference, additional SearchResultReference may be - generated. Continuing the example, if the client contacted the - server (hostb) and issued the search for the subtree - "OU=People,O=MNN,C=WW", the server might respond as follows: - - SearchResultEntry for OU=People,O=MNN,C=WW - SearchResultReference { - ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW - } - SearchResultReference { - ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW - } - SearchResultDone (success) - - If the contacted server does not hold the base object for the search, - then it will return a referral to the client. For example, if the - client requests a subtree search of "O=XYZ,C=US" to hosta, the server - may return only a SearchResultDone containing a referral. - - SearchResultDone (referral) { - ldap://hostg/ - } - -4.6. Modify Operation - - The Modify Operation allows a client to request that a modification - of an entry be performed on its behalf by a server. The Modify - Request is defined as follows: - - ModifyRequest ::= [APPLICATION 6] SEQUENCE { - object LDAPDN, - modification SEQUENCE OF SEQUENCE { - - - -Wahl, et. al. Standards Track [Page 32] - -RFC 2251 LDAPv3 December 1997 - - - operation ENUMERATED { - add (0), - delete (1), - replace (2) }, - modification AttributeTypeAndValues } } - - AttributeTypeAndValues ::= SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - - Parameters of the Modify Request are: - - - object: The object to be modified. The value of this field contains - the DN of the entry to be modified. The server will not perform - any alias dereferencing in determining the object to be modified. - - - modification: A list of modifications to be performed on the entry. - The entire list of entry modifications MUST be performed - in the order they are listed, as a single atomic operation. While - individual modifications may violate the directory schema, the - resulting entry after the entire list of modifications is performed - MUST conform to the requirements of the directory schema. The - values that may be taken on by the 'operation' field in each - modification construct have the following semantics respectively: - - add: add values listed to the given attribute, creating - the attribute if necessary; - - delete: delete values listed from the given attribute, - removing the entire attribute if no values are listed, or - if all current values of the attribute are listed for - deletion; - - replace: replace all existing values of the given attribute - with the new values listed, creating the attribute if it - did not already exist. A replace with no value will delete - the entire attribute if it exists, and is ignored if the - attribute does not exist. - - The result of the modify attempted by the server upon receipt of a - Modify Request is returned in a Modify Response, defined as follows: - - ModifyResponse ::= [APPLICATION 7] LDAPResult - - Upon receipt of a Modify Request, a server will perform the necessary - modifications to the DIT. - - - - - -Wahl, et. al. Standards Track [Page 33] - -RFC 2251 LDAPv3 December 1997 - - - The server will return to the client a single Modify Response - indicating either the successful completion of the DIT modification, - or the reason that the modification failed. Note that due to the - requirement for atomicity in applying the list of modifications in - the Modify Request, the client may expect that no modifications of - the DIT have been performed if the Modify Response received indicates - any sort of error, and that all requested modifications have been - performed if the Modify Response indicates successful completion of - the Modify Operation. If the connection fails, whether the - modification occurred or not is indeterminate. - - The Modify Operation cannot be used to remove from an entry any of - its distinguished values, those values which 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 4.9 is used to rename an entry. - - If an equality match filter has not been defined for an attribute type, - clients MUST NOT attempt to delete individual values of that attribute - from an entry using the "delete" form of a modification, and MUST - instead use the "replace" form. - - Note that due to the simplifications made in LDAP, there is not a - direct mapping of the modifications in an LDAP ModifyRequest onto the - EntryModifications of a DAP ModifyEntry operation, and different - implementations of LDAP-DAP gateways may use different means of - representing the change. If successful, the final effect of the - operations on the entry MUST be identical. - -4.7. Add Operation - - The Add Operation allows a client to request the addition of an entry - into the directory. The Add Request is defined as follows: - - AddRequest ::= [APPLICATION 8] SEQUENCE { - entry LDAPDN, - attributes AttributeList } - - AttributeList ::= SEQUENCE OF SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - - Parameters of the Add Request are: - - - entry: the Distinguished Name of the entry to be added. Note that - the server will not dereference any aliases in locating the entry - to be added. - - - - -Wahl, et. al. Standards Track [Page 34] - -RFC 2251 LDAPv3 December 1997 - - - - attributes: the list of attributes that make up the content of the - entry being added. Clients MUST include distinguished values - (those forming the entry's own RDN) in this list, the objectClass - attribute, and values of any mandatory attributes of the listed - object classes. Clients MUST NOT supply the createTimestamp or - creatorsName attributes, since these will be generated - automatically by the server. - - The entry named in the entry field of the AddRequest MUST NOT exist - for the AddRequest to succeed. The parent of the entry to be added - MUST exist. For example, if the client attempted to add - "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the - "C=US" entry did exist, then the server would return the error - noSuchObject with the matchedDN field containing "C=US". If the - parent entry exists but is not in a naming context held by the - server, the server SHOULD return a referral to the server holding the - parent entry. - - Servers implementations SHOULD NOT restrict where entries can be - located in the directory. Some servers MAY allow the administrator - to restrict the classes of entries which can be added to the - directory. - - Upon receipt of an Add Request, a server will attempt to perform the - add requested. The result of the add attempt will be returned to the - client in the Add Response, defined as follows: - - AddResponse ::= [APPLICATION 9] LDAPResult - - A response of success indicates that the new entry is present in the - directory. - -4.8. Delete Operation - - The Delete Operation allows a client to request the removal of an - entry from the directory. The Delete Request is defined as follows: - - DelRequest ::= [APPLICATION 10] LDAPDN - - The Delete Request consists of the Distinguished Name of the entry to - be deleted. Note that the server will not dereference aliases while - resolving the name of the target entry to be removed, and that only - leaf entries (those with no subordinate entries) can be deleted with - this operation. - - The result of the delete attempted by the server upon receipt of a - Delete Request is returned in the Delete Response, defined as - follows: - - - -Wahl, et. al. Standards Track [Page 35] - -RFC 2251 LDAPv3 December 1997 - - - DelResponse ::= [APPLICATION 11] LDAPResult - - Upon receipt of a Delete Request, a server will attempt to perform - the entry removal requested. The result of the delete attempt will be - returned to the client in the Delete Response. - -4.9. Modify DN Operation - - The Modify DN Operation allows a client to change the leftmost (least - significant) component of the name of an entry in the directory, or - to move a subtree of entries to a new location in the directory. The - Modify DN Request is defined as follows: - - ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { - entry LDAPDN, - newrdn RelativeLDAPDN, - deleteoldrdn BOOLEAN, - newSuperior [0] LDAPDN OPTIONAL } - - Parameters of the Modify DN Request are: - - - entry: the Distinguished Name of the entry to be changed. This - entry may or may not have subordinate entries. - - - newrdn: the RDN that will form the leftmost component of the new - name of the entry. - - - deleteoldrdn: a boolean parameter that controls whether the old RDN - attribute values are to be retained as attributes of the entry, or - deleted from the entry. - - - newSuperior: if present, this is the Distinguished Name of the entry - which becomes the immediate superior of the existing entry. - - The result of the name change attempted by the server upon receipt of - a Modify DN Request is returned in the Modify DN Response, defined - as follows: - - ModifyDNResponse ::= [APPLICATION 13] LDAPResult - - Upon receipt of a ModifyDNRequest, a server will attempt to - perform the name change. The result of the name change attempt will - be returned to the client in the Modify DN Response. - - For example, if the entry named in the "entry" parameter was - "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", - and the newSuperior parameter was absent, then this operation would - - - - -Wahl, et. al. Standards Track [Page 36] - -RFC 2251 LDAPv3 December 1997 - - - attempt to rename the entry to be "cn=John Cougar Smith,c=US". If - there was already an entry with that name, the operation would fail - with error code entryAlreadyExists. - - If the deleteoldrdn parameter is TRUE, the values forming the old - RDN are deleted from the entry. If the deleteoldrdn parameter is - FALSE, the values forming the old RDN will be retained as - non-distinguished attribute values of the entry. The server may - not perform the operation and return an error code if the setting of - the deleteoldrdn parameter would cause a schema inconsistency in the - entry. - - 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. - -4.10. Compare Operation - - The Compare Operation allows a client to compare an assertion - provided with an entry in the directory. The Compare Request is - defined as follows: - - CompareRequest ::= [APPLICATION 14] SEQUENCE { - entry LDAPDN, - ava AttributeValueAssertion } - - Parameters of the Compare Request are: - - - entry: the name of the entry to be compared with. - - - ava: the assertion with which an attribute in the entry is to be - compared. - - The result of the compare attempted by the server upon receipt of a - Compare Request is returned in the Compare Response, defined as - follows: - - CompareResponse ::= [APPLICATION 15] LDAPResult - - Upon receipt of a Compare Request, a server will attempt to perform - the requested comparison. The result of the comparison will be - returned to the client in the Compare Response. Note that errors and - the result of comparison are all returned in the same construct. - - - - - -Wahl, et. al. Standards Track [Page 37] - -RFC 2251 LDAPv3 December 1997 - - - Note that some directory systems may establish access controls which - permit the values of certain attributes (such as userPassword) to be - compared but not read. In a search result, it may be that an - attribute of that type would be returned, but with an empty set of - values. - -4.11. Abandon Operation - - The function of the Abandon Operation is to allow a client to request - that the server abandon an outstanding operation. The Abandon - Request is defined as follows: - - AbandonRequest ::= [APPLICATION 16] MessageID - - The MessageID MUST be that of a an operation which was requested - earlier in this connection. - - (The abandon request itself has its own message id. This is distinct - from the id of the earlier operation being abandoned.) - - There is no response defined in the Abandon Operation. Upon - transmission of an Abandon Operation, a client may expect that the - operation identified by the Message ID in the Abandon Request has - been abandoned. In the event that a server receives an Abandon - Request on a Search Operation in the midst of transmitting responses - to the search, that server MUST cease transmitting entry responses to - the abandoned request immediately, and MUST NOT send the - SearchResponseDone. Of course, the server MUST ensure that only - properly encoded LDAPMessage PDUs are transmitted. - - Clients MUST NOT send abandon requests for the same operation - multiple times, and MUST also be prepared to receive results from - operations it has abandoned (since these may have been in transit - when the abandon was requested). - - Servers MUST discard abandon requests for message IDs they do not - recognize, for operations which cannot be abandoned, and for - operations which have already been abandoned. - -4.12. Extended Operation - - An extension mechanism has been added in this version of LDAP, in - order to allow additional operations to be defined for services not - available elsewhere in this protocol, for instance digitally signed - operations and results. - - - - - - -Wahl, et. al. Standards Track [Page 38] - -RFC 2251 LDAPv3 December 1997 - - - The extended operation allows clients to make requests and receive - responses with predefined syntaxes and semantics. These may be - defined in RFCs or be private to particular implementations. Each - request MUST have a unique OBJECT IDENTIFIER assigned to it. - - ExtendedRequest ::= [APPLICATION 23] SEQUENCE { - requestName [0] LDAPOID, - requestValue [1] OCTET STRING OPTIONAL } - - The requestName is a dotted-decimal representation of the OBJECT - IDENTIFIER corresponding to the request. The requestValue is - information in a form defined by that request, encapsulated inside an - OCTET STRING. - - The server will respond to this with an LDAPMessage containing the - ExtendedResponse. - - ExtendedResponse ::= [APPLICATION 24] SEQUENCE { - COMPONENTS OF LDAPResult, - responseName [10] LDAPOID OPTIONAL, - response [11] OCTET STRING OPTIONAL } - - If the server does not recognize the request name, it MUST return - only the response fields from LDAPResult, containing the - protocolError result code. - -5. Protocol Element Encodings and Transfer - - One underlying service is defined here. Clients and servers SHOULD - implement the mapping of LDAP over TCP described in 5.2.1. - -5.1. Mapping Onto BER-based Transport Services - - The protocol elements of LDAP are encoded for exchange using the - Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the - high overhead involved in using certain elements of the BER, the - following additional restrictions are placed on BER-encodings of LDAP - protocol elements: - - (1) Only the definite form of length encoding will be used. - - (2) OCTET STRING values will be encoded in the primitive form only. - - (3) If the value of a BOOLEAN type is true, the encoding MUST have - its contents octets set to hex "FF". - - - - - - -Wahl, et. al. Standards Track [Page 39] - -RFC 2251 LDAPv3 December 1997 - - - (4) If a value of a type is its default value, it MUST be absent. - Only some BOOLEAN and INTEGER types have default values in this - protocol definition. - - These restrictions do not apply to ASN.1 types encapsulated inside of - OCTET STRING values, such as attribute values, unless otherwise - noted. - -5.2. Transfer Protocols - - This protocol is designed to run over connection-oriented, reliable - transports, with all 8 bits in an octet being significant in the data - stream. - -5.2.1. Transmission Control Protocol (TCP) - - The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It - is recommended that server implementations running over the TCP MAY - provide a protocol listener on the assigned port, 389. Servers may - instead provide a listener on a different port number. Clients MUST - support contacting servers on any valid TCP port. - -6. Implementation Guidelines - - This document describes an Internet protocol. - -6.1. Server Implementations - - The server MUST be capable of recognizing all the mandatory attribute - type names and implement the syntaxes specified in [5]. Servers MAY - also recognize additional attribute type names. - -6.2. Client Implementations - - Clients which request referrals MUST ensure that they do not loop - between servers. They MUST NOT repeatedly contact the same server for - the same request with the same target entry name, scope and filter. - Some clients may be using a counter that is incremented each time - referral handling occurs for an operation, and these kinds of clients - MUST be able to handle a DIT with at least ten layers of naming - contexts between the root and a leaf entry. - - In the absence of prior agreements with servers, clients SHOULD NOT - assume that servers support any particular schemas beyond those - referenced in section 6.1. Different schemas can have different - attribute types with the same names. The client can retrieve the - subschema entries referenced by the subschemaSubentry attribute in - the server's root DSE or in entries held by the server. - - - -Wahl, et. al. Standards Track [Page 40] - -RFC 2251 LDAPv3 December 1997 - - -7. Security Considerations - - When used with a connection-oriented transport, this version of the - protocol provides facilities for the LDAP v2 authentication - mechanism, simple authentication using a cleartext password, as well - as any SASL mechanism [12]. SASL allows for integrity and privacy - services to be negotiated. - - It is also permitted that the server can return its credentials to - the client, if it chooses to do so. - - Use of cleartext password is strongly discouraged where the - underlying transport service cannot guarantee confidentiality and may - result in disclosure of the password to unauthorized parties. - - When used with SASL, it should be noted that the name field of the - BindRequest is not protected against modification. Thus if the - distinguished name of the client (an LDAPDN) is agreed through the - negotiation of the credentials, it takes precedence over any value in - the unprotected name field. - - Implementations which cache attributes and entries obtained via LDAP - MUST ensure that access controls are maintained if that information - is to be provided to multiple clients, since servers may have access - control policies which prevent the return of entries or attributes in - search results except to particular authenticated clients. For - example, caches could serve result information only to the client - whose request caused it to be cache. - -8. Acknowledgements - - This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes, - and Steve Kille. Design ideas included in this document are based on - those discussed in ASID and other IETF Working Groups. The - contributions of individuals in these working groups is gratefully - acknowledged. - -9. Bibliography - - [1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models - and Service", 1993. - - [2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access - Protocol", RFC 1777, March 1995. - - [3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - - Specification of Basic Notation", 1994. - - - - -Wahl, et. al. Standards Track [Page 41] - -RFC 2251 LDAPv3 December 1997 - - - [4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access - Protocol (v3): UTF-8 String Representation of Distinguished - Names", RFC 2253, December 1997. - - [5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", - RFC 2252, December 1997. - - [6] ITU-T Rec. X.501, "The Directory: Models", 1993. - - [7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", - 1993. - - [9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255, - December 1997. - - [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, - Canonical, and Distinguished Encoding Rules", 1994. - - [12] Meyers, J., "Simple Authentication and Security Layer", - RFC 2222, October 1997. - - [13] Universal Multiple-Octet Coded Character Set (UCS) - - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : - 1993. - - [14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO - 10646", RFC 2044, October 1996. - -10. Authors' Addresses - - Mark Wahl - Critical Angle Inc. - 4815 W Braker Lane #502-385 - Austin, TX 78759 - USA - - Phone: +1 512 372-3160 - EMail: M.Wahl@critical-angle.com - - - - - - -Wahl, et. al. Standards Track [Page 42] - -RFC 2251 LDAPv3 December 1997 - - - Tim Howes - Netscape Communications Corp. - 501 E. Middlefield Rd., MS MV068 - Mountain View, CA 94043 - USA - - Phone: +1 650 937-3419 - EMail: howes@netscape.com - - Steve Kille - Isode Limited - The Dome, The Square - Richmond - TW9 1DT - UK - - Phone: +44-181-332-9091 - EMail: S.Kille@isode.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wahl, et. al. Standards Track [Page 43] - -RFC 2251 LDAPv3 December 1997 - - -Appendix A - Complete ASN.1 Definition - - Lightweight-Directory-Access-Protocol-V3 DEFINITIONS - IMPLICIT TAGS ::= - - BEGIN - - 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 } - - MessageID ::= INTEGER (0 .. maxInt) - - maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- - - LDAPString ::= OCTET STRING - - LDAPOID ::= OCTET STRING - - LDAPDN ::= LDAPString - - RelativeLDAPDN ::= LDAPString - - AttributeType ::= LDAPString - - AttributeDescription ::= LDAPString - - - - -Wahl, et. al. Standards Track [Page 44] - -RFC 2251 LDAPv3 December 1997 - - - AttributeDescriptionList ::= SEQUENCE OF - AttributeDescription - - AttributeValue ::= OCTET STRING - - AttributeValueAssertion ::= SEQUENCE { - attributeDesc AttributeDescription, - assertionValue AssertionValue } - - AssertionValue ::= OCTET STRING - - Attribute ::= SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - - MatchingRuleId ::= LDAPString - - 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), - - - -Wahl, et. al. Standards Track [Page 45] - -RFC 2251 LDAPv3 December 1997 - - - 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), - 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 } - - Referral ::= SEQUENCE OF LDAPURL - - LDAPURL ::= LDAPString -- limited to characters permitted in URLs - - Controls ::= SEQUENCE OF Control - - Control ::= SEQUENCE { - controlType LDAPOID, - criticality BOOLEAN DEFAULT FALSE, - controlValue OCTET STRING OPTIONAL } - - BindRequest ::= [APPLICATION 0] SEQUENCE { - version INTEGER (1 .. 127), - name LDAPDN, - authentication AuthenticationChoice } - - AuthenticationChoice ::= CHOICE { - simple [0] OCTET STRING, - -- 1 and 2 reserved - sasl [3] SaslCredentials } - - SaslCredentials ::= SEQUENCE { - mechanism LDAPString, - credentials OCTET STRING OPTIONAL } - - BindResponse ::= [APPLICATION 1] SEQUENCE { - - - -Wahl, et. al. Standards Track [Page 46] - -RFC 2251 LDAPv3 December 1997 - - - COMPONENTS OF LDAPResult, - serverSaslCreds [7] OCTET STRING OPTIONAL } - - UnbindRequest ::= [APPLICATION 2] NULL - - SearchRequest ::= [APPLICATION 3] SEQUENCE { - baseObject LDAPDN, - scope ENUMERATED { - baseObject (0), - singleLevel (1), - wholeSubtree (2) }, - derefAliases ENUMERATED { - neverDerefAliases (0), - derefInSearching (1), - derefFindingBaseObj (2), - derefAlways (3) }, - sizeLimit INTEGER (0 .. maxInt), - timeLimit INTEGER (0 .. maxInt), - typesOnly BOOLEAN, - filter Filter, - attributes AttributeDescriptionList } - - Filter ::= CHOICE { - and [0] SET OF Filter, - or [1] SET OF Filter, - not [2] Filter, - equalityMatch [3] AttributeValueAssertion, - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeDescription, - approxMatch [8] AttributeValueAssertion, - extensibleMatch [9] MatchingRuleAssertion } - - SubstringFilter ::= SEQUENCE { - type AttributeDescription, - -- at least one must be present - substrings SEQUENCE OF CHOICE { - initial [0] LDAPString, - any [1] LDAPString, - final [2] LDAPString } } - - MatchingRuleAssertion ::= SEQUENCE { - matchingRule [1] MatchingRuleId OPTIONAL, - type [2] AttributeDescription OPTIONAL, - matchValue [3] AssertionValue, - dnAttributes [4] BOOLEAN DEFAULT FALSE } - - - - -Wahl, et. al. Standards Track [Page 47] - -RFC 2251 LDAPv3 December 1997 - - - SearchResultEntry ::= [APPLICATION 4] SEQUENCE { - objectName LDAPDN, - attributes PartialAttributeList } - - PartialAttributeList ::= SEQUENCE OF SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - - SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL - - SearchResultDone ::= [APPLICATION 5] LDAPResult - - ModifyRequest ::= [APPLICATION 6] SEQUENCE { - object LDAPDN, - modification SEQUENCE OF SEQUENCE { - operation ENUMERATED { - add (0), - delete (1), - replace (2) }, - modification AttributeTypeAndValues } } - - AttributeTypeAndValues ::= SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - - ModifyResponse ::= [APPLICATION 7] LDAPResult - - AddRequest ::= [APPLICATION 8] SEQUENCE { - entry LDAPDN, - attributes AttributeList } - - AttributeList ::= SEQUENCE OF SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - - AddResponse ::= [APPLICATION 9] LDAPResult - - DelRequest ::= [APPLICATION 10] LDAPDN - - DelResponse ::= [APPLICATION 11] LDAPResult - - ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { - entry LDAPDN, - newrdn RelativeLDAPDN, - deleteoldrdn BOOLEAN, - newSuperior [0] LDAPDN OPTIONAL } - - ModifyDNResponse ::= [APPLICATION 13] LDAPResult - - - -Wahl, et. al. Standards Track [Page 48] - -RFC 2251 LDAPv3 December 1997 - - - CompareRequest ::= [APPLICATION 14] SEQUENCE { - entry LDAPDN, - ava AttributeValueAssertion } - - CompareResponse ::= [APPLICATION 15] LDAPResult - - AbandonRequest ::= [APPLICATION 16] MessageID - - 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 } - - END - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wahl, et. al. Standards Track [Page 49] - -RFC 2251 LDAPv3 December 1997 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Wahl, et. al. Standards Track [Page 50] - diff --git a/source4/ldap_server/devdocs/rfc2252.txt b/source4/ldap_server/devdocs/rfc2252.txt deleted file mode 100644 index 5a72b7768a7..00000000000 --- a/source4/ldap_server/devdocs/rfc2252.txt +++ /dev/null @@ -1,1795 +0,0 @@ - - - - - - -Network Working Group M. Wahl -Request for Comments: 2252 Critical Angle Inc. -Category: Standards Track A. Coulbeck - Isode Inc. - T. Howes - Netscape Communications Corp. - S. Kille - Isode Limited - December 1997 - - - Lightweight Directory Access Protocol (v3): - Attribute Syntax Definitions - -1. Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -IESG Note - - This document describes a directory access protocol that provides - both read and update access. Update access requires secure - authentication, but this document does not mandate implementation of - any satisfactory authentication mechanisms. - - In accordance with RFC 2026, section 4.4.1, this specification is - being approved by IESG as a Proposed Standard despite this - limitation, for the following reasons: - - a. to encourage implementation and interoperability testing of - these protocols (with or without update access) before they - are deployed, and - - b. to encourage deployment and use of these protocols in read-only - applications. (e.g. applications where LDAPv3 is used as - a query language for directories which are updated by some - secure mechanism other than LDAP), and - - - - - - -Wahl, et. al. Standards Track [Page 1] - -RFC 2252 LADPv3 Attributes December 1997 - - - c. to avoid delaying the advancement and deployment of other Internet - standards-track protocols which require the ability to query, but - not update, LDAPv3 directory servers. - - Readers are hereby warned that until mandatory authentication - mechanisms are standardized, clients and servers written according to - this specification which make use of update functionality are - UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION - IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. - - Implementors are hereby discouraged from deploying LDAPv3 clients or - servers which implement the update functionality, until a Proposed - Standard for mandatory authentication in LDAPv3 has been approved and - published as an RFC. - -2. Abstract - - The Lightweight Directory Access Protocol (LDAP) [1] requires that - the contents of AttributeValue fields in protocol elements be octet - strings. This document defines a set of syntaxes for LDAPv3, and the - rules by which attribute values of these syntaxes are represented as - octet strings for transmission in the LDAP protocol. The syntaxes - defined in this document are referenced by this and other documents - that define attribute types. This document also defines the set of - attribute types which LDAP servers should support. - -3. Overview - - This document defines the framework for developing schemas for - directories accessible via the Lightweight Directory Access Protocol. - - Schema is the collection of attribute type definitions, object class - definitions and other information which a server uses to determine - how to match a filter or attribute value assertion (in a compare - operation) against the attributes of an entry, and whether to permit - add and modify operations. - - Section 4 states the general requirements and notations for attribute - types, object classes, syntax and matching rule definitions. - - Section 5 lists attributes, section 6 syntaxes and section 7 object - classes. - - Additional documents define schemas for representing real-world - objects as directory entries. - - - - - - -Wahl, et. al. Standards Track [Page 2] - -RFC 2252 LADPv3 Attributes December 1997 - - -4. General Issues - - This document describes encodings used in an Internet protocol. - - 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 [4]. - - Attribute Type and Object Class definitions are written in a string - representation of the AttributeTypeDescription and - ObjectClassDescription data types defined in X.501(93) [3]. - Implementors are strongly advised to first read the description of - how schema is represented in X.500 before reading the rest of this - document. - -4.1. Common Encoding Aspects - - For the purposes of defining the encoding rules for attribute - syntaxes, the following BNF definitions will be used. They are based - on the BNF styles of RFC 822 [13]. - - a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / - "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / - "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / - "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / - "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / - "T" / "U" / "V" / "W" / "X" / "Y" / "Z" - - d = "0" / "1" / "2" / "3" / "4" / - "5" / "6" / "7" / "8" / "9" - - hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" / - "A" / "B" / "C" / "D" / "E" / "F" - - k = a / d / "-" / ";" - - p = a / d / """ / "(" / ")" / "+" / "," / - "-" / "." / "/" / ":" / "?" / " " - - letterstring = 1*a - - numericstring = 1*d - - anhstring = 1*k - - keystring = a [ anhstring ] - - printablestring = 1*p - - - -Wahl, et. al. Standards Track [Page 3] - -RFC 2252 LADPv3 Attributes December 1997 - - - space = 1*" " - - whsp = [ space ] - - utf8 = <any sequence of octets formed from the UTF-8 [9] - transformation of a character from ISO10646 [10]> - - dstring = 1*utf8 - - qdstring = whsp "'" dstring "'" whsp - - qdstringlist = [ qdstring *( qdstring ) ] - - qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp ) - - In the following BNF for the string representation of OBJECT - IDENTIFIERs, descr is the syntactic representation of an object - descriptor, which consists of letters and digits, starting with a - letter. An OBJECT IDENTIFIER in the numericoid format should not - have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should - not be generated). - - When encoding 'oid' elements in a value, the descr encoding option - SHOULD be used in preference to the numericoid. An object descriptor - is a more readable alias for a number OBJECT IDENTIFIER, and these - (where assigned and known by the implementation) SHOULD be used in - preference to numeric oids to the greatest extent possible. Examples - of object descriptors in LDAP are attribute type, object class and - matching rule names. - - oid = descr / numericoid - - descr = keystring - - numericoid = numericstring *( "." numericstring ) - - woid = whsp oid whsp - - ; set of oids of either form - oids = woid / ( "(" oidlist ")" ) - - oidlist = woid *( "$" woid ) - - ; object descriptors used as schema element names - qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp ) - - qdescrlist = [ qdescr *( qdescr ) ] - - - - -Wahl, et. al. Standards Track [Page 4] - -RFC 2252 LADPv3 Attributes December 1997 - - - qdescr = whsp "'" descr "'" whsp - -4.2. Attribute Types - - The attribute types are described by sample values for the subschema - "attributeTypes" attribute, which is written in the - AttributeTypeDescription syntax. While lines have been folded for - readability, the values transferred in protocol would not contain - newlines. - - The AttributeTypeDescription is encoded according to the following - BNF, and the productions for oid, qdescrs and qdstring are given in - section 4.1. Implementors should note that future versions of this - document may have expanded this BNF to include additional terms. - Terms which begin with the characters "X-" are reserved for private - experiments, and MUST be followed by a <qdstrings>. - - AttributeTypeDescription = "(" whsp - numericoid whsp ; AttributeType identifier - [ "NAME" qdescrs ] ; name used in AttributeType - [ "DESC" qdstring ] ; description - [ "OBSOLETE" whsp ] - [ "SUP" woid ] ; derived from this other - ; AttributeType - [ "EQUALITY" woid ; Matching Rule name - [ "ORDERING" woid ; Matching Rule name - [ "SUBSTR" woid ] ; Matching Rule name - [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 - [ "SINGLE-VALUE" whsp ] ; default multi-valued - [ "COLLECTIVE" whsp ] ; default not collective - [ "NO-USER-MODIFICATION" whsp ]; default user modifiable - [ "USAGE" whsp AttributeUsage ]; default userApplications - whsp ")" - - AttributeUsage = - "userApplications" / - "directoryOperation" / - "distributedOperation" / ; DSA-shared - "dSAOperation" ; DSA-specific, value depends on server - - Servers are not required to provide the same or any text in the - description part of the subschema values they maintain. Servers - SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each - AttributeTypeDescription. - - Servers MUST implement all the attribute types referenced in sections - 5.1, 5.2 and 5.3. - - - - -Wahl, et. al. Standards Track [Page 5] - -RFC 2252 LADPv3 Attributes December 1997 - - - Servers MAY recognize additional names and attributes not listed in - this document, and if they do so, MUST publish the definitions of the - types in the attributeTypes attribute of their subschema entries. - - Schema developers MUST NOT create attribute definitions whose names - conflict with attributes defined for use with LDAP in existing - standards-track RFCs. - - An AttributeDescription can be used as the value in a NAME part of an - AttributeTypeDescription. Note that these are case insensitive. - - Note that the AttributeTypeDescription does not list the matching - rules which can can be used with that attribute type in an - extensibleMatch search filter. This is done using the - matchingRuleUse attribute described in section 4.5. - - This document refines the schema description of X.501 by requiring - that the syntax field in an AttributeTypeDescription be a string - representation of an OBJECT IDENTIFIER for the LDAP string syntax - definition, and an optional indication of the maximum length of a - value of this attribute (defined in section 4.3.2). - -4.3. Syntaxes - - This section defines general requirements for LDAP attribute value - syntax encodings. All documents defining attribute syntax encodings - for use with LDAP are expected to conform to these requirements. - - The encoding rules defined for a given attribute syntax must produce - octet strings. To the greatest extent possible, encoded octet - strings should be usable in their native encoded form for display - purposes. In particular, encoding rules for attribute syntaxes - defining non-binary values should produce strings that can be - displayed with little or no translation by clients implementing LDAP. - There are a few cases (e.g. audio) however, when it is not sensible - to produce a printable representation, and clients MUST NOT assume - that an unrecognized syntax is a string representation. - - In encodings where an arbitrary string, not a Distinguished Name, is - used as part of a larger production, and other than as part of a - Distinguished Name, a backslash quoting mechanism is used to escape - the following separator symbol character (such as "'", "$" or "#") if - it should occur in that string. The backslash is followed by a pair - of hexadecimal digits representing the next character. A backslash - itself in the string which forms part of a larger syntax is always - transmitted as '\5C' or '\5c'. An example is given in section 6.27. - - - - - -Wahl, et. al. Standards Track [Page 6] - -RFC 2252 LADPv3 Attributes December 1997 - - - Syntaxes are also defined for matching rules whose assertion value - syntax is different from the attribute value syntax. - -4.3.1 Binary Transfer of Values - - This encoding format is used if the binary encoding is requested by - the client for an attribute, or if the attribute syntax name is - "1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP - AttributeValue or AssertionValue field is a BER-encoded instance of - the attribute value or a matching rule assertion value ASN.1 data - type as defined for use with X.500. (The first byte inside the OCTET - STRING wrapper is a tag octet. However, the OCTET STRING is still - encoded in primitive form.) - - All servers MUST implement this form for both generating attribute - values in search responses, and parsing attribute values in add, - compare and modify requests, if the attribute type is recognized and - the attribute syntax name is that of Binary. Clients which request - that all attributes be returned from entries MUST be prepared to - receive values in binary (e.g. userCertificate;binary), and SHOULD - NOT simply display binary or unrecognized values to users. - -4.3.2. Syntax Object Identifiers - - Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are - dotted-decimal strings. These are not intended to be displayed to - users. - - noidlen = numericoid [ "{" len "}" ] - - len = numericstring - - The following table lists some of the syntaxes that have been defined - for LDAP thus far. The H-R column suggests whether a value in that - syntax would likely be a human readable string. Clients and servers - need not implement all the syntaxes listed here, and MAY implement - other syntaxes. - - Other documents may define additional syntaxes. However, the - definition of additional arbitrary syntaxes is strongly deprecated - since it will hinder interoperability: today's client and server - implementations generally do not have the ability to dynamically - recognize new syntaxes. In most cases attributes will be defined - with the syntax for directory strings. - - - - - - - -Wahl, et. al. Standards Track [Page 7] - -RFC 2252 LADPv3 Attributes December 1997 - - - Value being represented H-R OBJECT IDENTIFIER - ================================================================= - ACI Item N 1.3.6.1.4.1.1466.115.121.1.1 - Access Point Y 1.3.6.1.4.1.1466.115.121.1.2 - Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3 - Audio N 1.3.6.1.4.1.1466.115.121.1.4 - Binary N 1.3.6.1.4.1.1466.115.121.1.5 - Bit String Y 1.3.6.1.4.1.1466.115.121.1.6 - Boolean Y 1.3.6.1.4.1.1466.115.121.1.7 - Certificate N 1.3.6.1.4.1.1466.115.121.1.8 - Certificate List N 1.3.6.1.4.1.1466.115.121.1.9 - Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10 - Country String Y 1.3.6.1.4.1.1466.115.121.1.11 - DN Y 1.3.6.1.4.1.1466.115.121.1.12 - Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13 - Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14 - Directory String Y 1.3.6.1.4.1.1466.115.121.1.15 - DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16 - DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17 - DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18 - DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19 - DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20 - Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21 - Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22 - Fax N 1.3.6.1.4.1.1466.115.121.1.23 - Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24 - Guide Y 1.3.6.1.4.1.1466.115.121.1.25 - IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26 - INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27 - JPEG N 1.3.6.1.4.1.1466.115.121.1.28 - LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54 - LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56 - LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57 - Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29 - Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30 - Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31 - Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32 - MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33 - Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55 - Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34 - Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35 - Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36 - Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37 - Octet String Y 1.3.6.1.4.1.1466.115.121.1.40 - OID Y 1.3.6.1.4.1.1466.115.121.1.38 - Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39 - Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41 - Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42 - - - -Wahl, et. al. Standards Track [Page 8] - -RFC 2252 LADPv3 Attributes December 1997 - - - Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43 - Printable String Y 1.3.6.1.4.1.1466.115.121.1.44 - Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58 - Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45 - Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46 - Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47 - Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48 - Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49 - Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50 - Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51 - Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52 - UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53 - - A suggested minimum upper bound on the number of characters in value - with a string-based syntax, or the number of bytes in a value for all - other syntaxes, may be indicated by appending this bound count inside - of curly braces following the syntax name's OBJECT IDENTIFIER in an - Attribute Type Description. This bound is not part of the syntax - name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that - server implementations should allow a string to be 64 characters - long, although they may allow longer strings. Note that a single - character of the Directory String syntax may be encoded in more than - one byte since UTF-8 is a variable-length encoding. - -4.3.3. Syntax Description - - The following BNF may be used to associate a short description with a - syntax OBJECT IDENTIFIER. Implementors should note that future - versions of this document may expand this definition to include - additional terms. Terms whose identifier begins with "X-" are - reserved for private experiments, and MUST be followed by a - <qdstrings>. - - SyntaxDescription = "(" whsp - numericoid whsp - [ "DESC" qdstring ] - whsp ")" - -4.4. Object Classes - - The format for representation of object classes is defined in X.501 - [3]. In general every entry will contain an abstract class ("top" or - "alias"), at least one structural object class, and zero or more - auxiliary object classes. Whether an object class is abstract, - structural or auxiliary is defined when the object class identifier - is assigned. An object class definition should not be changed - without having a new identifier assigned to it. - - - - -Wahl, et. al. Standards Track [Page 9] - -RFC 2252 LADPv3 Attributes December 1997 - - - Object class descriptions are written according to the following BNF. - Implementors should note that future versions of this document may - expand this definition to include additional terms. Terms whose - identifier begins with "X-" are reserved for private experiments, and - MUST be followed by a <qdstrings> encoding. - - ObjectClassDescription = "(" whsp - numericoid whsp ; ObjectClass identifier - [ "NAME" qdescrs ] - [ "DESC" qdstring ] - [ "OBSOLETE" whsp ] - [ "SUP" oids ] ; Superior ObjectClasses - [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] - ; default structural - [ "MUST" oids ] ; AttributeTypes - [ "MAY" oids ] ; AttributeTypes - whsp ")" - - These are described as sample values for the subschema - "objectClasses" attribute for a server which implements the LDAP - schema. While lines have been folded for readability, the values - transferred in protocol would not contain newlines. - - Servers SHOULD implement all the object classes referenced in section - 7, except for extensibleObject, which is optional. Servers MAY - implement additional object classes not listed in this document, and - if they do so, MUST publish the definitions of the classes in the - objectClasses attribute of their subschema entries. - - Schema developers MUST NOT create object class definitions whose - names conflict with attributes defined for use with LDAP in existing - standards-track RFCs. - -4.5. Matching Rules - - Matching rules are used by servers to compare attribute values - against assertion values when performing Search and Compare - operations. They are also used to identify the value to be added or - deleted when modifying entries, and are used when comparing a - purported distinguished name with the name of an entry. - - Most of the attributes given in this document will have an equality - matching rule defined. - - Matching rule descriptions are written according to the following - BNF. Implementors should note that future versions of this document - may have expanded this BNF to include additional terms. Terms whose - identifier begins with "X-" are reserved for private experiments, and - - - -Wahl, et. al. Standards Track [Page 10] - -RFC 2252 LADPv3 Attributes December 1997 - - - MUST be followed by a <qdstrings> encoding. - - MatchingRuleDescription = "(" whsp - numericoid whsp ; MatchingRule identifier - [ "NAME" qdescrs ] - [ "DESC" qdstring ] - [ "OBSOLETE" whsp ] - "SYNTAX" numericoid - whsp ")" - - Values of the matchingRuleUse list the attributes which are suitable - for use with an extensible matching rule. - - MatchingRuleUseDescription = "(" whsp - numericoid whsp ; MatchingRule identifier - [ "NAME" qdescrs ] - [ "DESC" qdstring ] - [ "OBSOLETE" ] - "APPLIES" oids ; AttributeType identifiers - whsp ")" - - Servers which support matching rules and the extensibleMatch SHOULD - implement all the matching rules in section 8. - - Servers MAY implement additional matching rules not listed in this - document, and if they do so, MUST publish the definitions of the - matching rules in the matchingRules attribute of their subschema - entries. If the server supports the extensibleMatch, then the server - MUST publish the relationship between the matching rules and - attributes in the matchingRuleUse attribute. - - For example, a server which implements a privately-defined matching - rule for performing sound-alike matches on Directory String-valued - attributes would include the following in the subschema entry - (1.2.3.4.5 is an example, the OID of an actual matching rule would be - different): - - matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - If this matching rule could be used with the attributes 2.5.4.41 and - 2.5.4.15, the following would also be present: - - matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) ) - - - - - - - -Wahl, et. al. Standards Track [Page 11] - -RFC 2252 LADPv3 Attributes December 1997 - - - A client could then make use of this matching rule by sending a - search operation in which the filter is of the extensibleMatch - choice, the matchingRule field is "soundAlikeMatch", and the type - field is "2.5.4.41" or "2.5.4.15". - -5. Attribute Types - - All LDAP server implementations MUST recognize the attribute types - defined in this section. - - Servers SHOULD also recognize all the attributes from section 5 of - [12]. - -5.1. Standard Operational Attributes - - Servers MUST maintain values of these attributes in accordance with - the definitions in X.501(93). - -5.1.1. createTimestamp - - This attribute SHOULD appear in entries which were created using the - Add operation. - - ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - -5.1.2. modifyTimestamp - - This attribute SHOULD appear in entries which have been modified - using the Modify operation. - - ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - -5.1.3. creatorsName - - This attribute SHOULD appear in entries which were created using the - Add operation. - - ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - - - - - -Wahl, et. al. Standards Track [Page 12] - -RFC 2252 LADPv3 Attributes December 1997 - - -5.1.4. modifiersName - - This attribute SHOULD appear in entries which have been modified - using the Modify operation. - - ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - -5.1.5. subschemaSubentry - - The value of this attribute is the name of a subschema entry (or - subentry if the server is based on X.500(93)) in which the server - makes available attributes specifying the schema. - - ( 2.5.18.10 NAME 'subschemaSubentry' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION - SINGLE-VALUE USAGE directoryOperation ) - -5.1.6. attributeTypes - - This attribute is typically located in the subschema entry. - - ( 2.5.21.5 NAME 'attributeTypes' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation ) - -5.1.7. objectClasses - - This attribute is typically located in the subschema entry. - - ( 2.5.21.6 NAME 'objectClasses' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) - -5.1.8. matchingRules - - This attribute is typically located in the subschema entry. - - ( 2.5.21.4 NAME 'matchingRules' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation ) - - - - - - - - -Wahl, et. al. Standards Track [Page 13] - -RFC 2252 LADPv3 Attributes December 1997 - - -5.1.9. matchingRuleUse - - This attribute is typically located in the subschema entry. - - ( 2.5.21.8 NAME 'matchingRuleUse' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation ) - -5.2. LDAP Operational Attributes - - These attributes are only present in the root DSE (see [1] and [3]). - - Servers MUST recognize these attribute names, but it is not required - that a server provide values for these attributes, when the attribute - corresponds to a feature which the server does not implement. - -5.2.1. namingContexts - - The values of this attribute correspond to naming contexts which this - server masters or shadows. If the server does not master any - information (e.g. it is an LDAP gateway to a public X.500 directory) - this attribute will be absent. If the server believes it contains - the entire directory, the attribute will have a single value, and - that value will be the empty string (indicating the null DN of the - root). This attribute will allow a client to choose suitable base - objects for searching when it has contacted a server. - - ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation ) - -5.2.2. altServer - - The values of this attribute are URLs of other servers which may be - contacted when this server becomes unavailable. If the server does - not know of any other servers which could be used this attribute will - be absent. Clients may cache this information in case their preferred - LDAP server later becomes unavailable. - - ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation ) - -5.2.3. supportedExtension - - The values of this attribute are OBJECT IDENTIFIERs identifying the - supported extended operations which the server supports. - - If the server does not support any extensions this attribute will be - absent. - - - -Wahl, et. al. Standards Track [Page 14] - -RFC 2252 LADPv3 Attributes December 1997 - - - ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) - -5.2.4. supportedControl - - The values of this attribute are the OBJECT IDENTIFIERs identifying - controls which the server supports. If the server does not support - any controls, this attribute will be absent. - - ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) - -5.2.5. supportedSASLMechanisms - - The values of this attribute are the names of supported SASL - mechanisms which the server supports. If the server does not support - any mechanisms this attribute will be absent. - - ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation ) - -5.2.6. supportedLDAPVersion - - The values of this attribute are the versions of the LDAP protocol - which the server implements. - - ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation ) - -5.3. LDAP Subschema Attribute - - This attribute is typically located in the subschema entry. - -5.3.1. ldapSyntaxes - - Servers MAY use this attribute to list the syntaxes which are - implemented. Each value corresponds to one syntax. - - ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation ) - -5.4. X.500 Subschema attributes - - These attributes are located in the subschema entry. All servers - SHOULD recognize their name, although typically only X.500 servers - will implement their functionality. - - - - -Wahl, et. al. Standards Track [Page 15] - -RFC 2252 LADPv3 Attributes December 1997 - - -5.4.1. dITStructureRules - - ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation ) - -5.4.2. nameForms - - ( 2.5.21.7 NAME 'nameForms' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation ) - -5.4.3. ditContentRules - - ( 2.5.21.2 NAME 'dITContentRules' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation ) - -6. Syntaxes - - Servers SHOULD recognize all the syntaxes described in this section. - -6.1. Attribute Type Description - - ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) - - Values in this syntax are encoded according to the BNF given at the - start of section 4.2. For example, - - ( 2.5.4.0 NAME 'objectClass' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - -6.2. Binary - - ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' ) - - Values in this syntax are encoded as described in section 4.3.1. - -6.3. Bit String - - ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) - - Values in this syntax are encoded according to the following BNF: - - bitstring = "'" *binary-digit "'B" - - binary-digit = "0" / "1" - - - - - -Wahl, et. al. Standards Track [Page 16] - -RFC 2252 LADPv3 Attributes December 1997 - - - Example: - - '0101111101'B - -6.4. Boolean - - ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) - - Values in this syntax are encoded according to the following BNF: - - boolean = "TRUE" / "FALSE" - - Boolean values have an encoding of "TRUE" if they are logically true, - and have an encoding of "FALSE" otherwise. - -6.5. Certificate - - ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) - - Because of the changes from X.509(1988) and X.509(1993) and - additional changes to the ASN.1 definition to support certificate - extensions, no string representation is defined, and values in this - syntax MUST only be transferred using the binary encoding, by - requesting or returning the attributes with descriptions - "userCertificate;binary" or "caCertificate;binary". The BNF notation - in RFC 1778 for "User Certificate" is not recommended to be used. - -6.6. Certificate List - - ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' ) - - Because of the incompatibility of the X.509(1988) and X.509(1993) - definitions of revocation lists, values in this syntax MUST only be - transferred using a binary encoding, by requesting or returning the - attributes with descriptions "certificateRevocationList;binary" or - "authorityRevocationList;binary". The BNF notation in RFC 1778 for - "Authority Revocation List" is not recommended to be used. - -6.7. Certificate Pair - - ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' ) - - Because the Certificate is being carried in binary, values in this - syntax MUST only be transferred using a binary encoding, by - requesting or returning the attribute description - "crossCertificatePair;binary". The BNF notation in RFC 1778 for - "Certificate Pair" is not recommended to be used. - - - - -Wahl, et. al. Standards Track [Page 17] - -RFC 2252 LADPv3 Attributes December 1997 - - -6.8. Country String - - ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) - - A value in this syntax is encoded the same as a value of Directory - String syntax. Note that this syntax is limited to values of exactly - two printable string characters, as listed in ISO 3166 [14]. - - CountryString = p p - - Example: - US - -6.9. DN - - ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) - - Values in the Distinguished Name syntax are encoded to have the - representation defined in [5]. Note that this representation is not - reversible to an ASN.1 encoding used in X.500 for Distinguished - Names, as the CHOICE of any DirectoryString element in an RDN is no - longer known. - - Examples (from [5]): - CN=Steve Kille,O=Isode Limited,C=GB - OU=Sales+CN=J. Smith,O=Widget Inc.,C=US - CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB - CN=Before\0DAfter,O=Test,C=GB - 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB - SN=Lu\C4\8Di\C4\87 - -6.10. Directory String - - ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) - - A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a - superset of Unicode). Servers and clients MUST be prepared to - receive encodings of arbitrary Unicode characters, including - characters not presently assigned to any character set. - - For characters in the PrintableString form, the value is encoded as - the string value itself. - - If it is of the TeletexString form, then the characters are - transliterated to their equivalents in UniversalString, and encoded - in UTF-8 [9]. - - - - - -Wahl, et. al. Standards Track [Page 18] - -RFC 2252 LADPv3 Attributes December 1997 - - - If it is of the UniversalString or BMPString forms [10], UTF-8 is - used to encode them. - - Note: the form of DirectoryString is not indicated in protocol unless - the attribute value is carried in binary. Servers which convert to - DAP MUST choose an appropriate form. Servers MUST NOT reject values - merely because they contain legal Unicode characters outside of the - range of printable ASCII. - - Example: - - This is a string of DirectoryString containing #!%#@ - -6.11. DIT Content Rule Description - - ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' ) - - Values in this syntax are encoded according to the following BNF. - Implementors should note that future versions of this document may - have expanded this BNF to include additional terms. - - - DITContentRuleDescription = "(" - numericoid ; Structural ObjectClass identifier - [ "NAME" qdescrs ] - [ "DESC" qdstring ] - [ "OBSOLETE" ] - [ "AUX" oids ] ; Auxiliary ObjectClasses - [ "MUST" oids ] ; AttributeType identifiers - [ "MAY" oids ] ; AttributeType identifiers - [ "NOT" oids ] ; AttributeType identifiers - ")" - -6.12. Facsimile Telephone Number - - - ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) - - Values in this syntax are encoded according to the following BNF: - - fax-number = printablestring [ "$" faxparameters ] - - faxparameters = faxparm / ( faxparm "$" faxparameters ) - - faxparm = "twoDimensional" / "fineResolution" / - "unlimitedLength" / - "b4Length" / "a3Width" / "b4Width" / "uncompressed" - - - - -Wahl, et. al. Standards Track [Page 19] - -RFC 2252 LADPv3 Attributes December 1997 - - - In the above, the first printablestring is the telephone number, - based on E.123 [15], and the faxparm tokens represent fax parameters. - -6.13. Fax - - ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) - - Values in this syntax are encoded as if they were octet strings - containing Group 3 Fax images as defined in [7]. - -6.14. Generalized Time - - ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) - - Values in this syntax are encoded as printable strings, represented - as specified in X.208. Note that the time zone must be specified. - It is strongly recommended that GMT time be used. For example, - - 199412161032Z - -6.15. IA5 String - - ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) - - The encoding of a value in this syntax is the string value itself. - -6.16. INTEGER - - ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) - - Values in this syntax are encoded as the decimal representation of - their values, with each decimal digit represented by the its - character equivalent. So the number 1321 is represented by the - character string "1321". - -6.17. JPEG - - ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) - - Values in this syntax are encoded as strings containing JPEG images - in the JPEG File Interchange Format (JFIF), as described in [8]. - -6.18. Matching Rule Description - - ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) - - Values of type matchingRules are encoded as strings according to the - BNF given in section 4.5. - - - -Wahl, et. al. Standards Track [Page 20] - -RFC 2252 LADPv3 Attributes December 1997 - - -6.19. Matching Rule Use Description - - ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' - ) - - Values of type matchingRuleUse are encoded as strings according to - the BNF given in section 4.5. - -6.20. MHS OR Address - - ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) - - Values in this syntax are encoded as strings, according to the format - defined in [11]. - -6.21. Name And Optional UID - - ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) - - Values in this syntax are encoded according to the following BNF: - - NameAndOptionalUID = DistinguishedName [ "#" bitstring ] - - Although the '#' character may occur in a string representation of a - distinguished name, no additional special quoting is done. This - syntax has been added subsequent to RFC 1778. - - Example: - - 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B - -6.22. Name Form Description - - ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) - - Values in this syntax are encoded according to the following BNF. - Implementors should note that future versions of this document may - have expanded this BNF to include additional terms. - - NameFormDescription = "(" whsp - numericoid whsp ; NameForm identifier - [ "NAME" qdescrs ] - [ "DESC" qdstring ] - [ "OBSOLETE" whsp ] - "OC" woid ; Structural ObjectClass - "MUST" oids ; AttributeTypes - [ "MAY" oids ] ; AttributeTypes - whsp ")" - - - -Wahl, et. al. Standards Track [Page 21] - -RFC 2252 LADPv3 Attributes December 1997 - - -6.23. Numeric String - - ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) - - The encoding of a string in this syntax is the string value itself. - Example: - - 1997 - -6.24. Object Class Description - - ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) - - Values in this syntax are encoded according to the BNF in section - 4.4. - -6.25. OID - - ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) - - Values in the Object Identifier syntax are encoded according to - the BNF in section 4.1 for "oid". - - Example: - - 1.2.3.4 - cn - -6.26. Other Mailbox - - ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) - - Values in this syntax are encoded according to the following BNF: - - otherMailbox = mailbox-type "$" mailbox - - mailbox-type = printablestring - - mailbox = <an encoded IA5 String> - - In the above, mailbox-type represents the type of mail system in - which the mailbox resides, for example "MCIMail"; and mailbox is the - actual mailbox in the mail system defined by mailbox-type. - -6.27. Postal Address - - ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) - - - - -Wahl, et. al. Standards Track [Page 22] - -RFC 2252 LADPv3 Attributes December 1997 - - - Values in this syntax are encoded according to the following BNF: - - postal-address = dstring *( "$" dstring ) - - In the above, each dstring component of a postal address value is - encoded as a value of type Directory String syntax. Backslashes and - dollar characters, if they occur in the component, are quoted as - described in section 4.3. Many servers limit the postal address to - six lines of up to thirty characters. - - Example: - - 1234 Main St.$Anytown, CA 12345$USA - \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA - -6.28. Presentation Address - - ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) - - Values in this syntax are encoded with the representation described - in RFC 1278 [6]. - -6.29. Printable String - - ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) - - The encoding of a value in this syntax is the string value itself. - PrintableString is limited to the characters in production p of - section 4.1. - - Example: - - This is a PrintableString - -6.30. Telephone Number - - ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) - - Values in this syntax are encoded as if they were Printable String - types. Telephone numbers are recommended in X.520 to be in - international form, as described in E.123 [15]. - - Example: - - +1 512 305 0280 - - - - - - -Wahl, et. al. Standards Track [Page 23] - -RFC 2252 LADPv3 Attributes December 1997 - - -6.31. UTC Time - - ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) - - Values in this syntax are encoded as if they were printable strings - with the strings containing a UTCTime value. This is historical; new - attribute definitions SHOULD use GeneralizedTime instead. - -6.32. LDAP Syntax Description - - ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) - - Values in this syntax are encoded according to the BNF in section - 4.3.3. - -6.33. DIT Structure Rule Description - - ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description' - ) - - Values with this syntax are encoded according to the following BNF: - - DITStructureRuleDescription = "(" whsp - ruleidentifier whsp ; DITStructureRule identifier - [ "NAME" qdescrs ] - [ "DESC" qdstring ] - [ "OBSOLETE" whsp ] - "FORM" woid whsp ; NameForm - [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules - ")" - - ruleidentifier = integer - - ruleidentifiers = ruleidentifier | - "(" whsp ruleidentifierlist whsp ")" - - ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ] - -7. Object Classes - - Servers SHOULD recognize all the names of standard classes from - section 7 of [12]. - -7.1. Extensible Object Class - - The extensibleObject object class, if present in an entry, permits - that entry to optionally hold any attribute. The MAY attribute list - of this class is implicitly the set of all attributes. - - - -Wahl, et. al. Standards Track [Page 24] - -RFC 2252 LADPv3 Attributes December 1997 - - - ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' - SUP top AUXILIARY ) - - The mandatory attributes of the other object classes of this entry - are still required to be present. - - Note that not all servers will implement this object class, and those - which do not will reject requests to add entries which contain this - object class, or modify an entry to add this object class. - -7.2. subschema - - This object class is used in the subschema entry. - - ( 2.5.20.1 NAME 'subschema' AUXILIARY - MAY ( dITStructureRules $ nameForms $ ditContentRules $ - objectClasses $ attributeTypes $ matchingRules $ - matchingRuleUse ) ) - - The ldapSyntaxes operational attribute may also be present in - subschema entries. - -8. Matching Rules - - Servers which implement the extensibleMatch filter SHOULD allow all - the matching rules listed in this section to be used in the - extensibleMatch. In general these servers SHOULD allow matching - rules to be used with all attribute types known to the server, when - the assertion syntax of the matching rule is the same as the value - syntax of the attribute. - - Servers MAY implement additional matching rules. - -8.1. Matching Rules used in Equality Filters - - Servers SHOULD be capable of performing the following matching rules. - - For all these rules, the assertion syntax is the same as the value - syntax. - - ( 2.5.13.0 NAME 'objectIdentifierMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - - If the client supplies a filter using an objectIdentifierMatch whose - matchValue oid is in the "descr" form, and the oid is not recognized - by the server, then the filter is Undefined. - - ( 2.5.13.1 NAME 'distinguishedNameMatch' - - - -Wahl, et. al. Standards Track [Page 25] - -RFC 2252 LADPv3 Attributes December 1997 - - - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) - - ( 2.5.13.2 NAME 'caseIgnoreMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - ( 2.5.13.8 NAME 'numericStringMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) - - ( 2.5.13.11 NAME 'caseIgnoreListMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) - - ( 2.5.13.14 NAME 'integerMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) - - ( 2.5.13.16 NAME 'bitStringMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) - - ( 2.5.13.20 NAME 'telephoneNumberMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) - - ( 2.5.13.22 NAME 'presentationAddressMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) - - ( 2.5.13.23 NAME 'uniqueMemberMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) - - ( 2.5.13.24 NAME 'protocolInformationMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) - - ( 2.5.13.27 NAME 'generalizedTimeMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) - - ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - - ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) - - When performing the caseIgnoreMatch, caseIgnoreListMatch, - telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, - multiple adjoining whitespace characters are treated the same as an - individual space, and leading and trailing whitespace is ignored. - - Clients MUST NOT assume that servers are capable of transliteration - of Unicode values. - - - - - - -Wahl, et. al. Standards Track [Page 26] - -RFC 2252 LADPv3 Attributes December 1997 - - -8.2. Matching Rules used in Inequality Filters - - Servers SHOULD be capable of performing the following matching rules, - which are used in greaterOrEqual and lessOrEqual filters. - - ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) - - ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - - The sort ordering for a caseIgnoreOrderingMatch is implementation- - dependent. - -8.3. Syntax and Matching Rules used in Substring Filters - - The Substring Assertion syntax is used only as the syntax of - assertion values in the extensible match. It is not used as the - syntax of attributes, or in the substring filter. - - ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) - - The Substring Assertion is encoded according to the following BNF: - - substring = [initial] any [final] - initial = value - any = "*" *(value "*") - final = value - - The <value> production is UTF-8 encoded string. Should the backslash - or asterix characters be present in a production of <value>, they are - quoted as described in section 4.3. - - Servers SHOULD be capable of performing the following matching rules, - which are used in substring filters. - - ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - ( 2.5.13.10 NAME 'numericStringSubstringsMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) - - - - - - - -Wahl, et. al. Standards Track [Page 27] - -RFC 2252 LADPv3 Attributes December 1997 - - -8.4. Matching Rules for Subschema Attributes - - Servers which allow subschema entries to be modified by clients MUST - support the following matching rules, as they are the equality - matching rules for several of the subschema attributes. - - ( 2.5.13.29 NAME 'integerFirstComponentMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) - - ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - - Implementors should note that the assertion syntax of these matching - rules, an INTEGER or OID, is different from the value syntax of - attributes for which this is the equality matching rule. - - If the client supplies an extensible filter using an - objectIdentifierFirstComponentMatch whose matchValue is in the - "descr" form, and the OID is not recognized by the server, then the - filter is Undefined. - -9. Security Considerations - -9.1. Disclosure - - Attributes of directory entries are used to provide descriptive - information about the real-world objects they represent, which can be - people, organizations or devices. Most countries have privacy laws - regarding the publication of information about people. - -9.2. Use of Attribute Values in Security Applications - - The transformations of an AttributeValue value from its X.501 form to - an LDAP string representation are not always reversible back to the - same BER or DER form. An example of a situation which requires the - DER form of a distinguished name is the verification of an X.509 - certificate. - - For example, a distinguished name consisting of one RDN with one AVA, - in which the type is commonName and the value is of the TeletexString - choice with the letters 'Sam' would be represented in LDAP as the - string CN=Sam. Another distinguished name in which the value is - still 'Sam' but of the PrintableString choice would have the same - representation CN=Sam. - - Applications which require the reconstruction of the DER form of the - value SHOULD NOT use the string representation of attribute syntaxes - when converting a value to LDAP format. Instead it SHOULD use the - - - -Wahl, et. al. Standards Track [Page 28] - -RFC 2252 LADPv3 Attributes December 1997 - - - Binary syntax. - -10. Acknowledgements - - This document is based substantially on RFC 1778, written by Tim - Howes, Steve Kille, Wengyik Yeong and Colin Robbins. - - Many of the attribute syntax encodings defined in this and related - documents are adapted from those used in the QUIPU and the IC R3 - X.500 implementations. The contributions of the authors of both these - implementations in the specification of syntaxes are gratefully - acknowledged. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wahl, et. al. Standards Track [Page 29] - -RFC 2252 LADPv3 Attributes December 1997 - - -11. Authors' Addresses - - Mark Wahl - Critical Angle Inc. - 4815 West Braker Lane #502-385 - Austin, TX 78759 - USA - - Phone: +1 512 372-3160 - EMail: M.Wahl@critical-angle.com - - Andy Coulbeck - Isode Inc. - 9390 Research Blvd Suite 305 - Austin, TX 78759 - USA - - Phone: +1 512 231-8993 - EMail: A.Coulbeck@isode.com - - Tim Howes - Netscape Communications Corp. - 501 E. Middlefield Rd, MS MV068 - Mountain View, CA 94043 - USA - - Phone: +1 650 937-3419 - EMail: howes@netscape.com - - Steve Kille - Isode Limited - The Dome, The Square - Richmond - TW9 1DT - UK - - Phone: +44-181-332-9091 - EMail: S.Kille@isode.com - - - - - - - - - - - - - -Wahl, et. al. Standards Track [Page 30] - -RFC 2252 LADPv3 Attributes December 1997 - - -12. Bibliography - - [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [2] The Directory: Selected Attribute Types. ITU-T Recommendation - X.520, 1993. - - [3] The Directory: Models. ITU-T Recommendation X.501, 1993. - - [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access - Protocol (v3): UTF-8 String Representation of - Distinguished Names", RFC 2253, December 1997. - - [6] Kille, S., "A String Representation for Presentation Addresses", - RFC 1278, November 1991. - - [7] Terminal Equipment and Protocols for Telematic Services - - Standardization of Group 3 facsimile apparatus for document - transmission. CCITT, Recommendation T.4. - - [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, - C-Cube Microsystems, Milpitas, CA, September 1, 1992. - - [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO - 10646", RFC 2044, October 1996. - - [10] Universal Multiple-Octet Coded Character Set (UCS) - - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : - 1993 (With amendments). - - [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 - and RFC 822", RFC 1327, May 1992. - - [12] Wahl, M., "A Summary of the X.500(96) User Schema for use - with LDAPv3", RFC 2256, December 1997. - - [13] Crocker, D., "Standard of the Format of ARPA-Internet Text - Messages", STD 11, RFC 822, August 1982. - - [14] ISO 3166, "Codes for the representation of names of countries". - - [15] ITU-T Rec. E.123, Notation for national and international - telephone numbers, 1988. - - - - -Wahl, et. al. Standards Track [Page 31] - -RFC 2252 LADPv3 Attributes December 1997 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Wahl, et. al. Standards Track [Page 32] - diff --git a/source4/ldap_server/devdocs/rfc2253.txt b/source4/ldap_server/devdocs/rfc2253.txt deleted file mode 100644 index a7439eed776..00000000000 --- a/source4/ldap_server/devdocs/rfc2253.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group M. Wahl -Request for Comments: 2253 Critical Angle Inc. -Obsoletes: 1779 S. Kille -Category: Standards Track Isode Ltd. - T. Howes - Netscape Communications Corp. - December 1997 - - - Lightweight Directory Access Protocol (v3): - UTF-8 String Representation of Distinguished Names - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -IESG Note - - This document describes a directory access protocol that provides - both read and update access. Update access requires secure - authentication, but this document does not mandate implementation of - any satisfactory authentication mechanisms. - - In accordance with RFC 2026, section 4.4.1, this specification is - being approved by IESG as a Proposed Standard despite this - limitation, for the following reasons: - - a. to encourage implementation and interoperability testing of - these protocols (with or without update access) before they - are deployed, and - - b. to encourage deployment and use of these protocols in read-only - applications. (e.g. applications where LDAPv3 is used as - a query language for directories which are updated by some - secure mechanism other than LDAP), and - - c. to avoid delaying the advancement and deployment of other Internet - standards-track protocols which require the ability to query, but - not update, LDAPv3 directory servers. - - - - -Wahl, et. al. Proposed Standard [Page 1] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - - Readers are hereby warned that until mandatory authentication - mechanisms are standardized, clients and servers written according to - this specification which make use of update functionality are - UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION - IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. - - Implementors are hereby discouraged from deploying LDAPv3 clients or - servers which implement the update functionality, until a Proposed - Standard for mandatory authentication in LDAPv3 has been approved and - published as an RFC. - -Abstract - - The X.500 Directory uses distinguished names as the primary keys to - entries in the directory. Distinguished Names are encoded in ASN.1 - in the X.500 Directory protocols. In the Lightweight Directory - Access Protocol, a string representation of distinguished names is - transferred. This specification defines the string format for - representing names, which is designed to give a clean representation - of commonly used distinguished names, while being able to represent - any distinguished name. - - 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 [6]. - -1. Background - - This specification assumes familiarity with X.500 [1], and the - concept of Distinguished Name. It is important to have a common - format to be able to unambiguously represent a distinguished name. - The primary goal of this specification is ease of encoding and - decoding. A secondary goal is to have names that are human readable. - It is not expected that LDAP clients with a human user interface - would display these strings directly to the user, but would most - likely be performing translations (such as expressing attribute type - names in one of the local national languages). - -2. Converting DistinguishedName from ASN.1 to a String - - In X.501 [2] the ASN.1 structure of distinguished name is defined as: - - DistinguishedName ::= RDNSequence - - RDNSequence ::= SEQUENCE OF RelativeDistinguishedName - - - - - - -Wahl, et. al. Proposed Standard [Page 2] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - - RelativeDistinguishedName ::= SET SIZE (1..MAX) OF - AttributeTypeAndValue - - AttributeTypeAndValue ::= SEQUENCE { - type AttributeType, - value AttributeValue } - - The following sections define the algorithm for converting from an - ASN.1 structured representation to a UTF-8 string representation. - -2.1. Converting the RDNSequence - - If the RDNSequence is an empty sequence, the result is the empty or - zero length string. - - Otherwise, the output consists of the string encodings of each - RelativeDistinguishedName in the RDNSequence (according to 2.2), - starting with the last element of the sequence and moving backwards - toward the first. - - The encodings of adjoining RelativeDistinguishedNames are separated - by a comma character (',' ASCII 44). - -2.2. Converting RelativeDistinguishedName - - When converting from an ASN.1 RelativeDistinguishedName to a string, - the output consists of the string encodings of each - AttributeTypeAndValue (according to 2.3), in any order. - - Where there is a multi-valued RDN, the outputs from adjoining - AttributeTypeAndValues are separated by a plus ('+' ASCII 43) - character. - -2.3. Converting AttributeTypeAndValue - - The AttributeTypeAndValue is encoded as the string representation of - the AttributeType, followed by an equals character ('=' ASCII 61), - followed by the string representation of the AttributeValue. The - encoding of the AttributeValue is given in section 2.4. - - If the AttributeType is in a published table of attribute types - associated with LDAP [4], then the type name string from that table - is used, otherwise it is encoded as the dotted-decimal encoding of - the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is - described in [3]. As an example, strings for a few of the attribute - types frequently seen in RDNs include: - - - - - -Wahl, et. al. Proposed Standard [Page 3] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - - String X.500 AttributeType - ------------------------------ - CN commonName - L localityName - ST stateOrProvinceName - O organizationName - OU organizationalUnitName - C countryName - STREET streetAddress - DC domainComponent - UID userid - -2.4. Converting an AttributeValue from ASN.1 to a String - - If the AttributeValue is of a type which does not have a string - representation defined for it, then it is simply encoded as an - octothorpe character ('#' ASCII 35) followed by the hexadecimal - representation of each of the bytes of the BER encoding of the X.500 - AttributeValue. This form SHOULD be used if the AttributeType is of - the dotted-decimal form. - - Otherwise, if the AttributeValue is of a type which has a string - representation, the value is converted first to a UTF-8 string - according to its syntax specification (see for example section 6 of - [4]). - - If the UTF-8 string does not have any of the following characters - which need escaping, then that string can be used as the string - representation of the value. - - o a space or "#" character occurring at the beginning of the - string - - o a space character occurring at the end of the string - - o one of the characters ",", "+", """, "\", "<", ">" or ";" - - Implementations MAY escape other characters. - - If a character to be escaped is one of the list shown above, then it - is prefixed by a backslash ('\' ASCII 92). - - Otherwise the character to be escaped is replaced by a backslash and - two hex digits, which form a single byte in the code of the - character. - - Examples of the escaping mechanism are shown in section 5. - - - - -Wahl, et. al. Proposed Standard [Page 4] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - -3. Parsing a String back to a Distinguished Name - - The structure of the string is specified in a BNF grammar, based on - the grammar defined in RFC 822 [5]. Server implementations parsing a - DN string generated by an LDAPv2 client MUST also accept (and ignore) - the variants given in section 4 of this document. - -distinguishedName = [name] ; may be empty string - -name = name-component *("," name-component) - -name-component = attributeTypeAndValue *("+" attributeTypeAndValue) - -attributeTypeAndValue = attributeType "=" attributeValue - -attributeType = (ALPHA 1*keychar) / oid -keychar = ALPHA / DIGIT / "-" - -oid = 1*DIGIT *("." 1*DIGIT) - -attributeValue = string - -string = *( stringchar / pair ) - / "#" hexstring - / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2 - -quotechar = <any character except "\" or QUOTATION > - -special = "," / "=" / "+" / "<" / ">" / "#" / ";" - -pair = "\" ( special / "\" / QUOTATION / hexpair ) -stringchar = <any character except one of special, "\" or QUOTATION > - -hexstring = 1*hexpair -hexpair = hexchar hexchar - -hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" - / "a" / "b" / "c" / "d" / "e" / "f" - -ALPHA = <any ASCII alphabetic character> - ; (decimal 65-90 and 97-122) -DIGIT = <any ASCII decimal digit> ; (decimal 48-57) -QUOTATION = <the ASCII double quotation mark character '"' decimal 34> - - - - - - - - -Wahl, et. al. Proposed Standard [Page 5] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - -4. Relationship with RFC 1779 and LDAPv2 - - The syntax given in this document is more restrictive than the syntax - in RFC 1779. Implementations parsing a string generated by an LDAPv2 - client MUST accept the syntax of RFC 1779. Implementations MUST NOT, - however, generate any of the RFC 1779 encodings which are not - described above in section 2. - - Implementations MUST allow a semicolon character to be used instead - of a comma to separate RDNs in a distinguished name, and MUST also - allow whitespace characters to be present on either side of the comma - or semicolon. The whitespace characters are ignored, and the - semicolon replaced with a comma. - - Implementations MUST allow an oid in the attribute type to be - prefixed by one of the character strings "oid." or "OID.". - - Implementations MUST allow for space (' ' ASCII 32) characters to be - present between name-component and ',', between attributeTypeAndValue - and '+', between attributeType and '=', and between '=' and - attributeValue. These space characters are ignored when parsing. - - Implementations MUST allow a value to be surrounded by quote ('"' - ASCII 34) characters, which are not part of the value. Inside the - quoted value, the following characters can occur without any - escaping: - - ",", "=", "+", "<", ">", "#" and ";" - -5. Examples - - This notation is designed to be convenient for common forms of name. - This section gives a few examples of distinguished names written - using this notation. First is a name containing three relative - distinguished names (RDNs): - - CN=Steve Kille,O=Isode Limited,C=GB - - Here is an example name containing three RDNs, in which the first RDN - is multi-valued: - - OU=Sales+CN=J. Smith,O=Widget Inc.,C=US - - This example shows the method of quoting of a comma in an - organization name: - - CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB - - - - -Wahl, et. al. Proposed Standard [Page 6] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - - An example name in which a value contains a carriage return - character: - - CN=Before\0DAfter,O=Test,C=GB - - An example name in which an RDN was of an unrecognized type. The - value is the BER encoding of an OCTET STRING containing two bytes - 0x48 and 0x69. - - 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB - - Finally, an example of an RDN surname value consisting of 5 letters: - - Unicode Letter Description 10646 code UTF-8 Quoted - =============================== ========== ====== ======= - LATIN CAPITAL LETTER L U0000004C 0x4C L - LATIN SMALL LETTER U U00000075 0x75 u - LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D - LATIN SMALL LETTER I U00000069 0x69 i - LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87 - - Could be written in printable ASCII (useful for debugging purposes): - - SN=Lu\C4\8Di\C4\87 - -6. References - - [1] The Directory -- overview of concepts, models and services. - ITU-T Rec. X.500(1993). - - [2] The Directory -- Models. ITU-T Rec. X.501(1993). - - [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", - RFC 2252, December 1997. - - [5] Crocker, D., "Standard of the Format of ARPA-Internet Text - Messages", STD 11, RFC 822, August 1982. - - [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119. - - - - - - - -Wahl, et. al. Proposed Standard [Page 7] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - -7. Security Considerations - -7.1. Disclosure - - Distinguished Names typically consist of descriptive information - about the entries they name, which can be people, organizations, - devices or other real-world objects. This frequently includes some - of the following kinds of information: - - - the common name of the object (i.e. a person's full name) - - an email or TCP/IP address - - its physical location (country, locality, city, street address) - - organizational attributes (such as department name or affiliation) - - Most countries have privacy laws regarding the publication of - information about people. - -7.2. Use of Distinguished Names in Security Applications - - The transformations of an AttributeValue value from its X.501 form to - an LDAP string representation are not always reversible back to the - same BER or DER form. An example of a situation which requires the - DER form of a distinguished name is the verification of an X.509 - certificate. - - For example, a distinguished name consisting of one RDN with one AVA, - in which the type is commonName and the value is of the TeletexString - choice with the letters 'Sam' would be represented in LDAP as the - string CN=Sam. Another distinguished name in which the value is - still 'Sam' but of the PrintableString choice would have the same - representation CN=Sam. - - Applications which require the reconstruction of the DER form of the - value SHOULD NOT use the string representation of attribute syntaxes - when converting a distinguished name to the LDAP format. Instead, - they SHOULD use the hexadecimal form prefixed by the octothorpe ('#') - as described in the first paragraph of section 2.4. - -8. Authors' Addresses - - Mark Wahl - Critical Angle Inc. - 4815 W. Braker Lane #502-385 - Austin, TX 78759 - USA - - EMail: M.Wahl@critical-angle.com - - - - -Wahl, et. al. Proposed Standard [Page 8] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - - Steve Kille - Isode Ltd. - The Dome - The Square - Richmond, Surrey - TW9 1DT - England - - Phone: +44-181-332-9091 - EMail: S.Kille@ISODE.COM - - - Tim Howes - Netscape Communications Corp. - 501 E. Middlefield Rd, MS MV068 - Mountain View, CA 94043 - USA - - Phone: +1 650 937-3419 - EMail: howes@netscape.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wahl, et. al. Proposed Standard [Page 9] - -RFC 2253 LADPv3 Distinguished Names December 1997 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Wahl, et. al. Proposed Standard [Page 10] - diff --git a/source4/ldap_server/devdocs/rfc2254.txt b/source4/ldap_server/devdocs/rfc2254.txt deleted file mode 100644 index 323fdb00b7c..00000000000 --- a/source4/ldap_server/devdocs/rfc2254.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group T. Howes -Request for Comments: 2254 Netscape Communications Corp. -Category: Standards Track December 1997 - - - The String Representation of LDAP Search Filters - -1. Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -IESG Note - - This document describes a directory access protocol that provides - both read and update access. Update access requires secure - authentication, but this document does not mandate implementation of - any satisfactory authentication mechanisms. - - In accordance with RFC 2026, section 4.4.1, this specification is - being approved by IESG as a Proposed Standard despite this - limitation, for the following reasons: - - a. to encourage implementation and interoperability testing of - these protocols (with or without update access) before they - are deployed, and - - b. to encourage deployment and use of these protocols in read-only - applications. (e.g. applications where LDAPv3 is used as - a query language for directories which are updated by some - secure mechanism other than LDAP), and - - c. to avoid delaying the advancement and deployment of other Internet - standards-track protocols which require the ability to query, but - not update, LDAPv3 directory servers. - - - - - - - - - -Howes Standards Track [Page 1] - -RFC 2254 String Representation of LDAP December 1997 - - - Readers are hereby warned that until mandatory authentication - mechanisms are standardized, clients and servers written according to - this specification which make use of update functionality are - UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION - IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. - - Implementors are hereby discouraged from deploying LDAPv3 clients or - servers which implement the update functionality, until a Proposed - Standard for mandatory authentication in LDAPv3 has been approved and - published as an RFC. - -2. Abstract - - The Lightweight Directory Access Protocol (LDAP) [1] defines a - network representation of a search filter transmitted to an LDAP - server. Some applications may find it useful to have a common way of - representing these search filters in a human-readable form. This - document defines a human-readable string format for representing LDAP - search filters. - - This document replaces RFC 1960, extending the string LDAP filter - definition to include support for LDAP version 3 extended match - filters, and including support for representing the full range of - possible LDAP search filters. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Howes Standards Track [Page 2] - -RFC 2254 String Representation of LDAP December 1997 - - -3. LDAP Search Filter Definition - - An LDAPv3 search filter is defined in Section 4.5.1 of [1] as - follows: - - Filter ::= CHOICE { - and [0] SET OF Filter, - or [1] SET OF Filter, - not [2] Filter, - equalityMatch [3] AttributeValueAssertion, - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeDescription, - approxMatch [8] AttributeValueAssertion, - extensibleMatch [9] MatchingRuleAssertion - } - - SubstringFilter ::= SEQUENCE { - type AttributeDescription, - SEQUENCE OF CHOICE { - initial [0] LDAPString, - any [1] LDAPString, - final [2] LDAPString - } - } - - AttributeValueAssertion ::= SEQUENCE { - attributeDesc AttributeDescription, - attributeValue AttributeValue - } - - MatchingRuleAssertion ::= SEQUENCE { - matchingRule [1] MatchingRuleID OPTIONAL, - type [2] AttributeDescription OPTIONAL, - matchValue [3] AssertionValue, - dnAttributes [4] BOOLEAN DEFAULT FALSE - } - - AttributeDescription ::= LDAPString - - AttributeValue ::= OCTET STRING - - MatchingRuleID ::= LDAPString - - AssertionValue ::= OCTET STRING - - LDAPString ::= OCTET STRING - - - -Howes Standards Track [Page 3] - -RFC 2254 String Representation of LDAP December 1997 - - - where the LDAPString above is limited to the UTF-8 encoding of the - ISO 10646 character set [4]. The AttributeDescription is a string - representation of the attribute description and is defined in [1]. - The AttributeValue and AssertionValue OCTET STRING have the form - defined in [2]. The Filter is encoded for transmission over a - network using the Basic Encoding Rules defined in [3], with - simplifications described in [1]. - -4. String Search Filter Definition - - The string representation of an LDAP search filter is defined by the - following grammar, following the ABNF notation defined in [5]. The - filter format uses a prefix notation. - - filter = "(" filtercomp ")" - filtercomp = and / or / not / item - and = "&" filterlist - or = "|" filterlist - not = "!" filter - filterlist = 1*filter - item = simple / present / substring / extensible - simple = attr filtertype value - filtertype = equal / approx / greater / less - equal = "=" - approx = "~=" - greater = ">=" - less = "<=" - extensible = attr [":dn"] [":" matchingrule] ":=" value - / [":dn"] ":" matchingrule ":=" value - present = attr "=*" - substring = attr "=" [initial] any [final] - initial = value - any = "*" *(value "*") - final = value - attr = AttributeDescription from Section 4.1.5 of [1] - matchingrule = MatchingRuleId from Section 4.1.9 of [1] - value = AttributeValue from Section 4.1.6 of [1] - - The attr, matchingrule, and value constructs are as described in the - corresponding section of [1] given above. - - - - - - - - - - - -Howes Standards Track [Page 4] - -RFC 2254 String Representation of LDAP December 1997 - - - If a value should contain any of the following characters - - Character ASCII value - --------------------------- - * 0x2a - ( 0x28 - ) 0x29 - \ 0x5c - NUL 0x00 - - the character must be encoded as the backslash '\' character (ASCII - 0x5c) followed by the two hexadecimal digits representing the ASCII - value of the encoded character. The case of the two hexadecimal - digits is not significant. - - This simple escaping mechanism eliminates filter-parsing ambiguities - and allows any filter that can be represented in LDAP to be - represented as a NUL-terminated string. Other characters besides the - ones listed above may be escaped using this mechanism, for example, - non-printing characters. - - For example, the filter checking whether the "cn" attribute contained - a value with the character "*" anywhere in it would be represented as - "(cn=*\2a*)". - - Note that although both the substring and present productions in the - grammar above can produce the "attr=*" construct, this construct is - used only to denote a presence filter. - -5. Examples - - This section gives a few examples of search filters written using - this notation. - - (cn=Babs Jensen) - (!(cn=Tim Howes)) - (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) - (o=univ*of*mich*) - - The following examples illustrate the use of extensible matching. - - (cn:1.2.3.4.5:=Fred Flintstone) - (sn:dn:2.4.6.8.10:=Barney Rubble) - (o:dn:=Ace Industry) - (:dn:2.4.6.8.10:=Dino) - - - - - - -Howes Standards Track [Page 5] - -RFC 2254 String Representation of LDAP December 1997 - - - The second example illustrates the use of the ":dn" notation to - indicate that matching rule "2.4.6.8.10" should be used when making - comparisons, and that the attributes of an entry's distinguished name - should be considered part of the entry when evaluating the match. - - The third example denotes an equality match, except that DN - components should be considered part of the entry when doing the - match. - - The fourth example is a filter that should be applied to any - attribute supporting the matching rule given (since the attr has been - left off). Attributes supporting the matching rule contained in the - DN should also be considered. - - The following examples illustrate the use of the escaping mechanism. - - (o=Parens R Us \28for all your parenthetical needs\29) - (cn=*\2A*) - (filename=C:\5cMyFile) - (bin=\00\00\00\04) - (sn=Lu\c4\8di\c4\87) - - The first example shows the use of the escaping mechanism to - represent parenthesis characters. The second shows how to represent a - "*" in a value, preventing it from being interpreted as a substring - indicator. The third illustrates the escaping of the backslash - character. - - The fourth example shows a filter searching for the four-byte value - 0x00000004, illustrating the use of the escaping mechanism to - represent arbitrary data, including NUL characters. - - The final example illustrates the use of the escaping mechanism to - represent various non-ASCII UTF-8 characters. - -6. Security Considerations - - This memo describes a string representation of LDAP search filters. - While the representation itself has no known security implications, - LDAP search filters do. They are interpreted by LDAP servers to - select entries from which data is retrieved. LDAP servers should - take care to protect the data they maintain from unauthorized access. - - - - - - - - - -Howes Standards Track [Page 6] - -RFC 2254 String Representation of LDAP December 1997 - - -7. References - - [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", RFC - 2252, December 1997. - - [3] Specification of ASN.1 encoding rules: Basic, Canonical, and - Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994. - - [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO - 10646", RFC 2044, October 1996. - - [5] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, August 1982. - -8. Author's Address - - Tim Howes - Netscape Communications Corp. - 501 E. Middlefield Road - Mountain View, CA 94043 - USA - - Phone: +1 415 937-3419 - EMail: howes@netscape.com - - - - - - - - - - - - - - - - - - - - - - - -Howes Standards Track [Page 7] - -RFC 2254 String Representation of LDAP December 1997 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Howes Standards Track [Page 8] - diff --git a/source4/ldap_server/devdocs/rfc2255.txt b/source4/ldap_server/devdocs/rfc2255.txt deleted file mode 100644 index a03567154e5..00000000000 --- a/source4/ldap_server/devdocs/rfc2255.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group T. Howes -Request for Comments: 2255 M. Smith -Category: Standards Track Netscape Communications Corp. - December 1997 - - - The LDAP URL Format - -1. Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -IESG NOTE - - This document describes a directory access protocol that provides - both read and update access. Update access requires secure - authentication, but this document does not mandate implementation of - any satisfactory authentication mechanisms. - - In accordance with RFC 2026, section 4.4.1, this specification is - being approved by IESG as a Proposed Standard despite this - limitation, for the following reasons: - - a. to encourage implementation and interoperability testing of - these protocols (with or without update access) before they - are deployed, and - - b. to encourage deployment and use of these protocols in read-only - applications. (e.g. applications where LDAPv3 is used as - a query language for directories which are updated by some - secure mechanism other than LDAP), and - - c. to avoid delaying the advancement and deployment of other Internet - standards-track protocols which require the ability to query, but - not update, LDAPv3 directory servers. - - - - - - - - -Howes & Smith Standards Track [Page 1] - -RFC 2255 LDAP URL Format December 1997 - - - Readers are hereby warned that until mandatory authentication - mechanisms are standardized, clients and servers written according to - this specification which make use of update functionality are - UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION - IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. - - Implementors are hereby discouraged from deploying LDAPv3 clients or - servers which implement the update functionality, until a Proposed - Standard for mandatory authentication in LDAPv3 has been approved and - published as an RFC. - -2. Abstract - - LDAP is the Lightweight Directory Access Protocol, defined in [1], - [2] and [3]. This document describes a format for an LDAP Uniform - Resource Locator. The format describes an LDAP search operation to - perform to retrieve information from an LDAP directory. This document - replaces RFC 1959. It updates the LDAP URL format for version 3 of - LDAP and clarifies how LDAP URLs are resolved. This document also - defines an extension mechanism for LDAP URLs, so that future - documents can extend their functionality, for example, to provide - access to new LDAPv3 extensions as they are defined. - - The key words "MUST", "MAY", and "SHOULD" used in this document are - to be interpreted as described in [6]. - - - - - - - - - - - - - - - - - - - - - - - - - - -Howes & Smith Standards Track [Page 2] - -RFC 2255 LDAP URL Format December 1997 - - -3. URL Definition - - An LDAP URL begins with the protocol prefix "ldap" and is defined by - the following grammar. - - ldapurl = scheme "://" [hostport] ["/" - [dn ["?" [attributes] ["?" [scope] - ["?" [filter] ["?" extensions]]]]]] - scheme = "ldap" - attributes = attrdesc *("," attrdesc) - scope = "base" / "one" / "sub" - dn = distinguishedName from Section 3 of [1] - hostport = hostport from Section 5 of RFC 1738 [5] - attrdesc = AttributeDescription from Section 4.1.5 of [2] - filter = filter from Section 4 of [4] - extensions = extension *("," extension) - extension = ["!"] extype ["=" exvalue] - extype = token / xtoken - exvalue = LDAPString from section 4.1.2 of [2] - token = oid from section 4.1 of [3] - xtoken = ("X-" / "x-") token - - The "ldap" prefix indicates an entry or entries residing in the LDAP - server running on the given hostname at the given portnumber. The - default LDAP port is TCP port 389. If no hostport is given, the - client must have some apriori knowledge of an appropriate LDAP server - to contact. - - The dn is an LDAP Distinguished Name using the string format - described in [1]. It identifies the base object of the LDAP search. - - ldapurl = scheme "://" [hostport] ["/" - [dn ["?" [attributes] ["?" [scope] - ["?" [filter] ["?" extensions]]]]]] - scheme = "ldap" - attributes = attrdesc *("," attrdesc) - scope = "base" / "one" / "sub" - dn = distinguishedName from Section 3 of [1] - hostport = hostport from Section 5 of RFC 1738 [5] - attrdesc = AttributeDescription from Section 4.1.5 of [2] - filter = filter from Section 4 of [4] - extensions = extension *("," extension) - extension = ["!"] extype ["=" exvalue] - extype = token / xtoken - exvalue = LDAPString from section 4.1.2 of [2] - token = oid from section 4.1 of [3] - xtoken = ("X-" / "x-") token - - - - -Howes & Smith Standards Track [Page 3] - -RFC 2255 LDAP URL Format December 1997 - - - The "ldap" prefix indicates an entry or entries residing in the LDAP - server running on the given hostname at the given portnumber. The - default LDAP port is TCP port 389. If no hostport is given, the - client must have some apriori knowledge of an appropriate LDAP server - to contact. - - The dn is an LDAP Distinguished Name using the string format - described in [1]. It identifies the base object of the LDAP search. - - The attributes construct is used to indicate which attributes should - be returned from the entry or entries. Individual attrdesc names are - as defined for AttributeDescription in [2]. If the attributes part - is omitted, all user attributes of the entry or entries should be - requested (e.g., by setting the attributes field - AttributeDescriptionList in the LDAP search request to a NULL list, - or (in LDAPv3) by requesting the special attribute name "*"). - - The scope construct is used to specify the scope of the search to - perform in the given LDAP server. The allowable scopes are "base" - for a base object search, "one" for a one-level search, or "sub" for - a subtree search. If scope is omitted, a scope of "base" is assumed. - - The filter is used to specify the search filter to apply to entries - within the specified scope during the search. It has the format - specified in [4]. If filter is omitted, a filter of - "(objectClass=*)" is assumed. - - The extensions construct provides the LDAP URL with an extensibility - mechanism, allowing the capabilities of the URL to be extended in the - future. Extensions are a simple comma-separated list of type=value - pairs, where the =value portion MAY be omitted for options not - requiring it. Each type=value pair is a separate extension. These - LDAP URL extensions are not necessarily related to any of the LDAPv3 - extension mechanisms. Extensions may be supported or unsupported by - the client resolving the URL. An extension prefixed with a '!' - character (ASCII 33) is critical. An extension not prefixed with a ' - !' character is non-critical. - - If an extension is supported by the client, the client MUST obey the - extension if the extension is critical. The client SHOULD obey - supported extensions that are non-critical. - - If an extension is unsupported by the client, the client MUST NOT - process the URL if the extension is critical. If an unsupported - extension is non-critical, the client MUST ignore the extension. - - - - - - -Howes & Smith Standards Track [Page 4] - -RFC 2255 LDAP URL Format December 1997 - - - If a critical extension cannot be processed successfully by the - client, the client MUST NOT process the URL. If a non-critical - extension cannot be processed successfully by the client, the client - SHOULD ignore the extension. - - Extension types prefixed by "X-" or "x-" are reserved for use in - bilateral agreements between communicating parties. Other extension - types MUST be defined in this document, or in other standards-track - documents. - - One LDAP URL extension is defined in this document in the next - section. Other documents or a future version of this document MAY - define other extensions. - - Note that any URL-illegal characters (e.g., spaces), URL special - characters (as defined in section 2.2 of RFC 1738) and the reserved - character '?' (ASCII 63) occurring inside a dn, filter, or other - element of an LDAP URL MUST be escaped using the % method described - in RFC 1738 [5]. If a comma character ',' occurs inside an extension - value, the character MUST also be escaped using the % method. - -4. The Bindname Extension - - This section defines an LDAP URL extension for representing the - distinguished name for a client to use when authenticating to an LDAP - directory during resolution of an LDAP URL. Clients MAY implement - this extension. - - The extension type is "bindname". The extension value is the - distinguished name of the directory entry to authenticate as, in the - same form as described for dn in the grammar above. The dn may be the - NULL string to specify unauthenticated access. The extension may be - either critical (prefixed with a '!' character) or non-critical (not - prefixed with a '!' character). - - If the bindname extension is critical, the client resolving the URL - MUST authenticate to the directory using the given distinguished name - and an appropriate authentication method. Note that for a NULL - distinguished name, no bind MAY be required to obtain anonymous - access to the directory. If the extension is non-critical, the client - MAY bind to the directory using the given distinguished name. - -5. URL Processing - - This section describes how an LDAP URL SHOULD be resolved by a - client. - - - - - -Howes & Smith Standards Track [Page 5] - -RFC 2255 LDAP URL Format December 1997 - - - First, the client obtains a connection to the LDAP server referenced - in the URL, or an LDAP server of the client's choice if no LDAP - server is explicitly referenced. This connection MAY be opened - specifically for the purpose of resolving the URL or the client MAY - reuse an already open connection. The connection MAY provide - confidentiality, integrity, or other services, e.g., using TLS. Use - of security services is at the client's discretion if not specified - in the URL. - - Next, the client authenticates itself to the LDAP server. This step - is optional, unless the URL contains a critical bindname extension - with a non-NULL value. If a bindname extension is given, the client - proceeds according to the section above. - - If a bindname extension is not specified, the client MAY bind to the - directory using a appropriate dn and authentication method of its own - choosing (including NULL authentication). - - Next, the client performs the LDAP search operation specified in the - URL. Additional fields in the LDAP protocol search request, such as - sizelimit, timelimit, deref, and anything else not specified or - defaulted in the URL specification, MAY be set at the client's - discretion. - - Once the search has completed, the client MAY close the connection to - the LDAP server, or the client MAY keep the connection open for - future use. - -6. Examples - - The following are some example LDAP URLs using the format defined - above. The first example is an LDAP URL referring to the University - of Michigan entry, available from an LDAP server of the client's - choosing: - - ldap:///o=University%20of%20Michigan,c=US - - The next example is an LDAP URL referring to the University of - Michigan entry in a particular ldap server: - - ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US - - Both of these URLs correspond to a base object search of the - "o=University of Michigan, c=US" entry using a filter of - "(objectclass=*)", requesting all attributes. - - The next example is an LDAP URL referring to only the postalAddress - attribute of the University of Michigan entry: - - - -Howes & Smith Standards Track [Page 6] - -RFC 2255 LDAP URL Format December 1997 - - - ldap://ldap.itd.umich.edu/o=University%20of%20Michigan, - c=US?postalAddress - - The corresponding LDAP search operation is the same as in the - previous example, except that only the postalAddress attribute is - requested. - - The next example is an LDAP URL referring to the set of entries found - by querying the given LDAP server on port 6666 and doing a subtree - search of the University of Michigan for any entry with a common name - of "Babs Jensen", retrieving all attributes: - - ldap://host.com:6666/o=University%20of%20Michigan, - c=US??sub?(cn=Babs%20Jensen) - - The next example is an LDAP URL referring to all children of the c=GB - entry: - - ldap://ldap.itd.umich.edu/c=GB?objectClass?one - - The objectClass attribute is requested to be returned along with the - entries, and the default filter of "(objectclass=*)" is used. - - The next example is an LDAP URL to retrieve the mail attribute for - the LDAP entry named "o=Question?,c=US" is given below, illustrating - the use of the escaping mechanism on the reserved character '?'. - - ldap://ldap.question.com/o=Question%3f,c=US?mail - - The next example illustrates the interaction between LDAP and URL - quoting mechanisms. - - ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04) - - The filter in this example uses the LDAP escaping mechanism of \ to - encode three zero or null bytes in the value. In LDAP, the filter - would be written as (int=\00\00\00\04). Because the \ character must - be escaped in a URL, the \'s are escaped as %5c in the URL encoding. - - The final example shows the use of the bindname extension to specify - the dn a client should use for authentication when resolving the URL. - - ldap:///??sub??bindname=cn=Manager%2co=Foo - ldap:///??sub??!bindname=cn=Manager%2co=Foo - - The two URLs are the same, except that the second one marks the - bindname extension as critical. Notice the use of the % encoding - method to encode the comma in the distinguished name value in the - - - -Howes & Smith Standards Track [Page 7] - -RFC 2255 LDAP URL Format December 1997 - - - bindname extension. - -7. Security Considerations - - General URL security considerations discussed in [5] are relevant for - LDAP URLs. - - The use of security mechanisms when processing LDAP URLs requires - particular care, since clients may encounter many different servers - via URLs, and since URLs are likely to be processed automatically, - without user intervention. A client SHOULD have a user-configurable - policy about which servers to connect to using which security - mechanisms, and SHOULD NOT make connections that are inconsistent - with this policy. - - Sending authentication information, no matter the mechanism, may - violate a user's privacy requirements. In the absence of specific - policy permitting authentication information to be sent to a server, - a client should use an anonymous connection. (Note that clients - conforming to previous LDAP URL specifications, where all connections - are anonymous and unprotected, are consistent with this - specification; they simply have the default security policy.) - - Some authentication methods, in particular reusable passwords sent to - the server, may reveal easily-abused information to the remote server - or to eavesdroppers in transit, and should not be used in URL - processing unless explicitly permitted by policy. Confirmation by - the human user of the use of authentication information is - appropriate in many circumstances. Use of strong authentication - methods that do not reveal sensitive information is much preferred. - - The LDAP URL format allows the specification of an arbitrary LDAP - search operation to be performed when evaluating the LDAP URL. - Following an LDAP URL may cause unexpected results, for example, the - retrieval of large amounts of data, the initiation of a long-lived - search, etc. The security implications of resolving an LDAP URL are - the same as those of resolving an LDAP search query. - -8. Acknowledgements - - The LDAP URL format was originally defined at the University of - Michigan. This material is based upon work supported by the National - Science Foundation under Grant No. NCR-9416667. The support of both - the University of Michigan and the National Science Foundation is - gratefully acknowledged. - - - - - - -Howes & Smith Standards Track [Page 8] - -RFC 2255 LDAP URL Format December 1997 - - - Several people have made valuable comments on this document. In - particular RL "Bob" Morgan and Mark Wahl deserve special thanks for - their contributions. - -9. References - - [1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access - Protocol (v3): UTF-8 String Representation of Distinguished Names", - RFC 2253, December 1997. - - [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", RFC - 2252, December 1997. - - [4] Howes, T., "A String Representation of LDAP Search Filters", RFC - 2254, December 1997. - - [5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource - Locators (URL)," RFC 1738, December 1994. - - [6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement - Levels," RFC 2119, March 1997. - -Authors' Addresses - - Tim Howes - Netscape Communications Corp. - 501 E. Middlefield Rd. - Mountain View, CA 94043 - USA - - Phone: +1 415 937-3419 - EMail: howes@netscape.com - - - Mark Smith - Netscape Communications Corp. - 501 E. Middlefield Rd. - Mountain View, CA 94043 - USA - - Phone: +1 415 937-3477 - EMail: mcs@netscape.com - - - - - -Howes & Smith Standards Track [Page 9] - -RFC 2255 LDAP URL Format December 1997 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Howes & Smith Standards Track [Page 10] - diff --git a/source4/ldap_server/devdocs/rfc2256.txt b/source4/ldap_server/devdocs/rfc2256.txt deleted file mode 100644 index 69706f65a69..00000000000 --- a/source4/ldap_server/devdocs/rfc2256.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -Network Working Group M. Wahl -Request for Comments: 2256 Critical Angle Inc. -Category: Standards Track December 1997 - - - A Summary of the X.500(96) User Schema for use with LDAPv3 - -1. Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -IESG Note - - This document describes a directory access protocol that provides - both read and update access. Update access requires secure - authentication, but this document does not mandate implementation of - any satisfactory authentication mechanisms. - - In accordance with RFC 2026, section 4.4.1, this specification is - being approved by IESG as a Proposed Standard despite this - limitation, for the following reasons: - - a. to encourage implementation and interoperability testing of - these protocols (with or without update access) before they - are deployed, and - - b. to encourage deployment and use of these protocols in read-only - applications. (e.g. applications where LDAPv3 is used as - a query language for directories which are updated by some - secure mechanism other than LDAP), and - - c. to avoid delaying the advancement and deployment of other Internet - standards-track protocols which require the ability to query, but - not update, LDAPv3 directory servers. - - Readers are hereby warned that until mandatory authentication - mechanisms are standardized, clients and servers written according to - this specification which make use of update functionality are - UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION - IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. - - - -Wahl Standards Track [Page 1] - -RFC 2256 LDAPv3 Schema December 1997 - - - Implementors are hereby discouraged from deploying LDAPv3 clients or - servers which implement the update functionality, until a Proposed - Standard for mandatory authentication in LDAPv3 has been approved and - published as an RFC. - -2. Abstract - - This document provides an overview of the attribute types and object - classes defined by the ISO and ITU-T committees in the X.500 - documents, in particular those intended for use by directory clients. - This is the most widely used schema for LDAP/X.500 directories, and - many other schema definitions for white pages objects use it as a - basis. This document does not cover attributes used for the - administration of X.500 directory servers, nor does it include - attributes defined by other ISO/ITU-T documents. - - 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 [6]. - -3. General Issues - - This document references syntaxes given in section 6 of this document - and section 6 of [1]. Matching rules are listed in section 8 of this - document and section 8 of [1]. - - The attribute type and object class definitions are written using the - BNF form of AttributeTypeDescription and ObjectClassDescription given - in [1]. Lines have been folded for readability. - -4. Source - - The schema definitions in this document are based on those found in - X.500 [2],[3],[4],[5], and updates to these documents, specifically: - - Sections Source - ============ ============ - 5.1 - 5.2 X.501(93) - 5.3 - 5.36 X.520(88) - 5.37 - 5.41 X.509(93) - 5.42 - 5.52 X.520(93) - 5.53 - 5.54 X.509(96) - 5.55 X.520(96) - 6.1 RFC 1274 - 6.2 (new syntax) - 6.3 - 6.6 RFC 1274 - 7.1 - 7.2 X.501(93) - 7.3 - 7.18 X.521(93) - - - -Wahl Standards Track [Page 2] - -RFC 2256 LDAPv3 Schema December 1997 - - - 7.19 - 7.21 X.509(96) - 7.22 X.521(96) - - Some attribute names are different from those found in X.520(93). - - Three new attributes supportedAlgorithms, deltaRevocationList and - dmdName, and the objectClass dmd, are defined in the X.500(96) - documents. - -5. Attribute Types - - An LDAP server implementation SHOULD recognize the attribute types - described in this section. - -5.1. objectClass - - The values of the objectClass attribute describe the kind of object - which an entry represents. The objectClass attribute is present in - every entry, with at least two values. One of the values is either - "top" or "alias". - - ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - -5.2. aliasedObjectName - - The aliasedObjectName attribute is used by the directory service if - the entry containing this attribute is an alias. - - ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) - -5.3. knowledgeInformation - - This attribute is no longer used. - - ( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) - -5.4. cn - - This is the X.500 commonName attribute, which contains a name of an - object. If the object corresponds to a person, it is typically the - person's full name. - - ( 2.5.4.3 NAME 'cn' SUP name ) - - - - - -Wahl Standards Track [Page 3] - -RFC 2256 LDAPv3 Schema December 1997 - - -5.5. sn - - This is the X.500 surname attribute, which contains the family name - of a person. - - ( 2.5.4.4 NAME 'sn' SUP name ) - -5.6. serialNumber - - This attribute contains the serial number of a device. - - ( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} ) - -5.7. c - - This attribute contains a two-letter ISO 3166 country code - (countryName). - - ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE ) - -5.8. l - - This attribute contains the name of a locality, such as a city, - county or other geographic region (localityName). - - ( 2.5.4.7 NAME 'l' SUP name ) - -5.9. st - - This attribute contains the full name of a state or province - (stateOrProvinceName). - - ( 2.5.4.8 NAME 'st' SUP name ) - -5.10. street - - This attribute contains the physical address of the object to which - the entry corresponds, such as an address for package delivery - (streetAddress). - - ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) - - - - - - -Wahl Standards Track [Page 4] - -RFC 2256 LDAPv3 Schema December 1997 - - -5.11. o - - This attribute contains the name of an organization - (organizationName). - - ( 2.5.4.10 NAME 'o' SUP name ) - -5.12. ou - - This attribute contains the name of an organizational unit - (organizationalUnitName). - - ( 2.5.4.11 NAME 'ou' SUP name ) - -5.13. title - - This attribute contains the title, such as "Vice President", of a - person in their organizational context. The "personalTitle" - attribute would be used for a person's title independent of their job - function. - - ( 2.5.4.12 NAME 'title' SUP name ) - -5.14. description - - This attribute contains a human-readable description of the object. - - ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) - -5.15. searchGuide - - This attribute is for use by X.500 clients in constructing search - filters. It is obsoleted by enhancedSearchGuide, described below in - 5.48. - - ( 2.5.4.14 NAME 'searchGuide' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) - -5.16. businessCategory - - This attribute describes the kind of business performed by an - organization. - - ( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) - - - -Wahl Standards Track [Page 5] - -RFC 2256 LDAPv3 Schema December 1997 - - -5.17. postalAddress - - ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch - SUBSTR caseIgnoreListSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) - -5.18. postalCode - - ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ) - -5.19. postOfficeBox - - ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ) - -5.20. physicalDeliveryOfficeName - - ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) - -5.21. telephoneNumber - - ( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch - SUBSTR telephoneNumberSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} ) - -5.22. telexNumber - - ( 2.5.4.21 NAME 'telexNumber' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) - -5.23. teletexTerminalIdentifier - - ( 2.5.4.22 NAME 'teletexTerminalIdentifier' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) - -5.24. facsimileTelephoneNumber - - ( 2.5.4.23 NAME 'facsimileTelephoneNumber' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) - - - - - - - -Wahl Standards Track [Page 6] - -RFC 2256 LDAPv3 Schema December 1997 - - -5.25. x121Address - - ( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch - SUBSTR numericStringSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} ) - -5.26. internationaliSDNNumber - - ( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch - SUBSTR numericStringSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) - -5.27. registeredAddress - - This attribute holds a postal address suitable for reception of - telegrams or expedited documents, where it is necessary to have the - recipient accept delivery. - - ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress - SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) - -5.28. destinationIndicator - - This attribute is used for the telegram service. - - ( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} ) - -5.29. preferredDeliveryMethod - - ( 2.5.4.28 NAME 'preferredDeliveryMethod' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 - SINGLE-VALUE ) - -5.30. presentationAddress - - This attribute contains an OSI presentation address. - - ( 2.5.4.29 NAME 'presentationAddress' - EQUALITY presentationAddressMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 - SINGLE-VALUE ) - - - - - - - - -Wahl Standards Track [Page 7] - -RFC 2256 LDAPv3 Schema December 1997 - - -5.31. supportedApplicationContext - - This attribute contains the identifiers of OSI application contexts. - - ( 2.5.4.30 NAME 'supportedApplicationContext' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - -5.32. member - - ( 2.5.4.31 NAME 'member' SUP distinguishedName ) - -5.33. owner - - ( 2.5.4.32 NAME 'owner' SUP distinguishedName ) - -5.34. roleOccupant - - ( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName ) - -5.35. seeAlso - - ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName ) - -5.36. userPassword - - ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} ) - - Passwords are stored using an Octet String syntax and are not - encrypted. Transfer of cleartext passwords are strongly discouraged - where the underlying transport service cannot guarantee - confidentiality and may result in disclosure of the password to - unauthorized parties. - -5.37. userCertificate - - This attribute is to be stored and requested in the binary form, as - 'userCertificate;binary'. - - ( 2.5.4.36 NAME 'userCertificate' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) - -5.38. cACertificate - - This attribute is to be stored and requested in the binary form, as - 'cACertificate;binary'. - - - - -Wahl Standards Track [Page 8] - -RFC 2256 LDAPv3 Schema December 1997 - - - ( 2.5.4.37 NAME 'cACertificate' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) - -5.39. authorityRevocationList - - This attribute is to be stored and requested in the binary form, as - 'authorityRevocationList;binary'. - - ( 2.5.4.38 NAME 'authorityRevocationList' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) - -5.40. certificateRevocationList - - This attribute is to be stored and requested in the binary form, as - 'certificateRevocationList;binary'. - - ( 2.5.4.39 NAME 'certificateRevocationList' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) - -5.41. crossCertificatePair - - This attribute is to be stored and requested in the binary form, as - 'crossCertificatePair;binary'. - - ( 2.5.4.40 NAME 'crossCertificatePair' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 ) - -5.42. name - - The name attribute type is the attribute supertype from which string - attribute types typically used for naming may be formed. It is - unlikely that values of this type itself will occur in an entry. LDAP - server implementations which do not support attribute subtyping need - not recognize this attribute in requests. Client implementations - MUST NOT assume that LDAP servers are capable of performing attribute - subtyping. - - ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) - -5.43. givenName - - The givenName attribute is used to hold the part of a person's name - which is not their surname nor middle name. - - ( 2.5.4.42 NAME 'givenName' SUP name ) - - - - -Wahl Standards Track [Page 9] - -RFC 2256 LDAPv3 Schema December 1997 - - -5.44. initials - - The initials attribute contains the initials of some or all of an - individuals names, but not the surname(s). - - ( 2.5.4.43 NAME 'initials' SUP name ) - -5.45. generationQualifier - - The generationQualifier attribute contains the part of the name which - typically is the suffix, as in "IIIrd". - - ( 2.5.4.44 NAME 'generationQualifier' SUP name ) - -5.46. x500UniqueIdentifier - - The x500UniqueIdentifier attribute is used to distinguish between - objects when a distinguished name has been reused. This is a - different attribute type from both the "uid" and "uniqueIdentifier" - types. - - ( 2.5.4.45 NAME 'x500UniqueIdentifier' EQUALITY bitStringMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) - -5.47. dnQualifier - - The dnQualifier attribute type specifies disambiguating information - to add to the relative distinguished name of an entry. It is - intended for use when merging data from multiple sources in order to - prevent conflicts between entries which would otherwise have the same - name. It is recommended that the value of the dnQualifier attribute - be the same for all entries from a particular source. - - ( 2.5.4.46 NAME 'dnQualifier' EQUALITY caseIgnoreMatch - ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) - -5.48. enhancedSearchGuide - - This attribute is for use by X.500 clients in constructing search - filters. - - ( 2.5.4.47 NAME 'enhancedSearchGuide' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) - - - - - - - -Wahl Standards Track [Page 10] - -RFC 2256 LDAPv3 Schema December 1997 - - -5.49. protocolInformation - - This attribute is used in conjunction with the presentationAddress - attribute, to provide additional information to the OSI network - service. - - ( 2.5.4.48 NAME 'protocolInformation' - EQUALITY protocolInformationMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) - -5.50. distinguishedName - - This attribute type is not used as the name of the object itself, but - it is instead a base type from which attributes with DN syntax - inherit. - - It is unlikely that values of this type itself will occur in an - entry. LDAP server implementations which do not support attribute - subtyping need not recognize this attribute in requests. Client - implementations MUST NOT assume that LDAP servers are capable of - performing attribute subtyping. - - ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) - -5.51. uniqueMember - - ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) - -5.52. houseIdentifier - - This attribute is used to identify a building within a location. - - ( 2.5.4.51 NAME 'houseIdentifier' EQUALITY caseIgnoreMatch - SUBSTR caseIgnoreSubstringsMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) - -5.53. supportedAlgorithms - - This attribute is to be stored and requested in the binary form, as - 'supportedAlgorithms;binary'. - - ( 2.5.4.52 NAME 'supportedAlgorithms' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 ) - - - - - - -Wahl Standards Track [Page 11] - -RFC 2256 LDAPv3 Schema December 1997 - - -5.54. deltaRevocationList - - This attribute is to be stored and requested in the binary form, as - 'deltaRevocationList;binary'. - - ( 2.5.4.53 NAME 'deltaRevocationList' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) - -5.55. dmdName - - The value of this attribute specifies a directory management domain - (DMD), the administrative authority which operates the directory - server. - - ( 2.5.4.54 NAME 'dmdName' SUP name ) - -6. Syntaxes - - Servers SHOULD recognize the syntaxes defined in this section. Each - syntax begins with a sample value of the ldapSyntaxes attribute which - defines the OBJECT IDENTIFIER of the syntax. The descriptions of - syntax names are not carried in protocol, and are not guaranteed to - be unique. - -6.1. Delivery Method - - ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) - - Values in this syntax are encoded according to the following BNF: - - delivery-value = pdm / ( pdm whsp "$" whsp delivery-value ) - - pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / - "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" - - Example: - - telephone - -6.2. Enhanced Guide - - ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) - - Values in this syntax are encoded according to the following BNF: - - EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset - - subset = "baseobject" / "oneLevel" / "wholeSubtree" - - - -Wahl Standards Track [Page 12] - -RFC 2256 LDAPv3 Schema December 1997 - - - The criteria production is defined in the Guide syntax below. This - syntax has been added subsequent to RFC 1778. - - Example: - - person#(sn)#oneLevel - -6.3. Guide - - ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) - - Values in this syntax are encoded according to the following BNF: - - guide-value = [ object-class "#" ] criteria - - object-class = woid - - criteria = criteria-item / criteria-set / ( "!" criteria ) - - criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) / - ( [ "(" ] criteria "|" criteria-set [ ")" ] ) - - criteria-item = [ "(" ] attributetype "$" match-type [ ")" ] - - match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" - - This syntax should not be used for defining new attributes. - -6.4. Octet String - - ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) - - Values in this syntax are encoded as octet strings. - - - Example: - - secret - -6.5. Teletex Terminal Identifier - - ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' ) - - Values in this syntax are encoded according to the following BNF: - - teletex-id = ttx-term 0*("$" ttx-param) - - ttx-term = printablestring - - - -Wahl Standards Track [Page 13] - -RFC 2256 LDAPv3 Schema December 1997 - - - ttx-param = ttx-key ":" ttx-value - - ttx-key = "graphic" / "control" / "misc" / "page" / "private" - - ttx-value = octetstring - - In the above, the first printablestring is the encoding of the first - portion of the teletex terminal identifier to be encoded, and the - subsequent 0 or more octetstrings are subsequent portions of the - teletex terminal identifier. - -6.6. Telex Number - - ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) - - Values in this syntax are encoded according to the following BNF: - - telex-number = actual-number "$" country "$" answerback - - actual-number = printablestring - - country = printablestring - - answerback = printablestring - - In the above, actual-number is the syntactic representation of the - number portion of the TELEX number being encoded, country is the - TELEX country code, and answerback is the answerback code of a TELEX - terminal. - -6.7. Supported Algorithm - - ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' ) - - No printable representation of values of the supportedAlgorithms - attribute is defined in this document. Clients which wish to store - and retrieve this attribute MUST use "supportedAlgorithms;binary", in - which the value is transferred as a binary encoding. - -7. Object Classes - - LDAP servers MUST recognize the object classes "top" and "subschema". - LDAP servers SHOULD recognize all the other object classes listed - here as values of the objectClass attribute. - -7.1. top - - ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) - - - -Wahl Standards Track [Page 14] - -RFC 2256 LDAPv3 Schema December 1997 - - -7.2. alias - - ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName ) - -7.3. country - - ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c - MAY ( searchGuide $ description ) ) - -7.4. locality - - ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL - MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) ) - -7.5. organization - - ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o - MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ - x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ - facsimileTelephoneNumber $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l $ description ) ) - -7.6. organizationalUnit - - ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou - MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ - x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ - facsimileTelephoneNumber $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l $ description ) ) - -7.7. person - - ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) - MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) - -7.8. organizationalPerson - - ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL - MAY ( title $ x121Address $ registeredAddress $ - destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ - - - -Wahl Standards Track [Page 15] - -RFC 2256 LDAPv3 Schema December 1997 - - - facsimileTelephoneNumber $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ ou $ st $ l ) ) - -7.9. organizationalRole - - ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn - MAY ( x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ - facsimileTelephoneNumber $ - seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ - postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) - -7.10. groupOfNames - - ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn ) - MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) - -7.11. residentialPerson - - ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l - MAY ( businessCategory $ x121Address $ registeredAddress $ - destinationIndicator $ preferredDeliveryMethod $ telexNumber $ - teletexTerminalIdentifier $ telephoneNumber $ - internationaliSDNNumber $ - facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ - postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l ) ) - -7.12. applicationProcess - - ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn - MAY ( seeAlso $ ou $ l $ description ) ) - -7.13. applicationEntity - - ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL - MUST ( presentationAddress $ cn ) - MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ - description ) ) - -7.14. dSA - - ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL - MAY knowledgeInformation ) - - - - -Wahl Standards Track [Page 16] - -RFC 2256 LDAPv3 Schema December 1997 - - -7.15. device - - ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn - MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) ) - -7.16. strongAuthenticationUser - - ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY - MUST userCertificate ) - -7.17. certificationAuthority - - ( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY - MUST ( authorityRevocationList $ certificateRevocationList $ - cACertificate ) MAY crossCertificatePair ) - -7.18. groupOfUniqueNames - - ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL - MUST ( uniqueMember $ cn ) - MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) - -7.19. userSecurityInformation - - ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY - MAY ( supportedAlgorithms ) ) - -7.20. certificationAuthority-V2 - - ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP - certificationAuthority - AUXILIARY MAY ( deltaRevocationList ) ) - -7.21. cRLDistributionPoint - - ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL - MUST ( cn ) MAY ( certificateRevocationList $ - authorityRevocationList $ - deltaRevocationList ) ) - -7.22. dmd - - ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName ) - MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ - x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ - facsimileTelephoneNumber $ - - - -Wahl Standards Track [Page 17] - -RFC 2256 LDAPv3 Schema December 1997 - - - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l $ description ) ) - -8. Matching Rules - - Servers MAY implement additional matching rules. - -8.1. octetStringMatch - - Servers which implement the extensibleMatch filter SHOULD allow the - matching rule listed in this section to be used in the - extensibleMatch. In general these servers SHOULD allow matching - rules to be used with all attribute types known to the server, when - the assertion syntax of the matching rule is the same as the value - syntax of the attribute. - - ( 2.5.13.17 NAME 'octetStringMatch' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) - -9. Security Considerations - - Attributes of directory entries are used to provide descriptive - information about the real-world objects they represent, which can be - people, organizations or devices. Most countries have privacy laws - regarding the publication of information about people. - - Transfer of cleartext passwords are strongly discouraged where the - underlying transport service cannot guarantee confidentiality and may - result in disclosure of the password to unauthorized parties. - -10. Acknowledgements - - The definitions on which this document have been developed by - committees for telecommunications and international standards. No - new attribute definitions have been added. The syntax definitions - are based on the ISODE "QUIPU" implementation of X.500. - -11. Bibliography - - [1] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, - "Lightweight X.500 Directory Access Protocol (v3): Attribute - Syntax Definitions", RFC 2252, December 1997. - - [2] The Directory: Models. ITU-T Recommendation X.501, 1996. - - [3] The Directory: Authentication Framework. ITU-T Recommendation - X.509, 1996. - - - - -Wahl Standards Track [Page 18] - -RFC 2256 LDAPv3 Schema December 1997 - - - [4] The Directory: Selected Attribute Types. ITU-T Recommendation - X.520, 1996. - - [5] The Directory: Selected Object Classes. ITU-T Recommendation - X.521, 1996. - - [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - -12. Author's Address - - Mark Wahl - Critical Angle Inc. - 4815 West Braker Lane #502-385 - Austin, TX 78759 - USA - - Phone: +1 512 372 3160 - EMail: M.Wahl@critical-angle.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wahl Standards Track [Page 19] - -RFC 2256 LDAPv3 Schema December 1997 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Wahl Standards Track [Page 20] - |