Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol (LDAP;

/ldp/) is an open, vendor-neutral, industry standard
application protocol for accessing and maintaining distributed directory information services over an Internet
Protocol (IP) network.[1] Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users,
systems, networks, services, and applications throughout
the network.[2] As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an
address and a phone number.

stack. LDAP was originally intended to be a lightweight

alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP
protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service
protocols.
Standalone LDAP directory servers soon followed, as did
directory servers supporting both DAP and LDAP. The
latter has become popular in enterprises, as LDAP removed any need to deploy an OSI network. Today, X.500
directory protocols including DAP can also be used directly over TCP/IP.
The protocol was originally created[6] by Tim Howes of
the University of Michigan, Steve Kille of Isode Limited, Colin Robbins of Nexor and Wengyik Yeong of
Performance Systems International, circa 1993, as a
successor[7] to DIXIE and DAS. Mark Wahl of Critical Angle Inc., Tim Howes, and Steve Kille started work
in 1996 on a new version of LDAP, LDAPv3, under
the aegis of the Internet Engineering Task Force (IETF).
LDAPv3, rst published in 1997, superseded LDAPv2
and added support for extensibility, integrated the Simple
Authentication and Security Layer, and better aligned the
protocol to the 1993 edition of X.500. Further development of the LDAPv3 specications themselves and of numerous extensions adding features to LDAPv3 has come
through the IETF.

LDAP is specied in a series of Internet Engineering

Task Force (IETF) Standard Track publications called
Request for Comments (RFCs), using the description
language ASN.1. The latest specication is Version
3, published as RFC 4511. For example, here is an
LDAP search translated into plain English: Search in
the company email directory for all people located in
Nashville whose name contains 'Jesse' that have an email
address. Please return their full name, email, title, and
description.[3]

A common usage of LDAP is to provide a single sign on

where one password for a user is shared between many
services, such as applying a company login code to web
pages (so that sta log in only once to company computers, and then are automatically logged into the company In the early engineering stages of LDAP, it was known as
intranet).[3]
Lightweight Directory Browsing Protocol, or LDBP. It was
LDAP is based on a simpler subset of the standards con- renamed with the expansion of the scope of the prototained within the X.500 standard. Because of this rela- col beyond directory browsing and searching, to include
directory update functions. It was given its Lightweight
tionship, LDAP is sometimes called X.500-lite.[4]
name because it was not as network intensive as its DAP
predecessor and thus was more easily implemented over
the Internet due to its relatively modest bandwidth usage.

History

LDAP has inuenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory
Telecommunication companies understanding of direc(XED), Directory Service Markup Language (DSML),
tory requirements were well developed after some 70
Service Provisioning Markup Language (SPML), and the
years of producing and managing telephone directories.
Service Location Protocol (SLP).
These companies introduced the concept of directory
services to information technology and computer networking, their input culminating in the comprehensive
X.500 specication,[5] a suite of protocols produced by 2 Protocol overview
the International Telecommunication Union (ITU) in the
1980s.
A client starts an LDAP session by connecting to an
X.500 directory services were traditionally accessed via LDAP server, called a Directory System Agent (DSA),
the X.500 Directory Access Protocol (DAP), which re- by default on TCP and UDP port 389, or on port 636 for
quired the Open Systems Interconnection (OSI) protocol LDAPS.[8] Global Catalog is available by default on ports
1

4 OPERATIONS

3268, and 3269 for LDAPS.[9] The client then sends an

operation request to the server, and the server sends responses in return. With some exceptions, the client does
not need to wait for a response before sending the next
request, and the server may send the responses in any order. All information is transmitted using Basic Encoding
Rules (BER).
The client may request the following operations:

Each entry has a unique identier: its Distinguished

Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entrys
DN. Think of the DN as the full le path and the
RDN as its relative lename in its parent folder (e.g.
if /foo/bar/myle.txt were the DN, then myle.txt
would be the RDN).

A DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might
Bind authenticate and specify LDAP protocol be provided in the set of the entrys operational attributes.
version
An entry can look like this when represented in LDAP
Search search for and/or retrieve directory entries Data Interchange Format (LDIF) (LDAP itself is a binary
protocol):
Compare test if a named entry contains a given
dn: cn=John Doe,dc=example,dc=com cn: John
attribute value
Doe givenName: John sn: Doe telephoneNumber:
+1 888 555 6789 telephoneNumber: +1 888 555
Add a new entry
1232 mail: john@example.com manager: cn=Barbara
Delete an entry
Doe,dc=example,dc=com objectClass: inetOrgPerson
objectClass: organizationalPerson objectClass: person
Modify an entry
objectClass: top
Modify Distinguished Name (DN) move or re- dn is the distinguished name of the entry; it is neiname an entry
ther an attribute nor a part of the entry. cn=John Doe

