7 Network Working Group W. Yeong
8 Request for Comments: 1777 Performance Systems International
9 Obsoletes: 1487 T. Howes
10 Category: Standards Track University of Michigan
16 Lightweight Directory Access Protocol
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
28 The protocol described in this document is designed to provide access
29 to the X.500 Directory while not incurring the resource requirements
30 of the Directory Access Protocol (DAP). This protocol is specifically
31 targeted at simple management applications and browser applications
32 that provide simple read/write interactive access to the X.500
33 Directory, and is intended to be a complement to the DAP itself.
35 Key aspects of LDAP are:
37 - Protocol elements are carried directly over TCP or other transport,
38 bypassing much of the session/presentation overhead.
40 - Many protocol data elements are encoding as ordinary strings (e.g.,
43 - A lightweight BER encoding is used to encode all protocol elements.
47 The tremendous interest in X.500 [1,2] technology in the Internet has
48 lead to efforts to reduce the high "cost of entry" associated with
49 use of the technology, such as the Directory Assistance Service [3]
50 and DIXIE [4]. While efforts such as these have met with success,
51 they have been solutions based on particular implementations and as
52 such have limited applicability. This document continues the efforts
53 to define Directory protocol alternatives but departs from previous
54 efforts in that it consciously avoids dependence on particular
58 Yeong, Howes & Kille [Page 1]
60 RFC 1777 LDAP March 1995
67 The general model adopted by this protocol is one of clients
68 performing protocol operations against servers. In this model, this
69 is accomplished by a client transmitting a protocol request
70 describing the operation to be performed to a server, which is then
71 responsible for performing the necessary operations on the Directory.
72 Upon completion of the necessary operations, the server returns a
73 response containing any results or errors to the requesting client.
74 In keeping with the goal of easing the costs associated with use of
75 the Directory, it is an objective of this protocol to minimize the
76 complexity of clients so as to facilitate widespread deployment of
77 applications capable of utilizing the Directory.
79 Note that, although servers are required to return responses whenever
80 such responses are defined in the protocol, there is no requirement
81 for synchronous behavior on the part of either client or server
82 implementations: requests and responses for multiple operations may
83 be exchanged by client and servers in any order, as long as clients
84 eventually receive a response for every request that requires one.
86 Consistent with the model of servers performing protocol operations
87 on behalf of clients, it is also to be noted that protocol servers
88 are expected to handle referrals without resorting to the return of
89 such referrals to the client. This protocol makes no provisions for
90 the return of referrals to clients, as the model is one of servers
91 ensuring the performance of all necessary operations in the
92 Directory, with only final results or errors being returned by
95 Note that this protocol can be mapped to a strict subset of the
96 directory abstract service, so it can be cleanly provided by the DAP.
98 3. Mapping Onto Transport Services
100 This protocol is designed to run over connection-oriented, reliable
101 transports, with all 8 bits in an octet being significant in the data
102 stream. Specifications for two underlying services are defined here,
103 though others are also possible.
105 3.1. Transmission Control Protocol (TCP)
107 The LDAPMessage PDUs are mapped directly onto the TCP bytestream.
108 Server implementations running over the TCP should provide a protocol
109 listener on port 389.
114 Yeong, Howes & Kille [Page 2]
116 RFC 1777 LDAP March 1995
119 3.2. Connection Oriented Transport Service (COTS)
121 The connection is established. No special use of T-Connect is made.
122 Each LDAPMessage PDU is mapped directly onto T-Data.
124 4. Elements of Protocol
126 For the purposes of protocol exchanges, all protocol operations are
127 encapsulated in a common envelope, the LDAPMessage, which is defined
134 bindRequest BindRequest,
135 bindResponse BindResponse,
136 unbindRequest UnbindRequest,
137 searchRequest SearchRequest,
138 searchResponse SearchResponse,
139 modifyRequest ModifyRequest,
140 modifyResponse ModifyResponse,
141 addRequest AddRequest,
142 addResponse AddResponse,
143 delRequest DelRequest,
144 delResponse DelResponse,
145 modifyRDNRequest ModifyRDNRequest,
146 modifyRDNResponse ModifyRDNResponse,
147 compareDNRequest CompareRequest,
148 compareDNResponse CompareResponse,
149 abandonRequest AbandonRequest
153 MessageID ::= INTEGER (0 .. maxInt)
155 The function of the LDAPMessage is to provide an envelope containing
156 common fields required in all protocol exchanges. At this time the
157 only common field is a message ID, which is required to have a value
158 different from the values of any other requests outstanding in the
159 LDAP session of which this message is a part.
161 The message ID value must be echoed in all LDAPMessage envelopes
162 encapsulting responses corresponding to the request contained in the
163 LDAPMessage in which the message ID value was originally used.
165 In addition to the LDAPMessage defined above, the following
166 definitions are also used in defining protocol operations:
170 Yeong, Howes & Kille [Page 3]
172 RFC 1777 LDAP March 1995
175 LDAPString ::= OCTET STRING
177 The LDAPString is a notational convenience to indicate that, although
178 strings of LDAPString type encode as OCTET STRING types, the legal
179 character set in such strings is limited to the IA5 character set.
181 LDAPDN ::= LDAPString
183 RelativeLDAPDN ::= LDAPString
185 An LDAPDN and a RelativeLDAPDN are respectively defined to be the
186 representation of a Distinguished Name and a Relative Distinguished
187 Name after encoding according to the specification in [5], such that
189 <distinguished-name> ::= <name>
191 <relative-distinguished-name> ::= <name-component>
193 where <name> and <name-component> are as defined in [5].
195 AttributeValueAssertion ::=
197 attributeType AttributeType,
198 attributeValue AttributeValue
201 The AttributeValueAssertion type definition is similar to the one in
202 the X.500 Directory standards.
204 AttributeType ::= LDAPString
206 AttributeValue ::= OCTET STRING
208 An AttributeType value takes on as its value the textual string
209 associated with that AttributeType in the X.500 Directory standards.
210 For example, the AttributeType 'organizationName' with object
211 identifier 2.5.4.10 is represented as an AttributeType in this
212 protocol by the string "organizationName". In the event that a
213 protocol implementation encounters an Attribute Type with which it
214 cannot associate a textual string, an ASCII string encoding of the
215 object identifier associated with the Attribute Type may be
216 subsitituted. For example, the organizationName AttributeType may be
217 represented by the ASCII string "2.5.4.10" if a protocol
218 implementation is unable to associate the string "organizationName"
226 Yeong, Howes & Kille [Page 4]
228 RFC 1777 LDAP March 1995
231 A field of type AttributeValue takes on as its value an octet string
232 encoding of a Directory AttributeValue type. The definition of these
233 string encodings for different Directory AttributeValue types may be
234 found in companions to this document that define the encodings of
235 various attribute syntaxes such as [6].
239 resultCode ENUMERATED {
243 timeLimitExceeded (3),
244 sizeLimitExceeded (4),
247 authMethodNotSupported (7),
248 strongAuthRequired (8),
249 noSuchAttribute (16),
250 undefinedAttributeType (17),
251 inappropriateMatching (18),
252 constraintViolation (19),
253 attributeOrValueExists (20),
254 invalidAttributeSyntax (21),
257 invalidDNSyntax (34),
259 aliasDereferencingProblem (36),
260 inappropriateAuthentication (48),
261 invalidCredentials (49),
262 insufficientAccessRights (50),
265 unwillingToPerform (53),
267 namingViolation (64),
268 objectClassViolation (65),
269 notAllowedOnNonLeaf (66),
270 notAllowedOnRDN (67),
271 entryAlreadyExists (68),
272 objectClassModsProhibited (69),
276 errorMessage LDAPString
282 Yeong, Howes & Kille [Page 5]
284 RFC 1777 LDAP March 1995
287 The LDAPResult is the construct used in this protocol to return
288 success or failure indications from servers to clients. In response
289 to various requests, servers will return responses containing fields
290 of type LDAPResult to indicate the final status of a protocol
291 operation request. The errorMessage field of this construct may, at
292 the servers option, be used to return an ASCII string containing a
293 textual, human-readable error diagnostic. As this error diagnostic is
294 not standardized, implementations should not rely on the values
295 returned. If the server chooses not to return a textual diagnostic,
296 the errorMessage field of the LDAPResult type should contain a zero
299 For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax,
300 isLeaf, and aliasDereferencingProblem, the matchedDN field is set to
301 the name of the lowest entry (object or alias) in the DIT that was
302 matched and is a truncated form of the name provided or, if an alias
303 has been dereferenced, of the resulting name. The matchedDN field
304 should be set to NULL DN (a zero length string) in all other cases.
308 The function of the Bind Operation is to initiate a protocol session
309 between a client and a server, and to allow the authentication of the
310 client to the server. The Bind Operation must be the first operation
311 request received by a server from a client in a protocol session.
312 The Bind Request is defined as follows:
315 [APPLICATION 0] SEQUENCE {
316 version INTEGER (1 .. 127),
318 authentication CHOICE {
319 simple [0] OCTET STRING,
320 krbv42LDAP [1] OCTET STRING,
321 krbv42DSA [2] OCTET STRING
325 Parameters of the Bind Request are:
327 - version: A version number indicating the version of the protocol to
328 be used in this protocol session. This document describes version
329 2 of the LDAP protocol. Note that there is no version negotiation,
330 and the client should just set this parameter to the version it
338 Yeong, Howes & Kille [Page 6]
340 RFC 1777 LDAP March 1995
343 - name: The name of the Directory object that the client wishes to
344 bind as. This field may take on a null value (a zero length
345 string) for the purposes of anonymous binds.
347 - authentication: information used to authenticate the name, if any,
348 provided in the Bind Request. The "simple" authentication option
349 provides minimal authentication facilities, with the contents of
350 the authentication field consisting only of a cleartext password.
351 This option should also be used when unauthenticated or anonymous
352 binds are to be performed, with the field containing a zero length
353 string in such cases. Kerberos version 4 [7] authentication to the
354 LDAP server and the DSA is accomplished by using the "krbv42LDAP"
355 and "krbv42DSA" authentication options, respectively. Note that
356 though they are referred to as separate entities here, there is no
357 requirement these two entities be distinct (i.e., a DSA could speak
358 LDAP directly). Two separate authentication options are provided
359 to support all implementations. Each octet string should contain
360 the kerberos ticket (e.g., as returned by krb_mk_req()) for the
361 appropriate service. The suggested service name for authentication
362 to the LDAP server is "ldapserver". The suggested service name for
363 authentication to the DSA is "x500dsa". In both cases, the
364 suggested instance name for the service is the name of the host on
365 which the service is running. Of course, the actual service names
366 and instances will depend on what is entered in the local kerberos
369 The Bind Operation requires a response, the Bind Response, which is
372 BindResponse ::= [APPLICATION 1] LDAPResult
374 A Bind Response consists simply of an indication from the server of
375 the status of the client's request for the initiation of a protocol
378 Upon receipt of a Bind Request, a protocol server will authenticate
379 the requesting client if necessary, and attempt to set up a protocol
380 session with that client. The server will then return a Bind Response
381 to the client indicating the status of the session setup request.
383 4.2. Unbind Operation
385 The function of the Unbind Operation is to terminate a protocol
386 session. The Unbind Operation is defined as follows:
388 UnbindRequest ::= [APPLICATION 2] NULL
394 Yeong, Howes & Kille [Page 7]
396 RFC 1777 LDAP March 1995
399 The Unbind Operation has no response defined. Upon transmission of an
400 UnbindRequest, a protocol client may assume that the protocol session
401 is terminated. Upon receipt of an UnbindRequest, a protocol server
402 may assume that the requesting client has terminated the session and
403 that all outstanding requests may be discarded.
405 4.3. Search Operation
407 The Search Operation allows a client to request that a search be
408 performed on its behalf by a server. The Search Request is defined as
412 [APPLICATION 3] SEQUENCE {
419 derefAliases ENUMERATED {
420 neverDerefAliases (0),
421 derefInSearching (1),
422 derefFindingBaseObj (2),
425 sizeLimit INTEGER (0 .. maxInt),
426 timeLimit INTEGER (0 .. maxInt),
429 attributes SEQUENCE OF AttributeType
434 and [0] SET OF Filter,
435 or [1] SET OF Filter,
437 equalityMatch [3] AttributeValueAssertion,
438 substrings [4] SubstringFilter,
439 greaterOrEqual [5] AttributeValueAssertion,
440 lessOrEqual [6] AttributeValueAssertion,
441 present [7] AttributeType,
442 approxMatch [8] AttributeValueAssertion
450 Yeong, Howes & Kille [Page 8]
452 RFC 1777 LDAP March 1995
457 initial [0] LDAPString,
463 Parameters of the Search Request are:
465 - baseObject: An LDAPDN that is the base object entry relative to
466 which the search is to be performed.
468 - scope: An indicator of the scope of the search to be performed. The
469 semantics of the possible values of this field are identical to the
470 semantics of the scope field in the Directory Search Operation.
472 - derefAliases: An indicator as to how alias objects should be
473 handled in searching. The semantics of the possible values of
474 this field are, in order of increasing value:
476 neverDerefAliases: do not dereference aliases in searching
477 or in locating the base object of the search;
479 derefInSearching: dereference aliases in subordinates of
480 the base object in searching, but not in locating the
481 base object of the search;
483 derefFindingBaseObject: dereference aliases in locating
484 the base object of the search, but not when searching
485 subordinates of the base object;
487 derefAlways: dereference aliases both in searching and in
488 locating the base object of the search.
490 - sizelimit: A sizelimit that restricts the maximum number of entries
491 to be returned as a result of the search. A value of 0 in this
492 field indicates that no sizelimit restrictions are in effect for
495 - timelimit: A timelimit that restricts the maximum time (in seconds)
496 allowed for a search. A value of 0 in this field indicates that no
497 timelimit restrictions are in effect for the search.
499 - attrsOnly: An indicator as to whether search results should contain
500 both attribute types and values, or just attribute types. Setting
501 this field to TRUE causes only attribute types (no values) to be
502 returned. Setting this field to FALSE causes both attribute types
506 Yeong, Howes & Kille [Page 9]
508 RFC 1777 LDAP March 1995
511 and values to be returned.
513 - filter: A filter that defines the conditions that must be fulfilled
514 in order for the search to match a given entry.
516 - attributes: A list of the attributes from each entry found as a
517 result of the search to be returned. An empty list signifies that
518 all attributes from each entry found in the search are to be
521 The results of the search attempted by the server upon receipt of a
522 Search Request are returned in Search Responses, defined as follows:
526 entry [APPLICATION 4] SEQUENCE {
528 attributes SEQUENCE OF SEQUENCE {
530 SET OF AttributeValue
533 resultCode [APPLICATION 5] LDAPResult
536 Upon receipt of a Search Request, a server will perform the necessary
539 The server will return to the client a sequence of responses
542 - Zero or more Search Responses each consisting of an entry found
543 during the search; with the response sequence terminated by
545 - A single Search Response containing an indication of success, or
546 detailing any errors that have occurred.
548 Each entry returned will contain all attributes, complete with
549 associated values if necessary, as specified in the 'attributes'
550 field of the Search Request.
552 Note that an X.500 "list" operation can be emulated by a one-level
553 LDAP search operation with a filter checking for the existence of the
554 objectClass attribute, and that an X.500 "read" operation can be
555 emulated by a base object LDAP search operation with the same filter.
562 Yeong, Howes & Kille [Page 10]
564 RFC 1777 LDAP March 1995
567 4.4. Modify Operation
569 The Modify Operation allows a client to request that a modification
570 of the DIB be performed on its behalf by a server. The Modify
571 Request is defined as follows:
574 [APPLICATION 6] SEQUENCE {
576 modification SEQUENCE OF SEQUENCE {
577 operation ENUMERATED {
582 modification SEQUENCE {
590 Parameters of the Modify Request are:
592 - object: The object to be modified. The value of this field should
593 name the object to be modified after all aliases have been
594 dereferenced. The server will not perform any alias dereferencing
595 in determining the object to be modified.
597 - A list of modifications to be performed on the entry to be modified.
598 The entire list of entry modifications should be performed
599 in the order they are listed, as a single atomic operation. While
600 individual modifications may violate the Directory schema, the
601 resulting entry after the entire list of modifications is performed
602 must conform to the requirements of the Directory schema. The
603 values that may be taken on by the 'operation' field in each
604 modification construct have the following semantics respectively:
606 add: add values listed to the given attribute, creating
607 the attribute if necessary;
609 delete: delete values listed from the given attribute,
611 removing the entire attribute if no values are listed, or
612 if all current values of the attribute are listed for
618 Yeong, Howes & Kille [Page 11]
620 RFC 1777 LDAP March 1995
623 replace: replace existing values of the given attribute
624 with the new values listed, creating the attribute if
627 The result of the modify attempted by the server upon receipt of a
628 Modify Request is returned in a Modify Response, defined as follows:
630 ModifyResponse ::= [APPLICATION 7] LDAPResult
632 Upon receipt of a Modify Request, a server will perform the necessary
633 modifications to the DIB.
635 The server will return to the client a single Modify Response
636 indicating either the successful completion of the DIB modification,
637 or the reason that the modification failed. Note that due to the
638 requirement for atomicity in applying the list of modifications in
639 the Modify Request, the client may expect that no modifications of
640 the DIB have been performed if the Modify Response received indicates
641 any sort of error, and that all requested modifications have been
642 performed if the Modify Response indicates successful completion of
643 the Modify Operation.
647 The Add Operation allows a client to request the addition of an entry
648 into the Directory. The Add Request is defined as follows:
651 [APPLICATION 8] SEQUENCE {
653 attrs SEQUENCE OF SEQUENCE {
655 values SET OF AttributeValue
659 Parameters of the Add Request are:
661 - entry: the Distinguished Name of the entry to be added. Note that
662 all components of the name except for the last RDN component must
663 exist for the add to succeed.
665 - attrs: the list of attributes that make up the content of the entry
668 The result of the add attempted by the server upon receipt of a Add
669 Request is returned in the Add Response, defined as follows:
674 Yeong, Howes & Kille [Page 12]
676 RFC 1777 LDAP March 1995
679 AddResponse ::= [APPLICATION 9] LDAPResult
681 Upon receipt of an Add Request, a server will attempt to perform the
682 add requested. The result of the add attempt will be returned to the
683 client in the Add Response.
685 4.6. Delete Operation
687 The Delete Operation allows a client to request the removal of an
688 entry from the Directory. The Delete Request is defined as follows:
690 DelRequest ::= [APPLICATION 10] LDAPDN
692 The Delete Request consists only of the Distinguished Name of the
693 entry to be deleted. The result of the delete attempted by the
694 server upon receipt of a Delete Request is returned in the Delete
695 Response, defined as follows:
697 DelResponse ::= [APPLICATION 11] LDAPResult
699 Upon receipt of a Delete Request, a server will attempt to perform
700 the entry removal requested. The result of the delete attempt will be
701 returned to the client in the Delete Response. Note that only leaf
702 objects may be deleted with this operation.
704 4.7. Modify RDN Operation
706 The Modify RDN Operation allows a client to change the last component
707 of the name of an entry in the Directory. The Modify RDN Request is
711 [APPLICATION 12] SEQUENCE {
713 newrdn RelativeLDAPDN,
717 Parameters of the Modify RDN Request are:
719 - entry: the name of the entry to be changed.
721 - newrdn: the RDN that will form the last component of the new name.
723 - deleteoldrdn: a boolean parameter that controls whether the old RDN
724 attribute values should be retained as attributes of the entry or
725 deleted from the entry.
730 Yeong, Howes & Kille [Page 13]
732 RFC 1777 LDAP March 1995
735 The result of the name change attempted by the server upon receipt of
736 a Modify RDN Request is returned in the Modify RDN Response, defined
739 ModifyRDNResponse ::= [APPLICATION 13] LDAPResult
741 Upon receipt of a Modify RDN Request, a server will attempt to
742 perform the name change. The result of the name change attempt will
743 be returned to the client in the Modify RDN Response. The attributes
744 that make up the old RDN are deleted from the entry, or kept,
745 depending on the setting of the deleteoldrdn parameter.
747 4.8. Compare Operation
749 The Compare Operation allows a client to compare an assertion
750 provided with an entry in the Directory. The Compare Request is
754 [APPLICATION 14] SEQUENCE {
756 ava AttributeValueAssertion
759 Parameters of the Compare Request are:
761 - entry: the name of the entry to be compared with.
763 - ava: the assertion with which the entry is to be compared.
765 The result of the compare attempted by the server upon receipt of a
766 Compare Request is returned in the Compare Response, defined as
769 CompareResponse ::= [APPLICATION 15] LDAPResult
771 Upon receipt of a Compare Request, a server will attempt to perform
772 the requested comparison. The result of the comparison will be
773 returned to the client in the Compare Response. Note that errors and
774 the result of comparison are all returned in the same construct.
776 6.9. Abandon Operation
778 The function of the Abandon Operation is to allow a client to request
779 that the server abandon an outstanding operation. The Abandon
780 Request is defined as follows:
782 AbandonRequest ::= [APPLICATION 16] MessageID
786 Yeong, Howes & Kille [Page 14]
788 RFC 1777 LDAP March 1995
791 There is no response defined in the Abandon Operation. Upon
792 transmission of an Abandon Operation, a client may expect that the
793 operation identityfied by the Message ID in the Abandon Request has
794 been abandoned. In the event that a server receives an Abandon
795 Request on a Search Operation in the midst of transmitting responses
796 to that search, that server should cease transmitting responses to
797 the abandoned search immediately.
799 5. Protocol Element Encodings
801 The protocol elements of LDAP are encoded for exchange using the
802 Basic Encoding Rules (BER) [12] of ASN.1 [11]. However, due to the
803 high overhead involved in using certain elements of the BER, the
804 following additional restrictions are placed on BER-encodings of LDAP
807 (1) Only the definite form of length encoding will be used.
809 (2) Bitstrings and octet strings and all character string types
810 will be encoded in the primitive form only.
812 6. Security Considerations
814 This version of the protocol provides facilities only for simple
815 authentication using a cleartext password, and for kerberos version 4
816 authentication. Future versions of LDAP will likely include support
817 for other authentication methods.
821 [1] The Directory: Overview of Concepts, Models and Service. CCITT
822 Recommendation X.500, 1988.
824 [2] Information Processing Systems -- Open Systems Interconnection --
825 The Directory: Overview of Concepts, Models and Service. ISO/IEC
826 JTC 1/SC21; International Standard 9594-1, 1988
828 [3] Rose, M., "Directory Assistance Service", RFC 1202, Performance
829 Systems International, Inc., February 1991.
831 [4] Howes, T., Smith, M., and B. Beecher, "DIXIE Protocol
832 Specification, RFC 1249, University of Michigan, August 1991.
834 [5] Kille, S., "A String Representation of Distinguished Names", RFC
835 1779, ISODE Consortium, March 1995.
842 Yeong, Howes & Kille [Page 15]
844 RFC 1777 LDAP March 1995
847 [6] Howes, T., Kille, S., Yeong, W., and C. Robbins, "Lightweight
848 Directory Access Protocol", RFC 1488, University of Michigan,
849 ISODE Consortium, Performance Systems International, NeXor Ltd.,
852 [7] Kerberos Authentication and Authorization System. S.P. Miller,
853 B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena
854 Documentation Section E.2.1, December 1987.
856 [8] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
857 1/SC21; International Standard 9594-2, 1988.
859 [10] The Directory: Abstract Service Definition. CCITT Recommendation
860 X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
862 [11] Specification of Abstract Syntax Notation One (ASN.1). CCITT
863 Recommendation X.208, 1988.
865 [12] Specification of Basic Encoding Rules for Abstract Syntax
866 Notation One (ASN.1). CCITT Recommendation X.209, 1988.
898 Yeong, Howes & Kille [Page 16]
900 RFC 1777 LDAP March 1995
903 10. Authors' Addresses
907 510 Huntmar Park Drive
911 Phone: +1 703-450-8001
912 EMail: yeongw@psilink.com
916 University of Michigan
919 Ann Arbor, MI 48103-4943
922 Phone: +1 313 747-4454
933 Phone: +44-71-223-4062
934 EMail: S.Kille@isode.com
954 Yeong, Howes & Kille [Page 17]
956 RFC 1777 LDAP March 1995
959 Appendix A - Complete ASN.1 Definition
961 Lightweight-Directory-Access-Protocol DEFINITIONS IMPLICIT TAGS ::=
968 -- unique id in request,
969 -- to be echoed in response(s)
971 searchRequest SearchRequest,
972 searchResponse SearchResponse,
973 modifyRequest ModifyRequest,
974 modifyResponse ModifyResponse,
975 addRequest AddRequest,
976 addResponse AddResponse,
977 delRequest DelRequest,
978 delResponse DelResponse,
979 modifyDNRequest ModifyDNRequest,
980 modifyDNResponse ModifyDNResponse,
981 compareDNRequest CompareRequest,
982 compareDNResponse CompareResponse,
983 bindRequest BindRequest,
984 bindResponse BindResponse,
985 abandonRequest AbandonRequest,
986 unbindRequest UnbindRequest
991 [APPLICATION 0] SEQUENCE {
992 version INTEGER (1 .. 127),
993 -- current version is 2
995 -- null name implies an anonymous bind
996 authentication CHOICE {
997 simple [0] OCTET STRING,
998 -- a zero length octet string
999 -- implies an unauthenticated
1001 krbv42LDAP [1] OCTET STRING,
1002 krbv42DSA [2] OCTET STRING
1003 -- values as returned by
1005 -- Other values in later versions
1006 -- of this protocol.
1010 Yeong, Howes & Kille [Page 18]
1012 RFC 1777 LDAP March 1995
1018 BindResponse ::= [APPLICATION 1] LDAPResult
1020 UnbindRequest ::= [APPLICATION 2] NULL
1023 [APPLICATION 3] SEQUENCE {
1030 derefAliases ENUMERATED {
1031 neverDerefAliases (0),
1032 derefInSearching (1),
1033 derefFindingBaseObj (2),
1034 alwaysDerefAliases (3)
1036 sizeLimit INTEGER (0 .. maxInt),
1037 -- value of 0 implies no sizelimit
1038 timeLimit INTEGER (0 .. maxInt),
1039 -- value of 0 implies no timelimit
1041 -- TRUE, if only attributes (without values)
1044 attributes SEQUENCE OF AttributeType
1049 entry [APPLICATION 4] SEQUENCE {
1051 attributes SEQUENCE OF SEQUENCE {
1057 resultCode [APPLICATION 5] LDAPResult
1061 [APPLICATION 6] SEQUENCE {
1066 Yeong, Howes & Kille [Page 19]
1068 RFC 1777 LDAP March 1995
1071 modifications SEQUENCE OF SEQUENCE {
1072 operation ENUMERATED {
1077 modification SEQUENCE {
1086 ModifyResponse ::= [APPLICATION 7] LDAPResult
1089 [APPLICATION 8] SEQUENCE {
1091 attrs SEQUENCE OF SEQUENCE {
1093 values SET OF AttributeValue
1097 AddResponse ::= [APPLICATION 9] LDAPResult
1099 DelRequest ::= [APPLICATION 10] LDAPDN
1101 DelResponse ::= [APPLICATION 11] LDAPResult
1103 ModifyRDNRequest ::=
1104 [APPLICATION 12] SEQUENCE {
1106 newrdn RelativeLDAPDN -- old RDN always deleted
1109 ModifyRDNResponse ::= [APPLICATION 13] LDAPResult
1112 [APPLICATION 14] SEQUENCE {
1114 ava AttributeValueAssertion
1117 CompareResponse ::= [APPLICATION 15] LDAPResult
1122 Yeong, Howes & Kille [Page 20]
1124 RFC 1777 LDAP March 1995
1127 AbandonRequest ::= [APPLICATION 16] MessageID
1129 MessageID ::= INTEGER (0 .. maxInt)
1131 LDAPDN ::= LDAPString
1133 RelativeLDAPDN ::= LDAPString
1137 and [0] SET OF Filter,
1138 or [1] SET OF Filter,
1140 equalityMatch [3] AttributeValueAssertion,
1141 substrings [4] SubstringFilter,
1142 greaterOrEqual [5] AttributeValueAssertion,
1143 lessOrEqual [6] AttributeValueAssertion,
1144 present [7] AttributeType,
1145 approxMatch [8] AttributeValueAssertion
1150 resultCode ENUMERATED {
1152 operationsError (1),
1154 timeLimitExceeded (3),
1155 sizeLimitExceeded (4),
1158 authMethodNotSupported (7),
1159 strongAuthRequired (8),
1160 noSuchAttribute (16),
1161 undefinedAttributeType (17),
1162 inappropriateMatching (18),
1163 constraintViolation (19),
1164 attributeOrValueExists (20),
1165 invalidAttributeSyntax (21),
1168 invalidDNSyntax (34),
1170 aliasDereferencingProblem (36),
1171 inappropriateAuthentication (48),
1172 invalidCredentials (49),
1173 insufficientAccessRights (50),
1178 Yeong, Howes & Kille [Page 21]
1180 RFC 1777 LDAP March 1995
1184 unwillingToPerform (53),
1186 namingViolation (64),
1187 objectClassViolation (65),
1188 notAllowedOnNonLeaf (66),
1189 notAllowedOnRDN (67),
1190 entryAlreadyExists (68),
1191 objectClassModsProhibited (69),
1195 errorMessage LDAPString
1198 AttributeType ::= LDAPString
1199 -- text name of the attribute, or dotted
1200 -- OID representation
1202 AttributeValue ::= OCTET STRING
1204 AttributeValueAssertion ::=
1206 attributeType AttributeType,
1207 attributeValue AttributeValue
1213 SEQUENCE OF CHOICE {
1214 initial [0] LDAPString,
1216 final [2] LDAPString
1220 LDAPString ::= OCTET STRING
1222 maxInt INTEGER ::= 65535
1234 Yeong, Howes & Kille [Page 22]