view Side-By-Side changes
Network Working Group M. Wahl
INTERNET-DRAFT ISODE Consortium
Obsoletes: RFC 1777, RFC 1798 T. Howes
University of Michigan
Netscape Communications Corp.
S. Kille
ISODE Consortium
Expires in six months from 23 February 5 June 1996
Intended Category: Standards Track
Lightweight Directory Access Protocol (v3)
<draft-ietf-asid-ldapv3-protocol-00.txt>
<draft-ietf-asid-ldapv3-protocol-01.txt>
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
2. Abstract
The protocol described in this document is designed to provide access
to directories supporting the X.500 Directories 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 Directory, and protocols, it is
intended to be a complement to the DAP itself. X.500 DAP.
Key aspects of this version of LDAP are:
- All protocol elements of LDAP (RFC 1777) and CLDAP (RFC 1798) are
supported.
- Protocol elements are carried directly over TCP or other transport,
bypassing much of the session/presentation overhead. Connectionless
transport (UDP) is also supported for efficient lookup operations.
- If desired, many Most protocol data elements can be encoded as ordinary strings
(e.g., Distinguished Names).
- Important parameters features of X.500(1993) DAP can be used.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996 are included.
- Referrals to other servers may be returned.
- The protocol may be extended to support bilaterally-defined
operations.
- Several of the service controls may be requested by the client.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
3. Models
Interest in X.500 [1] technology directory technologies in the Internet has lead to
efforts to reduce the high "cost of entry" associated with use of the
technology. these
technologies. This document continues the efforts to define Directory directory
protocol alternatives: it builds heavily on updates the LDAP [2] protocol specification, and allows
adding support for additional X.500(1993) features. new features, including some support for servers
connecting to X.500(1993).
3.1. 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 transmits a protocol request describing the operation to be
performed to a server, which is then responsible for performing the
necessary operations on the Directory. 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, 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. 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 clients or server
implementations: requests servers.
Rrequests and responses for multiple operations may be exchanged by
between a client and servers server in any order, as long as clients provided the client
eventually receive 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 if requested.
Clients may also request that no referrals be returned, in
which case the server must ensure that the operation is performed
against the Directory, directory, or else return an error.
Note that this protocol can be mapped to a strict subset of the
X.500(1993) 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: some server implementations
acting as a gateway to X.500 directories may need to make multiple DAP
requests to perform extended operations.
3.2. Data Model
This section provides a brief introduction to the X.500 data model, as
used by LDAP. Schema rules and other features are not described here.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
The LDAP protocol assumes there is one or more servers which jointly
provide access to a Directory Information Tree. The tree is made up of
entries. Entries have names: one or more values from the entry itself
form its relative distinguished name, which must be unique among all
its siblings. The concatenation of the relative distinguished names
of entries, starting from the immediate subordinate of the unnamed
root of the tree and continuing to a specific entry form's forms that entry's
Distinguished Name, which is unique in the tree. An example of a
Distinguished Name is
<CN=Mark Wahl,
CN=Steve Kille, O=ISODE Consortium, C=GB> C=GB
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
Entries consist of a set of attributes. An attribute is a type with
one or more values associated with that type. values. The attribute type is type, described by an
OID (object identifier) which identifier), governs the maximum number of values
permissible for an attribute of that type in an entry, and the syntax to
which the values must conform. An example of an attribute type is "rfc822Mailbox": the "mail".
There may be one or more values of this
attribute attribute, and they must be IA5
strings.
All the attributes of an entry are mastered together in a single
server. Shadow or cached copies of entries may be held in other
servers, but these cannot be updated directly by users.
3.3. Relationship to X.500
This document defines LDAP in terms of X.500 as an X.500 access
mechanism. An LDAP server should act in accordance with the
X.500(1993) series
3.2.1 Attributes of ITU Recommendations when providing the service.
However, it is not required that Entries
Each entry must have an LDAP server make use objectClass attribute. Values of any X.500
protocols in providing this service: e.g. LDAP can attribute
may be mapped onto any
other Directory system so long as modified by clients, but the X.500 data and service model is
supported in objectClass attribute cannot be
removed. The objectClass attribute specifies the LDAP interface.
3.4. Additional server data requirements
An LDAP server must provide a number object classes of attributes in the root DSE,
that an
entry, which is named along with the zero-length LDAPDN. These attributes
should be retrievable if a client performs a base object search of system and user schema determine the
root. They
permitted attributes of an entry.
Servers should not be included if the client performs a subtree
search starting from the root. The server need not allow the client permit clients to modify these attributes.
The add attributes to an entry unless
those attributes are as follows:
- administratorAddress
This attribute's value is a string containing permitted by the RFC 822 address
of object class definitions, the LDAP server's human administrator. This information may be of
use when tracking down problems user
schema controlling that entry (specified in a distributed directory.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
- currentTime
This attribute's value is a string containing a UTCTime character
value. This attribute need only be present if the server supports
strong subschema subentry), or protected simple authentication. Otherwise if the
are operational attributes known to that server
does not know the current time this attribute should not be present.
The client and used for
administrative purposes.
Entries may wish to use this field to detect whether a strong or
protected bind would fail because contain the client and server clocks are
not sufficiently synchronized. Clients following operational attributes, but if present
should not use this time field
for setting their own system clock. be modifiable by clients:
- binaryName
This attribute's value is creatorsName: the binary ASN.1 encoding string representation of the server's
Distinguished Name. If the server does not have a Distinguished Name
it will not be able to accept strong authentication, and of
the user who added this attribute
should be absent. entry to the directory, if known.
- path
This attribute contains a binary encoding createTimestamp: the GeneralizedTime value of the AF.CertificationPath
data type, with time this entry was
added to the certificate path for directory, if known.
- modifiersName: the server. If string representation of the server
does not have a certificate path Distinguished Name of
the user who last modified this attribute should be absent. entry, if known.
- context
The values modifyTimestamp: the GeneralizedTime value of the time this attribute are entry was
last modified, if known.
- subschemaSubentry: the string representations representation of the Distinguished Names. Each value corresponds to a naming context Name
of the subschema subentry which
this server masters or shadows. If controls the server does not master any
information (e.g. it is an LDAP gateway to a public X.500 Directory) schema for this attribute should be absent. If the server believes it contains
the entire Directory, the attribute should have entry.
- entryName;binary: a single value, and
that value should be the empty string (indicating the null DN DER encoding of the
root).
- altLdapServer
The values of this attribute are URLs Distinguished Name of the
entry.
Servers may implement other LDAP servers operational attributes. Servers which
may be contacted when this
also make use of X.500(1993) protocols should provide support
for the attributes defined in X.501, including administrativeRole,
collectiveExclusions, governingStructureRule, dseType and entryACI.
3.2.2 Subschema Subentry
A server becomes unavailable. If may provide access to one or more subschema subentries to
permit clients to interrogate the schema which is in force for entries
in the directory.
A server
does not know of any other LDAP servers which could be used this
attribute should masters or shadows entries and permits clients to modify
these entries must implement subschema subentries.
The following two attributes must be absent. Clients should cache this information present in
case their preferred LDAP server later becomes unavailable. a subschema subentries:
- altX500Server
The values objectClasses: each value of this attribute are encoded with the AccessPoint93
syntax. They are specifies an object class
known to the access points server.
- attributeTypes: each value of X.500 DSAs which could be
contacted when this server becomes unavailable. If this server does
not know of any X.500 DSAs this attribute should specifies an attribute
type known to the server.
Other attributes may be absent. Clients
which support DAP should cache this information present in case subschema subentries.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
These attributes of subschema subentries may be retrieved by requesting
a baseObject search of their
preferred LDAP server later becomes unavailable.
- supportedExtension
The values name, with filter set to a test for the
presence of this attribute are the string representations objectClass attribute. Clients should not expect that
subschema subentries will be returned in searches with other settings of
OBJECT IDENTIFIERs,
scope or filter.
3.3. Relationship to X.500
This document defines LDAP in the dotted decimal form. Each value is the
name terms of X.500 as an extended request which this X.500 access
mechanism. An LDAP server supports (see section
4.11). If should act in accordance with the server does
X.500(1993) series of ITU Recommendations when providing the service.
However, it is not support required that an LDAP server make use of any extended operations X.500
protocols in providing this
attribute should service, e.g. LDAP can be absent.
The ASN.1 type DistinguishedName is defined in [6], and mapped onto any
other directory system so long as the type
CertificationPath X.500 data and service model is defined in [12]. They are included
supported in Appendix B
for reference.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
4. Elements of Protocol
The the LDAP protocol interface.
3.4. Server-specific Data Requirements
An LDAP server must provide information about itself and other
information that is described using Abstract Syntax Notation 1 [3]. It specific to each server. This is typically transferred using represented as a subset
number of attributes located in the Basic Encoding Rules.
In order to support future extensions to this protocol, clients and
servers root DSE (DSA-Specific Entry),
that which is named with the zero-length LDAPDN. These attributes
should ignore elements be retrievable if a client performs a base object search of SEQUENCEs whose tags they do not
recognize.
4.1. Common Elements
This section describes the LDAPMessage envelope PDU format, as well as
data type definitions which
root, however they are used in the protocol operations.
4.1.1. Message Envelope
For subject to access control restrictions.
They should not be included if the purposes of protocol exchanges, all protocol operations are
encapsulated in client performs a common envelope, subtree search
starting from the LDAPMessage, which is root. The server need not allow the client to modify
these attributes.
Additional attributes may be defined
as follows:
LDAPMessage ::= SEQUENCE {
messageID MessageID,
cldapUserName LDAPDN OPTIONAL,
protocolOp CHOICE {
bindRequest BindRequest,
bindRespBasic BindResponseBasic,
bindRespExtd BindResponseExtended,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
searchResFull SearchResultFull,
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 } }
MessageID ::= INTEGER (0 .. maxInt )
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-- by later documents or by bilateral
agreement. These attributes are currently defined:
- administratorAddress: This attribute's values are string containing
the addresses of the LDAP server's human administrator. This
information may be extended to 9223372036854775807 (2^^63 - 1) --
The function of use when tracking down problems in an Internet
distributed directory. For simplicity the LDAPMessage is syntax of the values are
limited to provide being URLs of the mailto form with an envelope containing
common fields required in all protocol exchanges. At this time the
only common fields are the message ID and cldapUserName.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
The message ID is required to have a value different from the values RFC 822 address:
"mailto:user@domain". Future versions of
any this protocol may permit other requests outstanding in the LDAP session
forms of which this
message is addresses.
- currentTime: This attribute has a part. Typically single value, a client may increment string containing a counter for each
request. The message ID value must
GeneralizedTime character string. This attribute need only be echoed in all LDAPMessage
envelopes encapsulating responses corresponding to the request
contained in present
if the LDAPMessage in which server supports LDAP strong or protected simple authentication.
Otherwise if the message ID value was
originally used.
The cldapUserName identifies server does not know the requesting user for this message. It
is only current time, or does not
choose to present if it to clients, this LDAPMessage is carried in attribute need not be present. The
client may wish to use this value to detect whether a connectionless
transport protocol, such as UDP. This strong or
protected bind is described in section 5.1.3.
When failing because the LDAP session is carried in a connection-oriented transport
protocol client and server clocks are not
sufficiently synchronized. Clients should not use this time field must be absent.
4.1.2. String
The LDAPString for
setting their own system clock.
- serverName;binary: This attribute's value is a notational convenience to indicate that, although
strings the binary representation
of LDAPString type encode as OCTET STRING types, the legal
character set in such strings is limited to ASN.1 DER encoding of the IA5 character set.
LDAPString ::= OCTET STRING
4.1.3. server's Distinguished Name and Relative Distinguished Name
An LDAPDN and a RelativeLDAPDN are respectively defined to be Name. If the
representation of a Distinguished Name and
server does not have a Relative Distinguished Name after encoding according it will not be able to the specification in [4], such that
<distinguished-name> ::= <name>
<relative-distinguished-name> ::= <name-component>
where <name> accept
strong authentication, and <name-component> are as defined in [4].
LDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
4.1.4. Attribute Type
An AttributeType takes on as its value this attribute should be absent. However the textual string associated
with that AttributeType in its specification. If
presence of this string is attribute does not
known, guarantee that the AttributeType should take server will be
able to perform strong authentication. If the ASCII representation of its
OBJECT IDENTIFIER, server acts as decimal digits with components separated by
periods, e.g. "2.5.4.10". The attribute type strings which must a gateway
to more than one X.500 DSA capable of strong authentication, there may
be
supported are described in section [5].
AttributeType ::= LDAPString multiple values of this attribute, one per DSA.
- certificationPath;binary: This data type describes attribute contains a list binary DER
encoding of 0 or more an AF.CertificationPath data type, which is the certificate
path for a server. If the server does not have a certificate path this
attribute types. Clients
and servers should be prepared to accept a list of many hundreds of
attribute types.
AttributeTypeList ::= SEQUENCE SIZE (0..maxInt) OF AttributeType absent.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
4.1.5. Attribute Value
A field
- namingContexts: The values of type AttributeValue takes on as its value an octet this attribute are the string
encoding
representations of Distinguished Names. Each value corresponds to a Directory AttributeValue type. The definition of these
string encodings for different Directory AttributeValue types may be
found in companions to
naming context which this document that define server masters or shadows. If the encodings of
various attribute syntaxes such as [5].
AttributeValue ::= OCTET STRING
Note that there server does
not master any information (e.g. it is no defined limit on the size of an LDAP gateway to a public X.500
directory) this encoding; thus
PDUs including multi-megabyte photograph attributes may attribute should be returned. absent. If the client has limited memory or storage capabilities server believes it may wish to
set the attrSizeLimit field when invoking a search operation.
4.1.6. Attribute Value Assertion
The AttributeValueAssertion type definition is similar to
contains the one in entire directory, the X.500 Directory standards. It contains an attribute type and should have a
equality matching assertion suitable for single value,
and that type.
AttributeValueAssertion ::= SEQUENCE {
attributeType AttributeType,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
For all the standard attributes, the assertion value syntax is should be the
same as empty string (indicating the value syntax.
4.1.7. Attribute
An attribute consists null DN of a type and one or more the
root).
- subschemaSubentry: The values of that type.
Attribute ::= SEQUENCE {
type AttributeType,
vals SET SIZE (1..maxInt) OF AttributeValue }
Clients and servers should be prepared this attribute are the string
representations of Distinguished Names. Each value corresponds to accept a
subschema subentry, which is an entry in which the server makes
available attributes with
many hundreds of values.
4.1.8. Matching Rule Identifier
An X.501(1993) Matching Rule specifying the schema. (This is identified described in
section 3.2.2). If the LDAP protocol by server does not master or shadow entries and
does not know the
ASCII representation locations of its OBJECT IDENTIFIER, as decimal digits with
components separated by periods, e.g. "1.3.6.1.4.1.453.33.33".
MatchingRuleId ::= LDAPString
4.1.9. Result Message schema information, this attribute should
be absent. If the server holds all the directory under a single set of
schema rules, there will be one attribute value (and a single subentry,
which could be located anywhere in the directory hierarchy). If the
server holds master or shadow copies of directory entries under one or
more schema rules, there may be any number of values of this attribute.
- altLdapServer: The LDAPResult is values of this attribute are URLs of other LDAP
servers which may be contacted when this server becomes unavailable. If
the construct server does not know of any other LDAP servers which could be used
this attribute should be absent. Clients should cache this information
in case their preferred LDAP server later becomes unavailable.
- altX500Server: The values of this protocol to return
success or failure indications from servers attribute are encoded with the
AccessPoint93 syntax. They are the access points of X.500 DSAs which
could be contacted when this server becomes unavailable. If this server
does not know of any X.500 DSAs this attribute should be absent.
Servers implemented as LDAP gateways to clients. In response X.500 DAP may permit management
clients to various requests, servers will return responses containing fields modify the values of type LDAPResult to indicate this attributes.
- supportedExtension: The values of this attribute are the final status string
representations of a protocol
operation request.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
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
-- 14-15 unused --
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
isLeaf (35),
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),
resultsTooLarge (70), -- cl only
affectsMultipleDSAs (71), -- new
-- 72-79 unused --
other (80) },
matchedDN LDAPDN,
errorMessage LDAPString (SIZE (0..maxInt)),
referral [3] Referral OPTIONAL,
matchedSubtype [4] AttributeType OPTIONAL }
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
The errorMessage field of this construct may, at OBJECT IDENTIFIERs, in the servers option,
be used to return an ASCII string containing a textual, human-readable
error diagnostic. As this error diagnostic dotted decimal form.
Each value is not standardized,
implementations should not rely on the values returned. name of an extended request which this server supports
(see section 4.11). If the server
chooses does not to return a textual diagnostic, the errorMessage field of
the LDAPResult type support any extended
operations this attribute should contain a zero length string.
For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax,
isLeaf, be absent.
The ASN.1 type DistinguishedName is defined in [6], and aliasDereferencingProblem, the matchedDN field type
CertificationPath is set to
the name of the lowest entry (object or alias) defined in the DIT that was
matched and [12].
4. Elements of Protocol
The LDAP protocol is described using Abstract Syntax Notation 1 [3]. It
is typically transferred using a truncated form of the name provided or, if an alias
has been dereferenced, subset of the resulting name in a Search or Compare
result. The matchedDN field Basic Encoding Rules.
In order to support future extensions to this protocol, clients and
servers should be set ignore elements of SEQUENCEs whose tags they do not
recognize. Note that unlike X.500, each change to a NULL DN (a zero length
string) in all other cases.
When the resultCode is compareTrue or compareFalse the matchedSubtype
field LDAP protocol
will contain have a different version number.
4.1. Common Elements
This section describes the LDAPMessage envelope PDU format, as well as
data type name of the attribute whose value matched
the ava definitions which are used in the Compare operation.
4.1.10. Referral
The referral field is present in an LDAPResult if protocol operations.
4.1.1. Message Envelope
For the
LDAPResult.resultCode field value is referral. It contains a reference
to another server (or set purposes of servers) protocol exchanges, all protocol operations are
encapsulated in a common envelope, the LDAPMessage, which may be accessed via LDAP
or other protocols.
Referral is defined
as follows:
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
LDAPMessage ::= SEQUENCE {
servers [0] SET SIZE (1..maxInt) OF LDAPURL
messageID MessageID,
cldapUserName LDAPDN OPTIONAL,
protocolOp CHOICE {
bindRequest BindRequest,
bindReqContinue BindContinuationRequest,
bindRespBasic BindResponseBasic,
bindRespExtd BindResponseExtended,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
searchResFull SearchResultFull,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
resumeRequest ResumeRequest,
resumeError ResumeError,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse } }
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
The servers field contains a list of URLs of servers, and each must be
capable function of processing the operation and presenting a consistent view LDAPMessage is to clients. URLs for servers implementing the LDAP provide an envelope containing
common fields required in all protocol exchanges. At this time the
only common fields are
written according to [9].
LDAPURL ::= LDAPString the message ID and cldapUserName.
The ASN.1 type Exclusions message ID is defined required to have a value different from the values of
any other requests outstanding in [10], and the LDAP session of which this
message is included in
Appendix B a part. Typically a client may increment a counter for reference. each
request. The server should place its own URL message ID value must be echoed in all LDAPMessage
envelopes encapsulating responses corresponding to the
referringServer field, as this information may be useful for tracing
referral loops and inconsistencies.
4.2. Bind Operation request
contained in the LDAPMessage in which the message ID value was
originally used.
The function of cldapUserName identifies the Bind Operation requesting user for this message. It
is to initiate only present if this LDAPMessage is carried in a protocol connectionless
transport protocol, such as UDP. This is described in section 5.1.3.
When the LDAP session
between is carried in a client and connection-oriented transport
protocol this field must be absent.
4.1.2. String Types
The LDAPString is a server, and notational convenience to allow the authentication indicate that, although
strings of LDAPString type encode as OCTET STRING types, the
client to the server. The Bind Request legal
character set in such strings is defined to be the Basic Multilingual
Plane (BMP) of UCS. These are encoded following the UTF-8 algorithm.
Note that in the UTF-8 algorithm, characters which are the same as follows:
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice,
serviceControls [7] Controls OPTIONAL }
AuthenticationChoice ::= CHOICE {
simple [1] OCTET STRING,
krbv42LDAP [2] OCTET STRING,
krbv42DSA [3] OCTET STRING,
protected [4] ProtectedPassword,
strong [5] StrongCredentials,
nonstandard [6] NonstandardCredentials }
ProtectedPassword ::= SEQUENCE {
time1 [0] UTCTime OPTIONAL,
time2 [1] UTCTime OPTIONAL,
random1 [2] BIT STRING OPTIONAL,
random2 [3] BIT STRING OPTIONAL,
protected [4] OCTET STRING }
StrongCredentials ::= SEQUENCE {
certification-path [0] AF.CertificationPath OPTIONAL,
bind-token [1] DAS.Token }
NonstandardCredentials ::= SEQUENCE {
authMechanism [0] LDAPString,
authToken [1] OCTET STRING }
Controls ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
criticality [0] BOOLEAN DEFAULT FALSE,
control ServiceControl }
ServiceControl ::= CHOICE {
referringServer [0] LDAPURL,
chainingProhibited [1] BOOLEAN,
scopeOfReferral [2] ENUMERATED {
any(-1),
dmd(0),
country(1) },
referToLDAPServers [3] BOOLEAN,
referToDAPServers [4] BOOLEAN,
preferredSyntax [5] SyntaxEncoding,
extendedControl [6] ExtendedControl }
SyntaxEncoding ::= SEQUENCE {
attributeType [0] AttributeType,
encodingPreference [1] SyntaxName }
SyntaxName ::= LDAPString
ExtendedControl ::= SEQUENCE {
controlName [0] LDAPString,
controlValue [1] OCTET STRING }
printable ASCII (0020 through 007F) are represented as that same ASCII
character in a single byte.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
Parameters of the Bind Request are:
- version: A version number indicating
LDAPString ::= OCTET STRING
The LDAPOID is a notational convenince to indicate that the version permitted
value of the protocol to
be used in this protocol session. This document describes version
3 of the LDAP protocol. Note that there string is no version negotiation, a dotted-decimal representation of an OBJECT
IDENTIFIER.
LDAPOID ::= OCTET STRING
4.1.3. Distinguished Name and Relative Distinguished Name
An LDAPDN and a RelativeLDAPDN are respectively defined to be the client should just set this parameter
representation of a Distinguished Name and a Relative Distinguished
Name after encoding according to the version it
desires. The client may request version 2, specification in which case [4], such that
<distinguished-name> ::= <name>
<relative-distinguished-name> ::= <name-component>
where <name> and <name-component> are as defined in [4]. Only the server single
line representation should implement only the protocol be used, with comma as described in [2], by NOT
returning:
- BindResponseExtended in response to this request,
- result codes referral, adminLimitExceeded,
unavailableCriticalExtension,
resultsTooLarge or affectsMultipleDSAs,
- referral or matchedSubtype in LDAPResult,
- fromEntry in SearchResultEntry,
- SearchResultReference in response to searches.
- name: The name of component separator.
LDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
4.1.4. Attribute Type and Description
An AttributeType takes on as its value the Directory object textual string associated
with that the client wishes to
bind as. AttributeType in its specification. This field may string must begin
with a letter, and only contain ASCII letters and digit characters.
If this string is not known, the AttributeType should take on the ASCII
representation of its OBJECT IDENTIFIER, as decimal digits with
components separated by periods, e.g., "2.5.4.10". The attribute type
strings which must be supported are described in section [5].
AttributeType ::= LDAPString
An AttributeDescription is a null value (a zero length
string) for superset of the purposes definition of anonymous binds.
- authentication: information used to authenticate the name, if any,
provided in
AttributeType. It has the Bind Request.
- serviceControls: same ASN.1 definition, but allows additional requests
parameters to be
AttributeDescription ::= LDAPString
A value of AttributeDescription is based on the client may make about following BNF:
<AttributeDescription> ::= <AttributeType> [ ";" <options> ]
<options> ::= <binary-option>
<binary-option> ::= "binary"
If the
protocol.
Upon receipt of a Bind Request, a protocol server will authenticate "binary" option is present, this overrides any printable
encoding representation defined for that attribute. Instead the requesting client if necessary, and attempt
attribute is to set up be transferred as a protocol
session with that client. BER-encoded binary value.
The server will then return data type "AttributeDescriptionList" describes a Bind Response list of 0 or more
attribute types. Clients and servers should be prepared to the client indicating the status accept a
list of many hundreds of attribute types.
AttributeDescriptionList ::= SEQUENCE SIZE (0..maxInt) OF
AttributeDescription
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
4.1.5. Attribute Value
A field of type AttributeValue takes on as its value an octet string
encoding of the session setup request.
Unlike LDAP v2, the client need not send a Bind Request X.500 Directory AttributeValue type. The definition of
these string encodings for different syntaxes and types may be
found in companions to this document, such as [5].
AttributeValue ::= OCTET STRING
Note that there is no defined limit on the first
PDU size of this encoding; thus
PDUs including multi-megabyte attributes (e.g. photographs) may be
returned. If the connection. The client has limited memory or storage capabilities it
may request any operations and wish to set the
server should treat these as unauthenticated. If attrSizeLimit field when invoking a search operation.
4.1.6. Attribute Value Assertion
The AttributeValueAssertion type definition is similar to the server requires one in
the X.500 directory standards. It contains an attribute type and a
equality matching assertion suitable for that type.
AttributeValueAssertion ::= SEQUENCE {
attributeType AttributeType,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
For all the client bind first, attributes described in [5], the server should reject any request other
that binding or unbinding with assertion value syntax is
the "operationsError" result. If same as the
client did not bind before sending value syntax.
4.1.7. Attribute
An attribute consists of a request type and receives an
operationsError, it should close one or more values of that type.
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET SIZE (1..maxInt) OF AttributeValue }
4.1.8. Matching Rule Identifier
An X.501(1993) Matching Rule is identified in the connection, reopen it and begin
again LDAP protocol by first sending a PDU with a Bind Request. This will aid in
interoperating with LDAPv2 servers.
Clients should not send more than one Bind Request on a connection.
4.2.1 Authentication
The "simple" authentication option provides minimal authentication
facilities, with the contents
ASCII representation of its OBJECT IDENTIFIER, as decimal digits with
components separated by periods, e.g. "1.3.6.1.4.1.453.33.33".
MatchingRuleId ::= LDAPOID
4.1.9. Result Message
The LDAPResult is the authentication field consisting
only of a cleartext password. This option should also be construct used when
unauthenticated in this protocol to return
success or anonymous binds are failure indications from servers to be performed, with the field clients. In response
to various requests, servers will return responses containing fields
of type LDAPResult to indicate the final status of a zero length string in such cases. protocol
operation request.
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
Kerberos version 4 [14] 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".
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
unableToProceed (13), -- new
-- 14-15 unused --
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
overSpecifiedFilter (22), -- new
-- 23-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
isLeaf (35),
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),
resultsTooLarge (70), -- cl only
affectsMultipleDSAs (71), -- new
-- 72-79 unused --
other (80) },
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL,
matchedSubtype [4] AttributeType OPTIONAL }
The suggested service name for authentication to errorMessage field of this construct may, at the DSA servers option,
be used to return an ASCII string containing a textual, human-readable
error diagnostic. As this error diagnostic is "x500dsa".
In both cases, not standardized,
implementations should not rely on the suggested instance name for values returned. If the service is server
chooses not to return a textual diagnostic, the name errorMessage field of
the host on which LDAPResult type should contain a zero length string.
For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax,
isLeaf, and aliasDereferencingProblem, the service matchedDN field is running. Of course, set to
the actual
service names and instances will depend on what is entered name of the lowest entry (object or alias) in the
local kerberos principle database.
The ProtectedPassword authentication option allows DIT that was
matched and is a hash truncated form of the
password, combined optionally with name provided or, if an alias
has been dereferenced, of the current time and resulting name in a random
number, to Search or Compare
result. The matchedDN field should be sent set to a NULL DN (a zero length
string) in all other cases.
When the DSA. The protected resultCode is compareTrue the matchedSubtype field contains may contain
the hash
value.
Strong authentication to type name of the Directory can be accomplished using attribute whose value matched the
strong credentials option. ava in the
Compare operation.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
4.1.10. Referral
The ASN.1 type "CertificationPath" referral field is
defined present in [12], and an LDAPResult if the ASN.1 type "Token"
LDAPResult.resultCode field value is defined in [13]. They
are included in Appendix B for Reference.
Nonstandard authentication referral. It contains a reference
to the Directory can another server (or set of servers) which may be performed using the
nonstandard credentials option. accessed via LDAP
or other protocols.
Referral ::= SEQUENCE SIZE (1..maxInt) OF LDAPURL
The authMechanism must be the
dotted-decimal printable representation referral contains a list of an OBJECT IDENTIFIER URLs [14] of that
authentication mechanism: for interoperability servers, any of which the full decimal format
client could contact to continue the request. Each server must be used. The authToken is arbitrary information
capable of processing the operation and presenting a form
defined by that authentication mechanism, encoded in an OCTET STRING.
4.2.1.1. Strong Credentials Signature Algorithm
It is recommended for interoperability that if strong authentication
is consistent view to be performed, then if
the server's or client's certificates
contain RSA public keys client. URLs for servers implementing the PKCS md5WithRSAEncryption
(1.2.840.113549.1.1.4) algorithm should be used.
4.2.2. Service Controls
Service Controls LDAP protocol are requests made by written
according to [9]; other kinds of URLs may be returned so long as the client which affect its
interaction with the server. Controls are not saved after a session
unbinds or disconnects abruptly, and do not affect other sessions to
this or same
information could be received using other servers. protocols.
LDAPURL ::= LDAPString
If the server is has not capable of setting one or more requested controls,
it should set as many as possible. If any information of where to progress the controls which the
server could not set are marked as critical, operation that
it should could return the
unavailableCriticalExtension error.
The referringServer control is non-critical. This field contains the URL
of another server which referred an operation to this server. This control
should only be present if the connection is being made only to process a
referral. If the connection will be held open to handle referrals from
other servers this control should be omitted.
If the chainingProhibited field is set to TRUE, the server set the
chainingProhibited service control on any DAP requests client, it makes. If
the referToLDAPServers or returnToDAPServers fields are set to TRUE,
the server should not return a referral, but
instead return referrals to clients. Otherwise if neither
of these are set to TRUE the server should itself follow referrals.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
If the referToLDAPServers field is set to TRUE, result code unableToProceed.
4.2. Bind Operation
The function of the server Bind Operation is permitted
by the client to return referrals to other LDAP servers.
If the referToDAPServers field is set allow authentication information
to TRUE, the server is permitted
by be exchanged between the client and server, and optionally allow
session-wide parameters to return referrals to other X.500 servers which accept
incoming DAP associations. be set.
The preferredSyntax fields control how the server should in Search
Responses return values of attributes, Bind Request is defined as follows:
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice,
serviceControls [7] Controls OPTIONAL }
AuthenticationChoice ::= CHOICE {
simple [1] OCTET STRING,
-- 2 and how 3 reserved
protected [4] ProtectedPassword,
strong [5] StrongCredentials,
otherkind [6] OtherCredentials }
ProtectedPassword ::= SEQUENCE {
time1 [0] UTCTime OPTIONAL,
time2 [1] UTCTime OPTIONAL,
random1 [2] BIT STRING OPTIONAL,
random2 [3] BIT STRING OPTIONAL,
protected [4] OCTET STRING }
StrongCredentials ::= SEQUENCE {
certification-path [0] AF.CertificationPath OPTIONAL,
bind-token [1] DAS.Token }
OtherCredentials ::= SEQUENCE {
authMechanism [0] LDAPOID,
authToken [1] OCTET STRING }
Controls ::= SEQUENCE OF SEQUENCE {
controlType LDAPString,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING }
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
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 should just set this parameter to the version it
desires. The client may request version 2, in which case the server
should interpret
values presented implement only the protocol as described in Compare, Add and Modify arguments. [2].
- name: The attribute
field is name of the attribute whose syntax preference is being noted, if directory object that the client wishes to
bind as. This field is may take on a null value (a zero length string
string) for the preference applies to all attributes.
The following encodingPref values have purposes of anonymous binds, or when authentication
has been defined: performed at a lower layer.
- The zero-length empty string corresponds authentication: information used to authenticate the default syntax for
the server. It may be binary, readable or something else for each
attribute.
- The string "binary" requests that the binary BER encoding be used for
the selected (or all) attributes. Note that Attribute Types, as
well as distinguished names transferred as protocol elements (not as
attribute values) are still carried name, if any,
provided in string representations. the Bind Request.
- The string "readable" serviceControls: additional requests that printable encodings be used for the selected attributes, and that IA5 character sets be used where
possible. If client may make about the attribute field is
protocol.
Upon receipt of zero length this requests the a Bind Request, a protocol server to encode unrecognized attributes using will authenticate
the "Readable"
default encoding.
Subsequent documents may define additional encoding preference values
to support internationalization.
The extendedControl is used to exchange bilaterally-defined information
from a requesting client if necessary, and attempt to set up a server. The controlName must be the dotted-decimal
printable representation of an OBJECT IDENTIFIER of protocol
session with that control: for
interoperability the full decimal format must be used. client. The
controlValue is arbitrary information of server will then return a form defined by that
control, encoded in an OCTET STRING.
4.2.3. Bind Response
The Bind Response will be one of
to the following, either
BindResponseBasic or BindResponseExtended.
BindResponseBasic ::= [APPLICATION 1] LDAPResult
A BindResponseBasic consists simply of an indication from client indicating the server status of the status session setup request.
Unlike LDAP v2, the client need not send a Bind Request in the first
PDU of the client's connection. The client may request for any operations and the initiation of
server should treat these as unauthenticated (or authentication may have
already occured at a protocol
session. lower layer). If the server requires that the
client bind was successful, first, the resultCode will be success,
otherwise it will be one of:
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
operationsError
protocolError
authMethodNotSupported
strongAuthRequired
referral
inappropriateAuthentication
invalidCredentials
unavailable server should reject any request other that
binding or unbinding with the "operationsError" result. If the
client receives a BindResponseBasic response where the
resultCode was did not success, bind before sending a request and receives an
operationsError, it should close the connection as the
server connection, reopen it and begin
again by first sending a PDU with a Bind Request. This will aid in
interoperating with LDAPv2 servers.
Clients may send multiple bind requests on an association.
Authentication or controls from earlier binds should subequently be unwilling
ignored.
4.2.1 Authentication
If no authentication is to accept further operations.
A BindResponseExtended will only be returned if performed, or has been performed at a
lower layer, then the bind was successful
and additional information is to simple authentication option should be returned to chosen,
and the client.
BindResponseExtended ::= [APPLICATION 17] SEQUENCE {
serverURL [0] LDAPURL,
serverCreds AuthenticationChoice } password be of zero length.
The serverURL contains "simple" authentication option provides minimal authentication
facilities, with the URL contents of this LDAP server. the authentication field consisting
only of a cleartext password.
The serverCreds ProtectedPassword authentication option allows a hash of the client to authenticate
password, combined optionally with the server current time and a random
number, to which it is
communicating.
4.3. Unbind Operation be sent to the DSA. The function of protected field contains the Unbind Operation is hash
value.
Strong authentication to terminate a protocol
session. the directory can be accomplished using the
strong credentials option. The Unbind Operation ASN.1 type "CertificationPath" 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 in [12], and the protocol session ASN.1 type "Token" is terminated. Upon receipt defined in [13]. They
are included in Appendix B for reference.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
Other kinds of an UnbindRequest, a protocol server
may assume that authentication to the requesting client has terminated directory can be performed using
the session and other credentials option. The authMechanism must be the
dotted-decimal printable representation of an OBJECT IDENTIFIER of that all outstanding requests may
authentication mechanism: for interoperability the full decimal format
must be discarded.
4.4. Search Operation used. The Search Operation allows authToken is arbitrary information of a client to request form
defined by that a search authentication mechanism, encoded in an OCTET STRING.
4.2.1.1. Strong Credentials Signature Algorithm
It is recommended for interoperability that if strong authentication
is to be
performed on its behalf performed, then if the server's or client's certificates
contain RSA public keys the PKCS md5WithRSAEncryption
(1.2.840.113549.1.1.4) algorithm should be used.
4.2.2. Service Controls
Service Controls are requests made by a the client which affect its
interaction with the server. The Search Request Controls are not saved after a session
unbinds or disconnects abruptly, and do not affect other sessions to
this or other servers.
If the server is defined not capable of setting one or more requested controls,
it should set 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),
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
typesOnly BOOLEAN,
filter Filter,
attributes AttributeTypeList,
matchedOnly [0] BOOLEAN DEFAULT FALSE,
sortKeys [1] SortKeyList OPTIONAL,
reverseSort [2] BOOLEAN DEFAULT FALSE,
modifyRightsReq [3] BOOLEAN DEFAULT FALSE,
extraAttributes [4] BOOLEAN DEFAULT FALSE,
attrSizeLimit [5] INTEGER OPTIONAL,
subentries [6] BOOLEAN DEFAULT FALSE,
dontUseCopy [7] BOOLEAN DEFAULT FALSE }
SortKeyList ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
attributeType AttributeType,
orderingRule [0] MatchingRuleId OPTIONAL,
startFrom [1] AssertionValue OPTIONAL,
endWith [2] AssertionValue OPTIONAL }
Filter ::= CHOICE {
and [0] SET SIZE (1..maxInt) OF Filter,
or [1] SET SIZE (1..maxInt) OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeType,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeType,
substrings SEQUENCE SIZE (1..maxInt) OF CHOICE {
initial [0] LDAPString, many as possible. If any [1] LDAPString,
final [2] LDAPString } }
MatchingRuleAssertion ::= SEQUENCE {
matchingRules [1] SET SIZE (0..maxInt) OF MatchingRuleId,
type [2] AttributeType,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN }
Parameters of the Search Request are:
- baseObject: An LDAPDN that is the base object entry relative to controls 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
server could not set are identical to the
semantics of the scope field in the Directory Search Operation.
- derefAliases: An indicator marked as to how alias objects critical, it should be
handled in searching. The semantics of return the possible values of
this
unavailableCriticalExtension error.
The controlType field are:
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
neverDerefAliases: do not dereference aliases must either be a string defined in searching this section,
or in locating the base object of the search;
derefInSearching: dereference aliases in subordinates a dotted-decimal representation of
the base object in searching, but not an OBJECT IDENTIFIER. This will
aid in locating preventing conflicts between privately-defined control extensions.
The following controls have been defined:
- referringServer
- chainingProhibited
- supportedReferral
- useAliasOnUpdate
- manageDsaIT
- preferredLanguage
The referringServer control is always non-critical. The value field
contains the
base object URL of another server which referred an operation to this
server. This control should only be present if the search;
derefFindingBaseObject: dereference aliases in locating connection is being
made only to process a referral. If the base object of connection will be held open to
handle referrals from multiple servers this control should be omitted.
The chainingProhibited control may be critical or non-critical at the search, but
clients request. The value should be an empty string. If present, the
server should not when searching
subordinates of contact any other servers, if it would be possible to
instead return to the base object;
derefAlways: dereference aliases both in searching and in
locating client a referral. If the base object of server is a gateway to
X.500, it should set the search.
- sizelimit: A sizelimit that restricts chainingProhibited service control on any
DAP/DSP requests it makes.
The supportedReferral control is always non-critical. The field is
a string name of a protocol which the maximum number client implements. The name of entries
to
the protocol may be returned as "ldap", "cldap", "dap", or any IANA-assigned protocol
name or URL mechanism. If this control is present, a result of server should
return a referral rather than chain to another server.
The useAliasOnUpdate control may be critical or non-critical at the search. A
clients request. The value of 0 in this
field indicates that no sizelimit restrictions are in effect for
the search.
- timelimit: A timelimit that restricts should be an empty string. If present, the maximum time (in seconds)
allowed for a search. A value
server should permit alias names to be used as components of 0 in this field indicates that no
timelimit restrictions are a
Distinguished Name in effect for Add, Modify and Delete operations. If the search.
- typesOnly: An indicator as server
is a gateway to whether search results X.500, it 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 set the useAliasOnUpdate critical
extensions on any DAP/DSP AddEntry, ModifyEntry and values to RemoveEntry requests
it makes.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
The manageDsaIT control is always critical. The value should be returned.
- filter: A filter that defines an
empty string. If present, the conditions that chainingProhibited control must also be fulfilled
in order for the search to match a given entry. The and, or
present and not
choices may be used to form boolean combinations of filters.
- attributes: A list of critical. This control affects the attributes from each entry found as a
result name resolution behavior
of the search server to be returned. An empty list signifies that
all attributes from each entry found in the search are permit a manager to be
returned.
- matchedOnly: read and modify knowledge references
and other server-specific attributes. If this field the server is set a gateway to TRUE, then in search results if
there are multivalued attributes where some but not all of
X.500, it should set the values
contributed to the search filter returning TRUE via filters other
than equality or present, then the values which did not contribute
are not returned in the entry attribute list.
- sortKeys: If this field is present, then it specifies one or more
attribute types and matching rules, and manageDsaIT critical extension, as well as the returned entries should
be sorted in order based
appropriate common arguments, on these types. any DAP/DSP requests it makes.
The preferredLanguage control is always non-critical. The startFrom and endWith assertion values specify a range of entries
which are to be returned. If an entry matches a specified sortKey but
with a value before the startFrom assertion or after the endWith
assertion, that entry is not returned an
ISO 646 language code (such as a result.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
If "EN" for English). This control advises
the server what language should be used for returned attribute values and
error messages. It does not recognize any affect character sets; BMP is always used.
4.2.3. Bind Response
The Bind Response will be one of the attribute types, or the
ordering rule associated with an attribute type is not applicable, following, either
BindResponseBasic or
none BindResponseExtended.
BindResponseBasic ::= [APPLICATION 1] LDAPResult
A BindResponseBasic consists simply of an indication from the attributes in server of
the search responses are status of these types,
then the sortKeys field is ignored and result entries are returned
in random order.
Support client's request for this field is optional, and clients should expect that
not all servers will implement result sorting.
- reverseSort: the initiation of a protocol
session. If this field is set to TRUE and the sortKeys field is
also present, then bind was successful, the entries resultCode will be presented in reverse sorted
order.
- modifyRightsReq: If this field is set to TRUE and the scope field is
set to baseObject, then success,
otherwise it will be one of:
operationsError
protocolError
authMethodNotSupported
strongAuthRequired
referral
inappropriateAuthentication
invalidCredentials
unavailable
unavailableCriticalExtension
If the client requests that receives a BindResponseBasic response where the modification
rights for
resultCode was not success, it should close the entry connection as the
server will be included unwilling to accept further operations.
The BindResponseExtended is used to provide additional information
in the search result. Support bind response, for either a successful or unsuccessfull
bind operation.
BindResponseExtended ::= [APPLICATION 17] SEQUENCE {
result [0] LDAPResult,
serverURL [1] LDAPURL OPTIONAL,
serverCreds [2] AuthenticationChoice OPTIONAL,
supportedExtns [3] SEQUENCE OF LDAPString,
unsupportedCtls [4] SEQUENCE OF LDAPString }
The serverURL contains the URL of this field is optional, and clients should expect that not all
servers will implement returning modify rights.
- extraAttributes: If this field is present and set to TRUE then
all operational attributes are requested LDAP server. The serverCreds
allows the client to be returned as well.
Note that specific operational attributes may instead be listed in authenticate the attributes field. Servers are permitted server to ignore extraAttributes
if returning this information is prohibited by security policy.
Clients should note that many operational attributes are not
modifiable.
- attrSizeLimit: If this field which it is present, then if
communicating. The supportedExtns contains the size in bytes names of an attribute service
controls and all its values extended operations which would be returned in a
result entry exceeds this size in bytes, then the attribute is not
included in server supports. The
unsupportedCtls names the result and service controls which the incompleteEntry field is set to TRUE.
- subentries: if present and set to TRUE, the server should ignore
ordinary entries and only perform the search against subentries. If client requested
but the server was not support subentries and this field able to set.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
4.2.4 Bind Continuation
The BindContinuationRequest is TRUE it should
not do any searching, and either return an error (protocolError) or
an empty result.
- dontUseCopy: if present used when a "challenge-response" style
of authentication is to be performed. The client will initially send a
BindRequest, and set will receive a BindResponseExtended. The client may
then send a BindContinuationRequest to TRUE, only the supply additional information
as part of a single authentication process. The server which holds will reply to
the master copy BindContinuationRequest with a BindResponseExtended.
BindContinuationRequest ::= [APPLICATION 19] SEQUENCE {
otherkind [6] OtherCredentials }
4.3. Unbind Operation
The function of the entry Unbind Operation is permitted to perform the filtering
and attribute selection. terminate a protocol
session. The results 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 search attempted by the server upon 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. Search Request are returned in Operation
The Search Responses, which are LDAP
messages containing either SearchResultEntry, SearchResultReference,
SearchResultDone or SearchResultFull data types.
SearchResultEntry 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 4] 3] SEQUENCE {
objectName
baseObject LDAPDN,
attributes PartialAttributeList,
modifyRights [2] ModifyRights OPTIONAL,
incompleteEntry [3] BOOLEAN DEFAULT FALSE,
fromEntry [4] BOOLEAN DEFAULT FALSE }
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
PartialAttributeList
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,
pageSizeLimit [0] INTEGER OPTIONAL,
sortKeys [1] SortKeyList OPTIONAL,
modifyRightsReq [3] BOOLEAN DEFAULT FALSE,
extraAttributes [4] BOOLEAN DEFAULT FALSE,
attrSizeLimit [5] INTEGER OPTIONAL,
subentries [6] BOOLEAN DEFAULT FALSE,
dontUseCopy [7] BOOLEAN DEFAULT FALSE,
usePartialCopy [8] BOOLEAN DEFAULT FALSE }
SortKeyList ::= SEQUENCE SIZE (0..maxInt) OF SEQUENCE {
type
attributeType AttributeType,
vals
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
Filter ::= CHOICE {
and [0] SET SIZE (0..maxInt) OF AttributeValue 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,
extensibleMatch [9] MatchingRuleAssertion }
SearchResultReference ::= [APPLICATION 18] Referral
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultFull
SubstringFilter ::= SEQUENCE {
type AttributeType,
substrings SEQUENCE SIZE (1..maxInt) OF CHOICE {
entry SearchResultEntry,
reference SearchResultReference,
resultCode SearchResultDone
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString }
ModifyRights }
MatchingRuleAssertion ::= SEQUENCE {
entryRemove BOOLEAN,
entryModifyDN BOOLEAN,
attrRights
matchingRules [1] SET SIZE (0..maxInt) OF SEQUENCE { MatchingRuleId,
type [2] AttributeType,
grantAdd BOOLEAN,
grantRemove
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN } }
Upon receipt
Parameters of a the Search Request, a server will perform Request are:
- baseObject: An LDAPDN that is the base object entry relative to
which the necessary search is to be performed.
- scope: An indicator of the DIT.
If the LDAP session is operating over a connection-oriented transport
such as TCP, scope of the server will return search to be performed. The
semantics of the client a sequence possible values 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 field are identical to the search. There must always
semantics of the scope field in the directory Search Operation.
- derefAliases: An indicator as to how alias objects should be a final response
containing
handled in searching. The semantics of the SearchResultDone, which contains an indication possible values of
success,
this field are:
neverDerefAliases: do not dereference aliases in searching
or detailing any errors that have occurred.
If in locating the LDAP session is operating over a connectionless transport such
as UDP, base object of the server will return to search;
derefInSearching: dereference aliases in subordinates of
the client only one response, a
LDAPMessage containing a SearchResultFull data type. All if any base object in searching, but not in locating the last element
base object of the SEQUENCE OF must be of search;
derefFindingBaseObject: dereference aliases in locating
the SearchResultEntry
type, and base object of the last must be search, but not when searching
subordinates of the SearchResultDone type.
Each entry returned base object;
derefAlways: dereference aliases both in a SearchResultEntry will contain all attributes,
complete with associated values if necessary, as specified searching and in
locating the
attributes field base object of the Search Request.
In a SearchResultEntry, as an encoding optimisation, search.
- sizelimit: A sizelimit that restricts the value maximum number of the
objectName LDAP DN may use a trailing '*' character to refer entries
to the
baseObject be returned as a result of the corresponding searchRequest. For example, if the
baseObject is specified as "o=UofM, c=US", then the following
objectName LDAPDNs 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 response would have search. A value of 0 in this field indicates that no
timelimit restrictions are in effect for the indicated meanings
objectName returned actual LDAPDN denoted
____________________________________________________
"*" "o=UofM, c=US"
"cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US" search.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
If (and
- typesOnly: 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 if) the modifyRightsReq attribute types (no values) to be
returned. Setting this field was present 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
Request search to match a given entry. The and, or and not
choices may be used to form boolean combinations of filters.
- attributes: A list of the server also include attributes from each entry found as a
result of the ModifyRights field search to be returned. An empty list signifies that
all attributes from each entry found in the
entry. This field details the operations which search are expected to succeed
if requested by that user later in this session. The server need not
guarantee that these permissions will be granted, however it should
avoid suggesting permissions that
returned.
- pageSizeLimit: if present and set to TRUE, then if more entries are not currently granted. If no
information is available to
be returned than the pageSizeLimit, the server should not include the
modifyRights field in return only as
many as this limit before returning the SearchResultDone response.
The incompleteEntry flag is set if one or more attributes are not
present in the PartialAttributeList, because their size would have
exceeded the attribute size limit.
It is never set if typesOnly was
set to TRUE.
The server may set the fromEntry field in a SearchResult entry to TRUE
if it is known that the search is not based upon a shadow or cached
copy must cache all of the entry, but that results for the source lifetime of entry data has been directly
contacted.
If the server was association.
(The client will be able to locate the entry referred to by the
baseObject but was unable to search all request more of the entries in using the scope at
ResumeRequest, and under the baseObject, cached results can be cleared if the server may return one or more
SearchResultReference, each containing a reference to another LDAP client
sends the Abandon operation for this search). If the same or fewer
entries than this limit are to an X.500 server for continuing be returned, the operation. The server should return at most one SearchResultReference for a subtree. A server must
not return a SearchResultReference if it has located
all the baseObject entries and thus has the SearchResultDone response, and need not searched cache
the result. The pageSizeLimit does not affect SearchResultReference
responses, of which any entries; in number may be returned by the server.
- sortKeys: If this case field is present, then it should return a
SearchResultDone containing a referral resultCode specifies one or more
attribute types and matching rules, and the
continuationReference.
Note that an X.500 "list" operation can returned entries should
be emulated by a one-level
LDAP search operation with a filter checking for sorted in order based on these types. If the existence of reverseOrder field is
set to TRUE, then the
objectClass attribute, and that an X.500 "read" operation can entries will be
emulated by a base object LDAP search operation with presented in reverse sorted
order.
If the same filter.
4.5. Modify Operation
The Modify Operation allows a client to request that a modification server does not recognize any of the DIB be performed on its behalf by a server. The Modify
Request attribute types, or the
ordering rule associated with an attribute type is defined as follows:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification Attribute } }
Parameters not applicable, or
none of the Modify Request are:
- object: The object to be modified. The value attributes in the search responses are of this field should
name these types,
then the object to be modified. The server will not perform any
alias dereferencing sortKeys field is ignored and result entries are returned
in determining the object to be modified.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996 random order.
- A list of modifications modifyRightsReq: If this field is set to be performed on TRUE and the entry scope field is
set to be modified.
The entire list of entry modifications should be performed
in baseObject, then the order they are listed, as a single atomic operation. While
individual modifications may violate client requests that the Directory schema, modification
rights for the
resulting entry after be included in the entire list of modifications is performed
must conform search result. Support for
this field is optional, and clients should expect that not all
servers will implement returning modify rights.
- extraAttributes: If this field is present and set to the requirements of the Directory schema. The
values TRUE then
all operational attributes are requested to be returned as well.
Note that specific operational attributes may instead be taken on by the 'operation' field listed in each
modification construct have
the following semantics respectively:
add: add values listed attributes field. Servers are permitted to the given attribute, creating
the attribute if necessary;
delete: delete values listed from the given attribute,
removing the entire attribute ignore extraAttributes
if no values returning this information is prohibited by security policy.
Clients should note that many operational attributes are listed, or not
modifiable.
- attrSizeLimit: If this field is present, then if all current values of the attribute are listed for
deletion;
replace: replace existing values size in bytes
of the given an attribute
with the new and all its values listed, creating which would be returned in a
result entry exceeds this size in bytes, then the attribute if
necessary.
The result of is not
included in the modify attempted by result and the server upon receipt of a
Modify Request incompleteEntry field is returned in a Modify Response, defined as follows:
ModifyResponse ::= [APPLICATION 7] LDAPResult
Upon receipt of a Modify Request, a set to TRUE.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
- subentries: if present and set to TRUE, the server will should ignore
ordinary entries and only perform the necessary
modifications to search against subentries. If
the DIB.
The server will return to the client a single Modify Response
indicating either not support subentries and this field is TRUE it should
not do any searching, and return an empty result. (Note that if the successful completion of
LDAP is backed by an X.500(1988) directory service, the DIB modification, LDAP server may
receive a protocolError or unavailableCriticalExtension error, which
it should discard and instead return to the reason that the modification failed. Note that due client an empty result.)
- dontUseCopy: if present and set to TRUE, only the
requirement for atomicity in applying server which holds
the list master copy of modifications in
the Modify Request, the client may expect that no modifications of entry is permitted to perform the DIB have been performed filtering
and attribute selection.
- usePartialCopy: if present and set to TRUE, if the Modify Response received indicates
any sort server holds a
shadow copy of error, and at least one attribute from a matching entry, it should
use that copy to satisfy the search, even if not all the attributes
requested modifications have been
performed if are present in the Modify Response indicates successful completion shadowed copy.
The results of the Modify Operation.
4.6. Add Operation
The Add Operation allows a client to request search attempted by the addition server upon receipt of an entry
into the Directory. The Add a
Search Request is defined as follows:
AddRequest are returned in Search Responses, which are LDAP
messages containing either SearchResultEntry, SearchResultReference,
SearchResultDone or SearchResultFull data types.
SearchResultEntry ::= [APPLICATION 8] 4] SEQUENCE {
entry
objectName LDAPDN,
attributes AttributeList PartialAttributeList,
modifyRights [2] BOOLEAN OPTIONAL,
incompleteEntry [3] BOOLEAN DEFAULT FALSE,
fromEntry [4] BOOLEAN DEFAULT FALSE,
thisEntryNumber [5] INTEGER OPTIONAL,
totalCount [6] INTEGER OPTIONAL }
AttributeList
PartialAttributeList ::= SEQUENCE SIZE (1..maxInt) (0..maxInt) OF SEQUENCE {
type AttributeType, AttributeDescription,
vals SET SIZE (1..maxInt) (0..maxInt) OF AttributeValue }
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
Parameters of the Add Request are:
- entry: the Distinguished Name of the
SearchResultReference ::= [APPLICATION 18] Referral
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultFull ::= SEQUENCE SIZE (1..maxInt) OF CHOICE {
entry to be added. Note that
all components SearchResultEntry,
reference SearchResultReference,
resultCode SearchResultDone }
Upon receipt of a Search Request, a server will perform the name except for necessary
search of the last RDN component must
exist for DIT.
If the add to succeed. Note also that LDAP session is operating over a connection-oriented transport
such as TCP, the server will not
dereference any aliases in locating the entry to be added, and that
there are never any entries subordinate return to an alias entry.
- attributes: the list of attributes that make up the content client a sequence of the
responses in separate LDAP messages. There may be zero or more
responses containing SearchResultEntry, one for each entry being added.
The result of found
during the add attempted search. There may also be zero or more responses
containing SearchResultReference, one for each area not explored by the
this server upon receipt of a Add
Request is returned during the search. The SearchResultEntry and
SearchResultReferences may come in any order. Following all the Add Response, defined as follows:
AddResponse ::= [APPLICATION 9] LDAPResult
Upon receipt of an Add Request,
SearchResultReference responses and all SearchResultEntry responses up
to a pageSizeLimit (if any), the server will attempt to perform return a response containing
the
add requested. The result SearchResultDone, which contains an indication of success, or
detailing any errors that have occurred.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
If the add attempt LDAP session is operating over a connectionless transport such
as UDP, the server will be returned return to the client in the Add Response.
4.7. Delete Operation
The Delete Operation allows only one response, a client to request
LDAPMessage containing a SearchResultFull data type. All if any but
the removal last element of an
entry from the Directory. The Delete Request is defined as follows:
DelRequest ::= [APPLICATION 10] LDAPDN
The Delete Request consists SEQUENCE OF must be of the Distinguished Name of SearchResultEntry
type, and the
entry to last must be deleted. Note that the server will not dereference aliases
while resolving the name of the target entry to be removed. SearchResultDone type.
The result of the delete attempted by the server upon receipt of a
Delete Request SearchResultFull is never returned in the Delete Response, defined as follows:
DelResponse ::= [APPLICATION 11] LDAPResult
Upon receipt of over a Delete Request, connection-oriented
transport.
Each entry returned in a server SearchResultEntry will attempt to perform contain all attributes,
complete with associated values if necessary, as specified in the entry removal requested. The result
attributes field of the delete attempt will be
returned Search Request. Return of attributes is subject
to access control and other administrative policy.
In a SearchResultEntry, as an encoding optimisation, the client in value of the Delete Response. Note that only leaf
objects may be deleted with this operation.
4.8. Modify DN Operation
The Modify
objectName LDAP DN Operation allows may use a client trailing '*' character to refer to change the last component
of the name
baseObject of an entry in the Directory, or to move a subtree of
entries to a new location in corresponding searchRequest. For example, if the Directory. The Modify DN Request
baseObject is
defined specified as follows:
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
Parameters of "o=UofM, c=US", then the Modify DN Request are:
- entry: following
objectName LDAPDNs in a response would have the name of indicated meanings
objectName returned actual LDAPDN denoted
____________________________________________________
"*" "o=UofM, c=US"
"cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US"
If (and only if) the entry to be changed.
- newrdn: modifyRightsReq field was present in the RDN that will form Search
Request may the last component of server also include the new name.
- deleteoldrdn: a boolean parameter that controls whether ModifyRights field in the old RDN
attribute values should be retained as attributes of
entry. If present and set to TRUE, then the server suggests it is
likely that a valid modification operation on this entry or
deleted from would succeed.
If present and set to FALSE, then it is likely the entry.
- newSuperior: if present, this operation would
fail due to an authentication or access control restriction. If no
information is available the name of another entry which server should be the superior of not include the subtree
modifyRights field in the entry field. response.
The result of the name change attempted by the server upon receipt of
a Modify DN Request incompleteEntry flag is returned set if one or more attributes are not
present in the Modify DN Response, defined
as follows:
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
Upon receipt of a Modify RDN Request, a server will attempt to
perform PartialAttributeList, because their size would have
exceeded the name change. The result attribute size limit, or if a partial shadow copy of the name change attempt will
be returned
entry was used to satisfy the client in the Modify DN Response. The request and some requested attributes
that make up the old RDN are deleted from the entry, or kept,
depending on the setting of the deleteoldrdn parameter.
4.9. Compare Operation
not returned. It is never set just because typesOnly was set to TRUE.
The Compare Operation allows server may set the fromEntry field in a client to compare an assertion
provided with an SearchResult entry in to TRUE
if it is known that the Directory. The Compare Request search is
defined as follows:
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion,
timeLimit [0] INTEGER (0 .. maxInt) OPTIONAL,
dontUseCopy [1] BOOLEAN DEFAULT FALSE }
Parameters not based upon a shadow or cached
copy of the Compare Request are:
- entry: entry, but that the name source of the entry to be compared with.
- ava: the assertion with which an attribute in the entry is to be
compared.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
- timeLimit: data has been directly
contacted.
If the maximum time in seconds pageSizeLimit control was present, the server should spend in
handling this operation.
- dontUseCopy: if present and set to TRUE, only must number the server
entries which holds
the master copy of match the search. The first entry is permitted to return returned will have
thisEntryNumber field contain the compareTrue
or compareFalse results. number 0, the next is number 1, etc.
The result server must also indicate a count of the compare attempted by the server upon receipt total number of a
Compare Request is returned entries in
the Compare Response, defined as
follows:
CompareResponse ::= [APPLICATION 15] LDAPResult
Upon receipt of field totalCount. The server may revise the count, a Compare Request, larger
totalCount field in a server later SearchResultEntry will attempt to perform override the requested comparison. The result
totalCount field of an earlier SearchResultEntry for that search.
If the comparison will be
returned to the client in server was able to locate the Compare Response. Note that errors and entry referred to by the result of comparison are
baseObject but was unable to search all returned the entries in the same construct.
This operation is defined scope at
and under the baseObject, the server may return one or more
SearchResultReference, each containing a reference to another LDAP
server for backwards compatability with earlier
versions of LDAP. Any new clients written should not use continuing the
comparison operation, but instead operation. The server should use return at most
one SearchResultReference for a subtree. A server must not return a
SearchResultReference if it has not located the search operation,
with scope set to baseObject and filter thus has
not searched any entries; in this case it should return a
SearchResultDone containing one element, an
equality match. a referral resultCode.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
Note that different results will an X.500 "list" operation can be returned than
from the comparison operation: in emulated by a one-level
LDAP search if the operation with a filter match is
successful, the entry will be returned, and if checking for the attribute
value is not present, no entries will be returned.
4.10. Abandon Operation
The function existence of the Abandon Operation is to allow a client to request
objectClass attribute, and that the server abandon an outstanding operation. X.500 "read" operation can be
emulated by a base object LDAP search operation with the same filter.
4.5. Resume Search Operation
The Abandon
Request Resume Search Operation is defined as follows:
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID must be that of used in conjunction with a Search or Compare
operation which was
requested earlier during previously issued on this association. Other types of operations
cannot be abandoned.
There is no response defined in
ResumeRequest ::= [APPLICATION 20] SEQUENCE {
searchRequestID [0] MessageID,
startAtEntry [1] INTEGER OPTIONAL,
entriesToReturn [2] INTEGER OPTIONAL }
The SearchRequest must have been made with the Abandon Operation. Upon
transmission of pageSizeLimit
field present, and the server must not have returned the SearchResultDone
for this search, indicating that all the results have been returned or
an Abandon Operation, a error was encountered. A Search which has been abandoned cannot be
resumed.
The searchRequestID field must contain the value of messageID which the
client used for the original search operation.
The startAtEntry number may expect that be any number greater than 0, and the
operation identified by sum of
startAtEntry and entriesToReturn must not be greater than the Message ID in value of
totalCount returned by the Abandon Request has
been abandoned. In server for this search. Note that the event client
may request that a the server receives an Abandon
Request on retransmit entries which it has already sent,
by setting a Search Operation in value of startAtEntry smaller than the midst thisEntryNumber of transmitting responses
the last entry which the server has transmitted.
The server will respond to that search, that the ResumeRequest with either a ResumeError,
or with a series of SearchResultEntry responses. The ResumeError is
only returned if the server should cease transmitting entry detected a problem with the ResumeRequest,
such as an invalid searchRequestID. The SearchResultEntry responses
to
have the abandoned search immediately. MessageID of the ResumeRequest, not of the original
SearchRequest.
ResumeError ::= [APPLICATION 21] LDAPResult
An example of using Resume is as follows:
CLIENT SERVER
0,BindRequest
-->
0,BindResponse
<--
1,SearchRequest (pageSizeLimit=2)
-->
(search matches 5 entries)
1,SearchResultEntry (0 of 5)
<--
1,SearchResultEntry (1 of 5)
<--
1,SearchResultDone
<--
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
4.11 Extended
2,ResumeRequest (search id 1, start at 2, retrieve 3)
-->
2,SearchResultEntry (2 of 5)
<--
2,SearchResultEntry (3 of 5)
<--
2,SearchResultEntry (4 of 5)
<--
3,AbandonRequest (id 1)
-->
(search cache cleared)
4.6. Modify Operation
The following operation Modify Operation allows clients a client to make requests of forms not
defined in this document. The requestName is request that a dotted-decimal
representation modification
of the OBJECT IDENTIFIER corresponding to the request.
The requestValue is information in a form defined DIB be performed on its behalf by that request,
encapsulated inside an OCTET STRING.
ExtendedRequest a server. The Modify
Request is defined as follows:
ModifyRequest ::= [APPLICATION 23] 6] SEQUENCE {
requestName [0] LDAPString,
requestValue [1] OCTET STRING
object LDAPDN,
modification SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues }
The server will respond to this with an LDAPMessage containing the
ExtendedResponse.
ExtendedResponse }
AttributeTypeAndValues ::= [APPLICATION 24] SEQUENCE {
response [0] OCTET STRING OPTIONAL,
standardResponse [1] LDAPResult
type AttributeDescription,
vals SET OF AttributeValue }
If the server does not recognize the operation name, it should return
only the standardResponse, containing the protocolError result code.
5. Protocol Element Encodings and Transfer
The protocol elements
Parameters of LDAP are encoded for exchange using the
Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due Modify Request are:
- object: The object to the
high overhead involved in using certain elements of the BER, the
following additional restrictions are placed on BER-encodings be modified. The value of LDAP
protocol elements:
(1) Only this field should
name the definite form of length encoding will object to be used.
(2) Bitstrings and octet strings and all character string types modified. The server will be encoded not perform any
alias dereferencing in determining the primitive form only.
(3) UTC Times should object to be encoded with the "Z" suffix, not as a local
time.
(4) If the value modified.
- A list of a BOOLEAN type is true, modifications to be performed on the encoding should have
its contents octets set entry to hex "FF".
(5) be modified.
The components entire list of a SET type, currently only DO.AccessPoint, entry modifications should be encoded performed
in ascending 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 tag value.
(6) Unused bits 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 final octet 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 encoding attribute are listed for
deletion;
replace: replace existing values of a BIT STRING
value, the given attribute
with the new values listed, creating the attribute if there are any, should always be set to zero.
(7) If a
necessary. A replace with no value should delete the entire
attribute.
The result of the modify attempted by the server upon receipt of a type
Modify Request is its default value, it should be absent.
Only BOOLEAN and ENUMERATED types have default values.
These restrictions do not apply to ASN.1 types encapsulated inside of
OCTET STRINGs. returned in a Modify Response, defined as follows:
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
5.1. 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
ModifyResponse ::= [APPLICATION 7] LDAPResult
Upon receipt of a Modify Request, a server will perform the data
stream. For compatibility with necessary
modifications to the existing LDAP v2 and CLDAP
protocols, three underlying services are defined here. However an
LDAP DIB.
The server need not implement all three. Separate documents may
define other mappings, such as will return to the client a MIME Content-type 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 use atomicity in
messaging and WWW.
5.1.1. Transmission Control Protocol (TCP)
The LDAPMessage PDUs are mapped directly onto the TCP bytestream.
Server implementations running over applying the TCP should provide a protocol
listener on port 389.
5.1.2. Connection Oriented Transport Service (COTS)
The connection is established. No special use list of T-Connect is made.
Each LDAPMessage PDU is mapped directly onto T-Data.
5.1.3. User Datagram Protocol (UDP)
The LDAPMessage PDUs are mapped directly onto UDP datagrams. Only
one request may be sent in a single datagram. Only one response may
be sent modifications in a single datagram. Server implementations running over
the UDP should provide a protocol listener on port 389.
The only operations which Modify Request, the client may request are searchRequest and
abandonRequest. The server may only respond with expect that no modifications of
the searchResultFull.
6. Implementation Guidelines
6.1. Server Implementations
The server should be capable DIB have been performed if the Modify Response received indicates
any sort of recognizing error, and that all requested modifications have been
performed if the attribute type
names and implement Modify Response indicates successful completion of
the syntaxes specified in [5]. Servers may also
recognize additional attribute type names.
In order Modify Operation.
4.7. Add Operation
The Add Operation allows a client to prevent confusion, the server should respond with the OID
form for request the "uniqueIdentifier" standard and pilot attribute.
6.2. Client Implementations
As there is a conflict addition of names, the client must not request an entry
into the
"uniqueIdentifier" attribute. Instead it should use directory. The Add Request is defined as follows:
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList,
targetSystem [0] LDAPString OPTIONAL }
AttributeList ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
type AttributeDescription,
vals SET SIZE (1..maxInt) OF AttributeValue }
Parameters of the OID form.
For simple lookup applications using Add Request are:
- entry: the connectionless transport
protocol UDP, use Distinguished Name of a retry algorithm with multiple servers similar the entry to that commonly used in DNS stub resolver implementations is
recommended. The location of a CLDAP server or servers may be better
specified using IP addresses (simple or broadcast) rather than names added. Note that
all components of the name except for the last RDN component must first be looked up in another directory such as DNS.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
Servers
exist for the add to succeed. Note also that the server will not
dereference any aliases encountered when performing an
Add, Delete or Modify operation. If an alias was encountered an error
will be returned. The client must retry in locating the operation with an updated
target entry name. Note that multiple aliases may to be encounted while
resolving added, and that
there are never any entries subordinate to an alias entry.
- attributes: the entry's true name.
7. Security Considerations
When used with a connection-oriented transport, this version list of attributes that make up the
protocol provides facilities for the LDAP v2 authentication mechanisms:
simple authentication using a cleartext password and kerberos version 4
authentication. It also provides for two other authentication
mechanisms as described in X.511: transfer of a hash content of the client's
password, and strong authentication based on
entry being added.
- targetSystem: if present, the private key string representation of an
AccessPoint93, identifying the
client.
When used with server which should hold the connectionless transport, no security services are
available. There has been some discussion about target
entry. If the desirability server does not support the targetSystem extension
it should return the error unavailableCriticalExtension.
The result of
authentication with connectionless LDAP requests. This might take the
form add attempted by the server upon receipt of a clear text password (which would go against the current IAB
drive to remove such things from protocols) or some arbitrary
credentials. It Add
Request is felt that, returned in general, authentication would incur
sufficient overhead to negate the advantages Add Response, defined as follows:
AddResponse ::= [APPLICATION 9] LDAPResult
Upon receipt of an Add Request, a server will attempt to perform the connectionless
basis
add requested. The result of CLDAP. If an application requires authenticated access the add attempt will be returned to the
Directory then CLDAP is not an appropriate protocol.
8. Acknowledgements
This document is based heavily on RFC 1777, by Wengyik Yeong, Tim
Howes, and Steve Kille. It also includes material from RFC 1798, by
Alan Young. Design ideas included in this document are based on those
discussed
client in ASID and other IETF Working Groups.
9. Bibliography
[1] the Add Response.
4.8. Delete Operation
The Directory: Overview Delete Operation allows a client to request the removal of Concepts, Models and Service. ITU-T
Recommendation X.500, 1993.
[2] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[3] Specification of Abstract Syntax Notation One (ASN.1). CCITT
Recommendation X.208, 1988.
[4] S. Kille, "A String Representation of Distinguished Names", RFC
1779, March 1995.
[5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins,
"Lightweight X.500 Directory Access Protocol Standard and Pilot
Attribute Definitions", <draft-ietf-asid-ldapv3-attributes-00.txt>,
February 1996.
[6] The Directory: Models. ITU-T Recommendation X.501, 1993.
[7] The Directory: Selected Attribute Types. ITU-T Recommendation
X.520, 1993.
INTERNET-DRAFT Lightweight an
entry from the directory. The Delete Request is defined as follows:
DelRequest ::= [APPLICATION 10] LDAPDN
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
[9] T. Howes, M. Smith, An LDAP URL Format, December 1995,
<draft-ietf-asid-ldap-format-03.txt>
[10] The Directory: Procedures for Distributed Operation. ITU-T
Recommendation X.518, 1993.
[11] Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1). CCITT Recommendation X.209, 1988.
[12] The Directory: Authentication Framework. ITU-T Recommendation
X.509, 1993.
[13]
The Directory: Abstract Service Definition. ITU-T Recommendation
X.511, 1993.
[14] 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.
10. Authors' Address
Mark Wahl
ISODE Consortium Inc.
3925 West Braker Lane, Suite 333
Austin, TX 78759
USA
Phone: +1 512-305-0280
EMail: M.Wahl@isode.com
Tim Howes
University Delete Request consists 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
The Dome, The Square
Richmond
TW9 1DT
UK
Phone: +44-181-332-9091
EMail: S.Kille@isode.com
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
Appendix A - Complete ASN.1 Definition
In the IMPORTS statement Distinguished Name of the "AF" module refers
entry to X.509(1993),
and be deleted. Note that the "DAS" module server will not dereference aliases
while resolving the name of the target entry to X.511(1993).
Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
IMPLICIT TAGS be removed.
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 ::=
BEGIN
IMPORTS CertificationPath FROM AF
Token FROM DAS;
LDAPMessage [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.9. Modify DN Operation
The Modify DN Operation allows a client to change the last 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 {
messageID MessageID,
cldapUserName
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL,
protocolOp CHOICE {
bindRequest BindRequest,
bindRespBasic BindResponseBasic,
bindRespExtd BindResponseExtended,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
searchResFull SearchResultFull,
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 } OPTIONAL }
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
MessageID ::= INTEGER (0 .. maxInt )
maxInt INTEGER ::= 2147483647 -- (2^^31
Parameters of the Modify DN Request are:
- 1) --
-- later may be extended entry: the name of the entry to 9223372036854775807 (2^^63 be changed.
- 1) --
LDAPString ::= OCTET STRING
LDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
AttributeType ::= LDAPString
AttributeTypeList ::= SEQUENCE SIZE (0..maxInt) OF AttributeType
AttributeValue ::= OCTET STRING
AttributeValueAssertion ::= SEQUENCE {
attributeType AttributeType,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
Attribute ::= SEQUENCE {
type AttributeType,
vals SET SIZE (1..maxInt) 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
-- 14-15 unused --
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
isLeaf (35),
aliasDereferencingProblem (36),
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
-- 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),
resultsTooLarge (70), -- cl only
affectsMultipleDSAs (71), -- newrdn: the RDN that will form the last component of the new
-- 72-79 unused --
other (80) },
matchedDN LDAPDN,
errorMessage LDAPString (SIZE (0..maxInt)),
referral [3] Referral OPTIONAL,
matchedSubtype [4] AttributeType OPTIONAL }
Referral ::= SEQUENCE {
servers [0] SET SIZE (1..maxInt) OF LDAPURL }
LDAPURL ::= OCTET STRING
BindRequest 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.
- newSuperior: if present, this is the name of another entry which
should be the superior of the subtree in the entry field.
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 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice,
serviceControls [7] Controls OPTIONAL }
AuthenticationChoice 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 DN 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.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 ::= CHOICE [APPLICATION 14] SEQUENCE {
simple
entry LDAPDN,
ava AttributeValueAssertion,
dontUseCopy [1] OCTET STRING,
krbv42LDAP [2] OCTET STRING,
krbv42DSA [3] OCTET STRING,
protected [4] ProtectedPassword,
strong [5] StrongCredentials,
nonstandard [6] NonstandardCredentials BOOLEAN DEFAULT FALSE }
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
ProtectedPassword ::= SEQUENCE {
time1 [0] UTCTime OPTIONAL,
time2 [1] UTCTime OPTIONAL,
random1 [2] BIT STRING OPTIONAL,
random2 [3] BIT STRING OPTIONAL,
protected [4] OCTET STRING }
StrongCredentials ::= SEQUENCE {
certification-path [0] AF.CertificationPath OPTIONAL,
bind-token [1] DAS.Token }
NonstandardCredentials ::= SEQUENCE {
authMechanism [0] LDAPString,
authToken [1] OCTET STRING }
Controls ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
criticality [0] BOOLEAN DEFAULT FALSE,
control ServiceControl }
ServiceControl ::= CHOICE {
referringServer [0] LDAPURL,
chainingProhibited [1] BOOLEAN,
scopeOfReferral [2] ENUMERATED {
any(-1),
dmd(0),
country(1) },
referToLDAPServers [3] BOOLEAN,
referToDAPServers [4] BOOLEAN,
preferredSyntax [5] SyntaxEncoding,
extendedControl [6] ExtendedControl }
SyntaxEncoding ::= SEQUENCE {
attributeType [0] AttributeType,
encodingPreference [1] SyntaxName }
SyntaxName ::= LDAPString
ExtendedControl ::= SEQUENCE {
controlName [0] LDAPString,
controlValue [1] OCTET STRING }
BindResponseBasic
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.
- dontUseCopy: if present and set to TRUE, only the server which holds
the master copy of the entry is permitted to return the compareTrue
or compareFalse results.
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 1] 15] LDAPResult
BindResponseExtended ::= [APPLICATION 17] SEQUENCE {
serverURL [0] LDAPURL,
serverCreds AuthenticationChoice }
UnbindRequest ::= [APPLICATION 2] NULL
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2) },
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
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.
Note that some directory systems may establish access controls which
permit the values of certain attributes AttributeTypeList,
matchedOnly [0] BOOLEAN DEFAULT FALSE,
sortKeys [1] SortKeyList OPTIONAL,
reverseSort [2] BOOLEAN DEFAULT FALSE,
modifyRightsReq [3] BOOLEAN DEFAULT FALSE,
extraAttributes [4] BOOLEAN DEFAULT FALSE,
attrSizeLimit [5] INTEGER OPTIONAL,
subentries [6] BOOLEAN DEFAULT FALSE,
dontUseCopy [7] BOOLEAN DEFAULT FALSE }
SortKeyList (such as userPassword) to be
compared but not read.
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 ::= SEQUENCE SIZE (1..maxInt) OF [APPLICATION 16] MessageID
The MessageID must be that of a Search, Resume or Compare operation
which was requested earlier during this association. Other types of
operations cannot be 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 or Resume Operation in the midst of transmitting
responses to the search, that server should cease transmitting entry
responses to the abandoned request immediately.
If the MessageID is for a Search operation in which pageSizeLimit was
set, the abandon will clear the results from the server's cache.
Abandoning a Resume operation does not clear the cache.
4.11 Extended Operation
It may be desirable in some communities to define additional operations
for services not available in this protocol, for instance digitally
signed operations and results. Thus an extension mechanism
The extended operation allows clients to make requests and receive
responses with bilaterally-defined syntaxes and semantics.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
attributeType AttributeType,
orderingRule
requestName [0] MatchingRuleId LDAPOID,
requestValue [1] OCTET STRING }
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 {
responseName [0] LDAPOID OPTIONAL,
startFrom
response [1] AssertionValue OCTET STRING OPTIONAL,
endWith
standardResponse [2] AssertionValue OPTIONAL LDAPResult }
Filter ::= CHOICE {
If the server does not recognize the operation name, it should return
only the standardResponse field, containing the protocolError result
code.
5. Protocol Element Encodings and Transfer
For compatibility with the existing LDAP v2 and CLDAP protocols, four
underlying services are defined here. However an LDAP server need not
implement all of them.
5.1. Mapping Onto BER-based 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.
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) BIT STRINGs and OCTET STRINGs will be encoded in the primitive form
only.
(3) If the value of a BOOLEAN type is true, the encoding should have
its contents octets set to hex "FF".
(4) If a value of a type is its default value, it should be absent.
Only some BOOLEAN and ENUMERATED types have default values in this
protocol definition.
If an implementation supports the protected or strong authentication
elements then the following additional restrictions apply:
(5) UTC Times in the protocol itself should be encoded with the "Z"
suffix, not as a local time. (This requirement does not apply to
times in attribute values).
(6) Unused bits in the final octet of the encoding of a BIT STRING
value, if there are any, should always be set to zero.
These restrictions do not apply to ASN.1 types encapsulated inside of
OCTET STRINGs, such as attribute values.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
5.1.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.
5.1.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.
5.1.3. User Datagram Protocol (UDP)
The LDAPMessage PDUs are mapped directly onto UDP datagrams. Only
one request may be sent in a single datagram. Only one response may
be sent in a single datagram. Server implementations running over
the UDP should provide a protocol listener on port 389.
The only operations which the client may request are searchRequest and
abandonRequest. The server may only respond with the searchResultFull.
5.1.4. Secure Socket Layer over TCP (SSL)
After establishing the SSL connection over TCP, the LDAPMessage PDUs
are mapped directly onto the bytestream. Server implementations
running over SSL/TCP should provide a protocol listener on port TBD.
6. Implementation Guidelines
6.1. Server Implementations
The server should 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
For simple lookup applications using the connectionless transport
protocol UDP, use of a retry algorithm with multiple servers similar
to that commonly used in DNS stub resolver implementations is
recommended. The location of a CLDAP server or servers may be better
specified using IP addresses (simple or broadcast) rather than names
that must first be looked up in another directory such as DNS.
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. It also provides for
two other authentication mechanisms as described in X.511: transfer of a
hash of the client's password, and strong authentication based on the
private key of the client. It is also permitted that the server can
return its credentials to the client.
This document also defines a mapping of LDAP over the Secure Sockets
Layer (SSL), which can provide strong authentication, integrity and [0] SET SIZE (1..maxInt) OF Filter,
privacy of the connection.
Use of cleartext password is strongly discouraged where the underlying
transport service cannot guarantee confidentiality.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
When used with the connectionless transport, no security services are
available. There has been some discussion about the desirability of
authentication with connectionless LDAP requests. This might take the
form of a clear text password (which would go against the current IAB
drive to remove such things from protocols) or [1] SET SIZE (1..maxInt) OF Filter, some arbitrary
credentials. It is felt that, in general, authentication would incur
sufficient overhead to negate the advantages of the connectionless
basis of CLDAP. If an application requires authenticated access to the
directory then CLDAP is not an appropriate protocol.
8. Acknowledgements
This document is an update to RFC 1777, by Wengyik Yeong, Tim
Howes, and Steve Kille. It also includes material from RFC 1798, by
Alan Young. Design ideas included in this document are based on those
discussed in ASID and other IETF Working Groups.
9. Bibliography
[1] The Directory: Overview of Concepts, Models and Service. ITU-T
Recommendation X.500, 1993.
[2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeType,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeType,
substrings SEQUENCE SIZE (1..maxInt) OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
MatchingRuleAssertion ::= SEQUENCE {
matchingRules [1] SET SIZE (0..maxInt) OF MatchingRuleId,
type [2] AttributeType,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList,
modifyRights [2] ModifyRights OPTIONAL,
incompleteEntry W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[3] BOOLEAN DEFAULT FALSE,
fromEntry Abstract Syntax Notation One (ASN.1) - Specification of Basic
Notation. ITU-T Recommendation X.680, 1994.
[4] BOOLEAN DEFAULT FALSE }
INTERNET-DRAFT Lightweight S. Kille, "A String Representation of Distinguished Names", RFC
1779, March 1995.
[5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins,
"Lightweight X.500 Directory Access Protocol 19 February 1996
PartialAttributeList ::= SEQUENCE SIZE (0..maxInt) OF SEQUENCE {
type AttributeType,
vals SET SIZE (0..maxInt) OF AttributeValue }
SearchResultReference ::= [APPLICATION 18] Referral
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultFull ::= SEQUENCE SIZE (1..maxInt) OF CHOICE {
entry SearchResultEntry,
reference SearchResultReference,
resultCode SearchResultDone }
ModifyRights ::= SEQUENCE {
entryRemove BOOLEAN,
entryModifyDN BOOLEAN,
attrRights SET SIZE (0..maxInt) OF SEQUENCE {
type AttributeType,
grantAdd BOOLEAN,
grantRemove BOOLEAN } }
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification Standard and Pilot
Attribute } }
ModifyResponse ::= [APPLICATION 7] LDAPResult
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE SIZE (1..maxInt) OF SEQUENCE {
type AttributeType,
vals SET SIZE (1..maxInt) OF AttributeValue }
AddResponse ::= [APPLICATION 9] LDAPResult
DelRequest ::= [APPLICATION 10] LDAPDN
DelResponse ::= [APPLICATION 11] LDAPResult Definitions", <draft-ietf-asid-ldapv3-attributes-03.txt>,
May 1996.
[6] The Directory: Models. ITU-T Recommendation X.501, 1993.
[7] The Directory: Selected Attribute Types. ITU-T Recommendation
X.520, 1993.
[9] T. Howes, M. Smith, An LDAP URL Format, December 1995,
<draft-ietf-asid-ldap-format-03.txt>
[10] The Directory: Procedures for Distributed Operation. ITU-T
Recommendation X.518, 1993.
[11] Specification of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules. ITU-T Recommendation X.690, 1994.
[12] The Directory: Authentication Framework. ITU-T Recommendation
X.509, 1993.
[13] The Directory: Abstract Service Definition. ITU-T Recommendation
X.511, 1993.
[14] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, Dec. 1994.
[15] Universal Multiple-Octet Coded Character Set (UCS) - Architecture
and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February (v3) June 1996
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion,
timeLimit [0] INTEGER (0 .. maxInt) OPTIONAL,
dontUseCopy [1] BOOLEAN DEFAULT FALSE }
CompareResponse ::= [APPLICATION 15] LDAPResult
AbandonRequest ::= [APPLICATION 16] MessageID
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPString,
requestValue [1] OCTET STRING }
ExtendedResponse
[16] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1.
10. Authors' Address
Mark Wahl
ISODE Consortium Inc.
3925 West Braker Lane, Suite 333
Austin, TX 78759
USA
Phone: +1 512-305-0280
EMail: M.Wahl@isode.com
Tim Howes
Netscape Communications Corp.
685 Middlefield
Mountain View, CA 94043
USA
Phone: +1 415 254-1900
EMail: howes@netscape.com
Steve Kille
ISODE Consortium
The Dome, The Square
Richmond
TW9 1DT
UK
Phone: +44-181-332-9091
EMail: S.Kille@isode.com
Appendix A - Complete ASN.1 Definition
In the IMPORTS statement the "AF" module refers to X.509(1993),
and the "DAS" module to X.511(1993).
Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
IMPLICIT TAGS ::= [APPLICATION 24] SEQUENCE {
response [0] OCTET STRING OPTIONAL,
standardResponse [1] LDAPResult }
BEGIN
IMPORTS CertificationPath FROM AF
Token FROM DAS;
--- to be provided ---
END
Appendix B - Imported ASN.1 Definitions
Note that the types described here are distinct from those defined in
the body of this document.
INTERNET-DRAFT Lightweight Directory Access Protocol 19 February 1996
B.1. Types from X.509(1993) "Authentication Framework"
The type "Certificate" is defined in X.509(1993). It it strongly
recommended that clients and server implementations which support
certificates implement the draft addendums to X.509 which provide
certificate extensions.
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY OPTIONAL }
CertificatePair ::= SEQUENCE {
forward [0] Certificate OPTIONAL,
reverse [1] Certificate OPTIONAL
-- at least one of the pair shall be present -- }
CertificationPath ::= SEQUENCE {
userCertificate Certificate,
theCACertificates SEQUENCE OF CertificatePair
OPTIONAL }
B.2. Types from X.511(1993) "Directory Abstract Syntax"
The type "DistinguishedName" is defined in X.501(1993). It is the
ASN.1 encoding, not a string encoding.
Token ::= SIGNED { SEQUENCE {
algorithm [0] AlgorithmIdentifier,
name [1] DistinguishedName,
time [2] UTCTime,
random [3] BIT STRING } }
<draft-ietf-asid-ldapv3-protocol-01.txt> Expires: December 5, 1996
INTERNET-DRAFT Lightweight Directory Access Protocol (v3) June 1996
----