StartTLS use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection

is the entrys RDN (Relative Distinguished Name), and

dc=example,dc=com is the DN of the parent entry,
Extended Operation generic operation used to where dc denotes 'Domain Component'. The other
lines show the attributes in the entry. Attribute names are
dene other operations
typically mnemonic strings, like cn for common name,
Unbind close the connection (not the inverse of dc for domain component, mail for e-mail address,
Bind)
and sn for surname.
Abandon abort a previous request

A server holds a subtree starting from a specic entry, e.g.

In addition the server may send Unsolicited Noticadc=example,dc=com and its children. Servers may also
tions that are not responses to any request, e.g. before
hold references to other servers, so an attempt to access
the connection is timed out.
ou=department,dc=example,dc=com could return a reA common alternative method of securing LDAP com- ferral or continuation reference to a server that holds that
munication is using an SSL tunnel. This is denoted in part of the directory tree. The client can then contact the
LDAP URLs by using the URL scheme ldaps. The de- other server. Some servers also support chaining, which
fault port for LDAP over SSL is 636. The use of LDAP means the server contacts the other server and returns the
over SSL was common in LDAP Version 2 (LDAPv2) results to the client.
but it was never standardized in any formal specication.
LDAP rarely denes any ordering: The server may return
This usage has been deprecated along with LDAPv2,
the values of an attribute, the attributes in an entry, and
which was ocially retired in 2003.[10]
the entries found by a search operation in any order. This
follows from the formal denitions - an entry is dened as
a set of attributes, and an attribute is a set of values, and
3 Directory structure
sets need not be ordered.
The protocol provides an interface with directories that
follow the 1993 edition of the X.500 model:
An entry consists of a set of attributes.

4 Operations
4.1 Add

An attribute has a name (an attribute type or attribute

description) and one or more values. The attributes The ADD operation inserts a new entry into the directoryserver database.[11] If the distinguished name in the add
are dened in a schema (see below).

4.3

Delete

request already exists in the directory, then the server will current<when?> LDAP version). In LDAPv3, each sucnot add a duplicate entry but will set the result code in the cessful BIND request changes the authentication state of
add result to decimal 68, entryAlreadyExists.[12]
the session and each unsuccessful BIND request resets the
authentication state of the session.
LDAP-compliant servers will never dereference the
distinguished name transmitted in the add request
when attempting to locate the entry, that is, distin- 4.3 Delete
guished names are never de-aliased.
To delete an entry, an LDAP client transmits a properly
LDAP-compliant servers will ensure that the distin- formed delete request to the server.[15]
guished name and all attributes conform to naming
standards
A delete request must contain the distinguished
name of the entry to be deleted
The entry to be added must not exist, and the immediate superior must exist.
Request controls may also be attached to the delete
The command used for searching the entries is:
request
ldapsearch -h localhost -x -LLL -W Servers do not dereference aliases when processing
D
cn=admin,dc=example,dc=com
-b
[13]
a delete request
dc=example,dc=com
dn:
uid=user,ou=people,dc=example,dc=com
changetype: add objectClass: top objectClass: person
uid: user sn: last-name cn: common-name userPassword:
password
In
the
above
example,
uid=user,ou=people,dc=example,dc=com must not
exist, and ou=people,dc=example,dc=com must exist.

4.2

Bind (authenticate)

When an LDAP session is created, that is, when an LDAP

client connects to the server, the authentication state of
the session is set to anonymous. The BIND operation establishes the authentication state for a session.

Only leaf entries (entries with no subordinates) may

be deleted by a delete request. Some servers support an operational attribute hasSubordinates whose
value indicates whether an entry has any subordinate
entries, and some servers support an operational attribute numSubordinates[16] indicating the number
of entries subordinate to the entry containing the
numSubordinates attribute.
Some servers support the subtree delete request control permitting deletion of the DN and all objects
subordinate to the DN, subject to access controls.
Delete requests are subject to access controls, that
is, whether a connection with a given authentication
state will be permitted to delete a given entry is governed by server-specic access control mechanisms.

Simple BIND and SASL PLAIN can send the users DN

and password in plaintext, so the connections utilizing
4.4 Search and Compare
either Simple or SASL PLAIN should be encrypted using Transport Layer Security (TLS). The server typically
The Search operation is used to both search for and read
checks the password against the userPassword attribute
entries. Its parameters are:
in the named entry. Anonymous BIND (with empty DN
and password) resets the connection to anonymous state.
baseObject The name of the base object entry (or posSASL (Simple Authentication and Security Layer) BIND
sibly the root) relative to which the search is to be
provides authentication services through a wide range of
performed.
mechanisms, e.g. Kerberos or the client certicate sent
with TLS.[14]
scope What elements below the baseObject to search.
This can be BaseObject (search just the named enBIND also sets the LDAP protocol version. The vertry, typically used to read one entry), singleLevel
sion is an integer and at present must be either 2 (two)
(entries immediately below the base DN), or wholeor 3 (three), although the standard supports integers beSubtree (the entire subtree starting at the base DN).
tween 1 and 127 (inclusive) in the protocol. If the client
requests a version that the server does not support, the lter Criteria to use in selecting elements within
server must set the result code in the BIND response to
scope.
For example, the lter (&(objectthe code for a protocol error. Normally clients should use
Class=person)(|(givenName=John)(mail=john*)))
LDAPv3, which is the default in the protocol but not alwill select persons (elements of objectClass
ways in LDAP libraries.
person) where the matching rules for givenName
BIND had to be the rst operation in a session
and mail determine whether the values for those
in LDAPv2, but is not required in LDAPv3 (the
attributes match the lter assertion. Note that

4 OPERATIONS
a common misconception is that LDAP data is
case-insensitive, whereas in fact matching rules and
ordering rules determine matching, comparisons,
and relative value relationships. If the example lters were required to match the case of the attribute
value, an extensible match lter must be used, for
example,
(&(objectClass=person)(|(givenName:
caseExactMatch:=John)(mail:
caseExactSubstringsMatch:=john*)))

There is also a modify-increment extension which allows

an incrementable attribute value to be incremented by a
specied amount. The modify-increment extension uses
object identier 1.3.6.1.1.14. The following example using LDIF increments employeeNumber by 5:
dn:
uid=user.0,ou=people,dc=example,dc=com
changetype: modify increment: employeeNumber
employeeNumber: 5 -

When LDAP servers are in a replicated topology, LDAP

derefAliases Whether and how to follow alias entries clients should consider using the post-read control to ver(entries that refer to other entries),
ify updates instead of a search after an update.[18] The
post-read control is designed so that applications need
attributes Which attributes to return in result entries.
not issue a search request after an update it is bad
sizeLimit, timeLimit Maximum number of entries to form to retrieve an entry for the sole purpose of checking
return, and maximum time to allow search to run. that an update worked because of the replication eventual
These values, however, cannot override any restric- consistency model. An LDAP client should not assume
tions the server places on size limit and time limit. that it connects to the same directory server for each request because architects may have placed load-balancers
typesOnly Return attribute types only, not attribute valor LDAP proxies or both between LDAP clients and
ues.
servers.
The server returns the matching entries and potentially
continuation references. These may be returned in any 4.6 Modify DN
order. The nal result will include the result code.
The Compare operation takes a DN, an attribute name Modify DN (move/rename entry) takes the new RDN
and an attribute value, and checks if the named entry con- (Relative Distinguished Name), optionally the new parents DN, and a ag that says whether to delete the
tains that attribute with that value.
value(s) in the entry that match the old RDN. The server
may support renaming of entire directory subtrees.

4.5

Modify

The MODIFY operation is used by LDAP clients to request that the LDAP server make changes to existing
entries.[17] Attempts to modify entries that do not exist
will fail. MODIFY requests are subject to access controls as implemented by the server.

An update operation is atomic: Other operations will

see either the new entry or the old one. On the other
hand, LDAP does not dene transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the meantime.
Servers may implement extensions[19] that support this,
though.

The MODIFY operation requires that the distinguished

name (DN) of the entry be specied, and a sequence of
4.7
changes. Each change in the sequence must be one of:

Extended operations

add (add a new value, which must not already exist The Extended Operation is a generic LDAP operation
that can dene new operations that were not part of
in the attribute)
the original protocol specication. StartTLS is one of
delete (delete an existing value)
the most signicant extensions. Other examples include
replace (replace an existing value with a new value) Cancel and Password Modify.
LDIF example of adding a value to an attribute:

4.7.1 StartTLS

dn: dc=example,dc=com changetype: modify add: cn cn:

The StartTLS operation establishes Transport Layer Sethe-new-cn-value-to-be-added curity (the descendant of SSL) on the connection. It can
To replace the value of an existing attribute, Use the re- provide data condentiality (to protect data from being
place keyword. If the attribute is multi-valued, the client observed by third parties) and/or data integrity protecmust specify the value of the attribute to delete.
tion (which protects the data from tampering). During
To delete an attribute from an entry, use the keyword TLS negotiation the server sends its X.509 certicate to
delete and the changetype designator modify. If the at- prove its identity. The client may also send a certicate to
tribute is multi-valued, the client must specify the value prove its identity. After doing so, the client may then use
SASL/EXTERNAL. By using the SASL/EXTERNAL,
of the attribute to delete.

5
the client requests the server derive its identity from credentials provided at a lower level (such as TLS). Though
technically the server may use any identity information
established at any lower level, typically the server will use
the identity information established by TLS.

DN is the distinguished name to use as the search

base.
attributes is a comma-separated list of attributes to
retrieve.

scope species the search scope and can be base

Servers also often support the non-standard LDAPS
(the default), one or sub.
(Secure LDAP, commonly known as LDAP over
SSL) protocol on a separate port, by default 636.
lter is a search lter. For example (objectClass=*)
LDAPS diers from LDAP in two ways: 1) upon conas dened in RFC 4515.
nect, the client and server establish TLS before any
extensions are extensions to the LDAP URL format.
LDAP messages are transferred (without a StartTLS operation) and 2) the LDAPS connection must be closed
For example, "ldap://ldap.example.com/cn=John%
upon TLS closure.
20Doe,dc=example,dc=com" refers to all user attributes
It should be noted that some LDAPS client libraries in John Does entry in ldap.example.com, while "ldap:
only encrypt communication, they do not check the host ///dc=example,dc=com??sub?(givenName=John)"
name against the name in the supplied certicate.[20]
searches for the entry in the default server (note the
triple slash, omitting the host, and the double question
mark, omitting the attributes). As in other URLs, special
4.8 Abandon
characters must be percent-encoded.
The Abandon operation requests that the server abort an
operation named by a message ID. The server need not
honor the request. Neither Abandon nor a successfully
abandoned operation send a response. A similar Cancel
extended operation does send responses, but not all implementations support this.

4.9

Unbind

There is a similar non-standard ldaps: URL scheme for

LDAP over SSL. This should not be confused with LDAP
with TLS, which is achieved using the StartTLS operation
using the standard ldap: scheme.

6 Creating a new object class and

adding attributes

The Unbind operation abandons any outstanding opera- 1. Create a new schema le (say, abc.schema) for the new
tions and closes the connection. It has no response. The object class with the additional attributes required[24]
name is of historical origin, and is not the opposite of the
attributetype ( 1.3.6.1.4.1.4203.666.1.90 NAME
Bind operation.[21]
'New_Attribute'
EQUALITY
caseIgnoreMatch
Clients can abort a session by simply closing the con- SUBSTR
caseIgnoreSubstringsMatch
SYNTAX
nection, but they should use Unbind.[22] Unbind allows 1.3.6.1.4.1.1466.115.121.1.15{1024} ) ... objectClass (
the server to gracefully close the connection and free re- 1.3.6.1.4.1.4203.666.1.100 NAME 'New_Class DESC
sources that it would otherwise keep for some time until 'Desc' SUP inetOrgPerson STRUCTURAL MAY (
discovering the client had abandoned the connection. It New_Attribute $ ... other attribute names separated by $
also instructs the server to cancel operations that can be ... ) )
canceled, and to not send responses for operations that
2. Create a conguration le (say, abc.conf) and add the
cannot be canceled.[23]
path of the schema le in it

LDAP URLs

include
/etc/ldap/schema/inetorgperson.schema
...
(other required object classes) include
/path_to_new_schema_le/abc.schema

An LDAP URL format exists, which clients support in 3. Create a new directory (or use an existing one) and
varying degrees, and servers return in referrals and con- run the slaptest command to generate the ldif le in that
tinuation references (see RFC 4516):
directory for the new conf le
ldap://host:port/DN?attributes?scope?filter?extensions
Most of the components described below are optional.

slaptest -f /path_of_conf_le/abc.conf -F Destination_directory

New
ldif
le
is
created
in
Destina host is the FQDN or IP address of the LDAP server tion_directory/cn=cong/cn=schema/cn={0}abc.ldif
to search.
4. change the le cn={0}abc.ldif:
port is the network port (default port 389) of the replace
LDAP server.

8 VARIATIONS

dn: cn={0}abc
by
dn: cn=abc, cn=schema, cn=cong
and remove the structural entries.
5. Add the ldif le to LDAP using ldapadd command

The schema denes object classes. Each entry must have

an objectClass attribute, containing named classes dened in the schema. The schema denition of the classes
of an entry denes what kind of object the entry may represent - e.g. a person, organization or domain. The object
class denitions also dene the list of attributes that must
contain values and the list of attributes which may contain
values.

For example, an entry representing a person might be-f long to the classes top and person. Membership in
the person class would require the entry to contain the
sn and cn attributes, and allow the entry also to contain userPassword, telephoneNumber, and other at7 Schema
tributes. Since entries may have multiple ObjectClasses
values, each entry has a complex of optional and mandaThe contents of the entries in a subtree are governed by tory attribute sets formed from the union of the object
a directory schema, a set of denitions and constraints classes it represents. ObjectClasses can be inherited, and
concerning the structure of the directory information tree a single entry can have multiple ObjectClasses values that
dene the available and required attributes of the entry it(DIT).
self. A parallel to the schema of an objectClass is a class
The schema of a Directory Server denes a set of rules
denition and an instance in Object-oriented programthat govern the kinds of information that the server can
ming, representing LDAP objectClass and LDAP entry,
hold. It has a number of elements, including:
respectively.
sudo ldapadd -x -D
/path_to_ldif_le/abc.ldif

cn=cong

-W

Attribute SyntaxesProvide information about the Directory servers may publish the directory schema conkind of information that can be stored in an attribute. trolling an entry at a base DN given by the entrys subschemaSubentry operational attribute. (An operational
Matching RulesProvide information about how to attribute describes operation of the directory rather than
make comparisons against attribute values.
user information and is only returned from a search when
Matching Rule UsesIndicate which attribute it is explicitly requested.)
types may be used in conjunction with a particular Server administrators can add additional schema entries
matching rule.
in addition to the provided schema elements. A schema
for representing individual people within organizations is
Attribute TypesDene an object identier (OID)
termed a white pages schema.
and a set of names that may be used to refer to a
given attribute, and associates that attribute with a
syntax and set of matching rules.
Object ClassesDene named collections of attributes and classify them into sets of required and
optional attributes.

8 Variations

Name FormsDene rules for the set of attributes A lot of the server operation is left to the implementor or
administrator to decide. Accordingly, servers may be set
that should be included in the RDN for an entry.
up to support a wide variety of scenarios.
Content RulesDene additional constraints about
the object classes and attributes that may be used in For example, data storage in the server is not specied the server may use at les, databases, or just be a gateconjunction with an entry.
way to some other server. Access control is not standard Structure RuleDene rules that govern the kinds ized, though there has been work on it and there are comof subordinate entries that a given entry may have. monly used models. Users passwords may be stored in
their entries or elsewhere. The server may refuse to perAttributes are the elements responsible for storing infor- form operations when it wishes, and impose various limmation in a directory, and the schema denes the rules its.
for which attributes may be used in an entry, the kinds Most parts of LDAP are extensible. Examples: One can
of values that those attributes may have, and how clients dene new operations. Controls may modify requests and
may interact with those values.
responses, e.g. to request sorted search results. New
Clients may learn about the schema elements that the search scopes and Bind methods can be dened. Atserver supports by retrieving an appropriate subschema tributes can have options that may modify their semansubentry.
tics.

Other data models

As LDAP has gained momentum, vendors have provided

it as an access protocol to other services. The implementation then recasts the data to mimic the LDAP/X.500
model, but how closely this model is followed varies.
For example, there is software to access SQL databases
through LDAP, even though LDAP does not readily lend
itself to this.[25] X.500 servers may support LDAP as
well.
Similarly, data previously held in other types of data
stores are sometimes moved to LDAP directories. For
example, Unix user and group information can be stored
in LDAP and accessed via PAM and NSS modules.
LDAP is often used by other services for authentication.
An example of such data model is the GLUE Schema,[26]
which is used in a distributed information system based
on LDAP that enable users, applications and services to
discover which services exist in a Grid infrastructure and
further information about their structure and state.

Hierarchical database model

Key server (cryptographic)
LDAP Application Program Interface
List of LDAP software
Simple Authentication and Security Layer (SASL)
Ambiguous name resolution

12 References
[1] Network Working Group RFC 4511. IETF.org. 200606-01. Retrieved 2014-04-04.
[2] Directory Services LDAP.
2014-04-04.

Oracle.com.

Retrieved

[3] What is LDAP?. Gracion.com. Retrieved on 2013-0717.

[4] LDAP - Lightweight Directory Access Protocol. Webopedia.com. Retrieved 2014-04-05.

10

Usage

An LDAP server may return referrals to other servers for

requests that it cannot fulll itself. This requires a naming
structure for LDAP entries so one can nd a server holding a given distinguished name (DN), a concept dened
in the X.500 Directory and also used in LDAP. Another
way of locating LDAP servers for an organization is a
DNS server record (SRV).

[5] The X.500 series - ITU-T Rec. X.500 to X.521

[6] Howes, Tim. The Lightweight Directory Access Protocol: X.500 Lite. Retrieved 26 December 2012.
[7] Pre-History of LDAP. Cyber Matters. Retrieved 5 October 2014.
[8] Service Name and Transport Protocol Port Number Registry. IANA. Retrieved 7 May 2014.
[9] Global Catalog and LDAP Searches. 2014-08-05. Re-

An organization with the domain example.org may use

trieved 2014-08-05.
the top level LDAP DN dc=example,dc=org (where
dc means domain component). If the LDAP server [10] RFC3494
is also named ldap.example.org, the organizations top
[11] Add section of RFC4511
level LDAP URL becomes ldap://ldap.example.org/dc=
example,dc=org.
[12] LDAP result codes
Primarily two common styles of naming are used in both
X.500 [2008] and LDAPv3. These are documented
in the ITU specications and IETF RFCs. The original form takes the top level object as the country object, such as c=US, c=FR. The domain component model
uses the model described above. An example of country based naming could be l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR, or in the
US: cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US.

11

See also

[13] http://www.linuxcommand.org/man_pages/ldapsearch1.
html
[14] SASL Mechanisms at IANA
[15] RFC4511: delete request
[16] Boreham Draft (numSubordinates)
[17] Modify Section of RFC4511
[18] Zeilenga, K.. Lightweight Directory Access Protocol
(LDAP) Read Entry Controls. IETF. RFC 4527. https:
//tools.ietf.org/html/rfc4527.
[19] INTERNET-DRAFT LDAP Transactions draft-zeilengaldap-txn-15.txt

Federated Naming Service

[20] Shibboleth Security alert 20120227

Global Directory Server

[21] Tools.ietf.org

Hesiod (name service)

[22] Tools.ietf.org

14

[23] Tools.ietf.org
[24] Creating object classes and attributes. http://www.
yolinux.com. Retrieved 22 September 2014.
[25] Openldap.org
[26] SourceForge : Project Home

12.1

Notes

ITU-T Rec. X.680, Abstract Syntax Notation One

(ASN.1) - Specication of Basic Notation, 1994

EXTERNAL LINKS

14 External links
Devshed.com, Understanding LDAP, A simple,
light introductory tutorial for LDAP.
Skills-1st.co.uk, LDAP schema design
Capitalhead.com, Troubleshooting LDAP SSL connection issues between Microsoft ILM/MIIS &
Novell eDirectory 8.7.3
Prasannatech.com, LDAP schema design - A Case
Study

LDAP esoterica, Deep-dive LDAP esoterica

Basic encoding rules (BER) - ITU-T Rec. X.690,
Specication of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules,
14.1 RFCs
1994
RFC 3641 - Generic String Encoding Rules (GSER) LDAP is specied in a series of Request for Comments
documents:
for ASN.1 Types
RFC 4346 - The TLS Protocol Version 1.1
RFC 4422 - Simple Authentication and Security
Layer (SASL)
SASL mechanisms registered at IANA
This article is based on material taken from the Free
On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the relicensing
terms of the GFDL, version 1.3 or later.

13

Further reading

RFC 4510 - LDAP: Technical Specication Road

Map (Obsoletes: RFC 2251, RFC 2252, RFC 2253,
RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC
2830, RFC 3377, RFC 3771)
RFC 4511 - LDAP: The Protocol (Obsoletes RFC
2251, RFC 2830 & RFC 3771)
RFC 4512 - LDAP: Directory Information Models (Obsoletes RFC 2251, RFC 2252, RFC 2256 &
RFC 3674)
RFC 4513 - LDAP: Authentication Methods and
Security Mechanisms (Obsoletes RFC 2251, RFC
2829 & RFC 2830)

Arkills, B (2003). LDAP Directories Explained: An

Introduction and Analysis. Addison-Wesley Professional. ISBN 0-201-78792-X.

RFC 4514 - LDAP: String Representation of Distinguished Names (Obsoletes RFC 2253)

Carter, G (2003). LDAP System Administration.

O'Reilly Media. ISBN 1-56592-491-6.

RFC 4515 - LDAP: String Representation of Search

Filters (Obsoletes RFC 2254)

Donley, C (2002). LDAP Programming, Management, and Integration. Manning Publications. ISBN
1-930110-40-5.

RFC 4516 - LDAP: Uniform Resource Locator

(Obsoletes RFC 2255)

Howes, T; Smith, M; Good, G (2003).

Understanding and Deploying LDAP Directory
Services. Addison-Wesley Professional. ISBN
0-672-32316-8.
Rhoton, J (1999). Programmers Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. Elsevier.
ISBN 1-55558-212-5.

RFC 4517 - LDAP: Syntaxes and Matching Rules

(Obsoletes RFC 2252 & RFC 2256, Updates RFC
3698)
RFC 4518 - LDAP: Internationalized String Preparation
RFC 4519 - LDAP: Schema for User Applications
(Obsoletes RFC 2256, Updates RFC 2247, RFC
2798 & RFC 2377)

Voglmaier, R (2003). The ABCs of LDAP: How to

Install, Run, and Administer LDAP Services. Auer- The following RFCs detail LDAP-specic Best Current
bach Publications. ISBN 0-8493-1346-5.
Practices:

14.1

RFCs

RFC 4520 (also BCP 64) - Internet Assigned

Numbers Authority (IANA) Considerations for the
Lightweight Directory Access Protocol (LDAP) (replaced RFC 3383)

RFC 4403 - LDAP Schema for UDDI

RFC 4521 (also BCP 118) - Considerations for

Lightweight Directory Access Protocol (LDAP) Extensions

RFC 4524 - LDAP: COSINE Schema (replaces

RFC 1274)

RFC 4522 - LDAP: Binary Encoding Option

RFC 4523 - LDAP: X.509 Certicate Schema

RFC 4525 - LDAP: Modify-Increment Extension

The following is a partial list of RFCs specifying
LDAPv3 extensions:

RFC 4526 - LDAP: Absolute True and False Filters

RFC 4527 - LDAP: Read Entry Controls

RFC 2247 - Use of DNS domains in distinguished

names (Updated by RFC 4519 & RFC 4524)
RFC 2307 - Using LDAP as a Network Information
Service

RFC 4528 - LDAP: Assertion Control

RFC 4529 - LDAP: Requesting Attributes by Object
Class

RFC 2589 - LDAPv3: Dynamic Directory Services

Extensions

RFC 4530 - LDAP: entryUUID

RFC 2649 - LDAPv3 Operational Signatures

RFC 4532 - LDAP Who am I? Operation

RFC 2696 - LDAP Simple Paged Result Control

RFC 4533 - LDAP Content Sync Operation

RFC 2798 - inetOrgPerson LDAP Object Class

(Updated by RFC 3698, RFC 4519 & RFC 4524)

RFC 4876 - Conguration Prole Schema for

LDAP-Based Agents

RFC 2830 - LDAPv3: Extension for Transport

Layer Security

RFC 5020 - LDAP entryDN Operational Attribute

RFC 4531 - LDAP Turn Operation

RFC 2849 - The LDAP Data Interchange Format LDAPv2 was specied in the following RFCs:
(LDIF)
RFC 1777 - Lightweight Directory Access Protocol
RFC 2891 - Server Side Sorting of Search Results
(replaced RFC 1487)
RFC 3045 - Storing Vendor Information in the
RFC 1778 - The String Representation of Standard
LDAP root DSE
Attribute Syntaxes (replaced RFC 1488)
RFC 3062 - LDAP Password Modify Extended Op RFC 1779 - A String Representation of Distineration
guished Names (replaced RFC 1485)
RFC 3296 - Named Subordinate References in
LDAP Directories
LDAPv2 was moved to historic status by the following
RFC:
RFC 3671 - Collective Attributes in LDAP
RFC 3672 - Subentries in LDAP
RFC 3673 - LDAPv3: All Operational Attributes
RFC 3687 - LDAP Component Matching Rules
RFC 3698 - LDAP: Additional Matching Rules
RFC 3829 - LDAP Authorization Identity Controls
RFC 3866 - Language Tags and Ranges in LDAP
RFC 3909 - LDAP Cancel Operation
RFC 3928 - LDAP Client Update Protocol
RFC 4370 - LDAP Proxied Authorization Control
RFC 4373 - LBURP

RFC 3494 - Lightweight Directory Access Protocol

version 2 (LDAPv2) to Historic Status

10

15

15
15.1

TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

Text and image sources, contributors, and licenses

Text

Lightweight Directory Access Protocol Source:

http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol?oldid=
631845616 Contributors: Tobias Hoevekamp, Taw, Ed Poor, Amillar, Arcade, Khendon, SJK, Hotlorp, Chris Q, Edward, Pnm, Looxix,
Ronabop, Ahoerstemeier, Aragorn2, Poor Yorick, Gamma, Redjar, Emperorbma, Dmsar, Jay, Greenrd, Pedant17, Tero, Taxman, Bevo,
Chuunen Baka, Robbot, Chealer, Alexbatko, RedWolf, Nurg, Rasmus Faber, GerardM, Wereon, Ruakh, BigSmoke, MilkMiruku, Tobias
Bergemann, WRJ, Levin, Georgesawyer, Varlaam, Rick Block, Matt Crypto, Darrien, Angelo.romano, Pgan002, SebastianBreier, Quadell,
Beland, Oneiros, Maximaximax, ZZyXx, TRS-80, EagleOne, Thorwald, MMSequeira, JTN, RossPatterson, Wk muriithi, Hhielscher,
Dolda2000, Bender235, Dewet, ESkog, Jarsyl, Nabber00, CanisRufus, Kwamikagami, JoeHenzi, Southen, PatrikR, MarkWahl, Polluks,
Mrbill, Giraedata, Jxn, Joe Jarvis, Cavrdg, CKlunck, Lysdexia, Jumbuck, Stephan Leeds, Tedp, Randy Johnston, Waddey, Woohookitty,
Mindmatrix, Jonathan de Boyne Pollard, Armando, Isnow, Turnstep, Scratchy, Monk, Pabix, Jeschuler, DoubleBlue, Manster, Fred
Bradstadt, AJackl, Juliank, Gurch, Grs1969, Joonga, Bcwhite, YurikBot, Wavelength, Tyler.szabo, Piet Delport, IanManka, Premil,
Rsrikanth05, Wiki alf, Exien, Dogcow, Nick, Mortein, Brandon, BOT-Superzerocool, Smaines, Great Cthulhu, Nippoo, Rageear,
SmackBot, Yingyang, Folajimi, Amux, Thumperward, Stevage, Asciberras, Sadads, Rwoodsmall, Dustimagic, Omniplex, DHN-bot,
Jdthood, RFightmaster, Rnapier, Jiddisch, Shadow1, Emmanuel JARRI, HFuruseth, Iridescence, Intersol, DavidHallett, EmirA, The
undertow, Piee, Kuru, Breno, Kdz, Tlesher, Almightylinuxgod, Doczilla, Kvng, Lee Carre, Hu12, EZio, IronJohnSr, Dokaspar,
Wsheward, CmdrObot, ShelfSkewed, Pit@0x.at, Equendil, Phatom87, Jordan Brown, Dennette, UncleBubba, Tbird1965, Pascal.Tesson,
Lesterrivera, Christian75, Kozuch, Peterblaise, Atstarr, Thijs!bot, MooingLemur, Marek69, Towo, Gpallis, Dawnseeker2000, Charles
Brooking, AntiVandalBot, Konman72, Uselesswarrior, VictorAnyakin, JAnDbot, Deective, NLuchs, Snupha, Bahar101, J-stan, Mr
stupid, Bouktin, Magioladitis, VoABot II, Ff1959, DerHexer, DGG, S3000, STBot, J.delanoy, Wojtekpia, Lukegm, Javawizard, Helon,
Andareed, Gman124, Jbm212, Srpnor, Marty.oe, Cometstyles, Vanished user 39948282, Marc Esnouf, Brvman, Remi0o, Crkey,
Andrew Findlay, Timotab, VolkovBot, IWhisky, Augustan, AlnoktaBOT, Jwilleke, Benjamin Barenblat, Parpauta, TXiKiBoT, Vitund,
Treydrake, Combatentropy, Anna Lincoln, Saligron, Highlandsun, Broadbot, DragonLord, Wilsonhughes, AlleborgoBot, Kbrose, SieBot,
Danpritts, VVVBot, Wageslave, Brevantes, Pxma, Flyer22, Abeld, Arknascar44, Oxymoron83, StaticGull, Denisarona, Mpeylo, ClueBot,
Czarko, Yohann.martineau, Rhubbarb, Manishearth, Anon lynx, Mallamace, Thingg, Lazki, Stickee, Subversive.sound, Addbot,
Ghettoblaster, SmartIcon, Atethnekos, Tothwolf, Lost on belmont, Grovejary, RW Dutton, Tide rolls, Lightbot, OlEnglish, JakobVoss,
Luckas-bot, Yobot, Mslinn, AnomieBOT, Flewis, Materialscientist, Citation bot, Quebec99, Jordav, Renaissancee, Anna Frodesiak, Mark
Schierbecker, Dalesc, FrescoBot, Shshme, Winterst, A8UDI, Jschnur, LCE1506, Lotje, Kalzekdor, DrRogla, EmausBot, WikitanvirBot,
Timtempleton, BabsiSnoecks, Sams sun, Wbenton, RodWiddowson, Manavmohanty, Neelkanthtriptathi, ChuispastonBot, Avijit.ghosal,
ClueBot NG, Jaanis2010, ANGELUS, The Master of Mayhem, SubTenebra, Ryan Vesey, Diningphil, Helpful Pixie Bot, BG19bot,
Nsda, Compfreak7, Klilidiplomus, YFdyh-bot, JesseAlanGordon, TwoTwoHello, Drewbigs, Camayoc, Allen.sampsell, Tango303,
DavidLeighEllis, ArmbrustBot, Keraunos-5, JaconaFrere, Unician, Varshini kumavath, Sakshi94 and Anonymous: 524

15.2

Images

File:Edit-clear.svg Source: http://upload.wikimedia.org/wikipedia/en/f/f2/Edit-clear.svg License: ? Contributors: The Tango! Desktop

Project. Original artist:
The people from the Tango! project. And according to the meta-data in the le, specically: Andreas Nilsson, and Jakub Steiner (although
minimally).

15.3

Content license

Creative Commons Attribution-Share Alike 3.0