LDAP
http://en.wikipedia.org/wiki/Ldap
Lightweight Directory
Access Protocol
LDAP
LDAP

An application protocol


For querying and modifying directory services
Runs over TCP/IP
LDAP

Directory

A set of objects with similar attributes


Organized in a logical and hierarchical manner
Example:

Telephone directory




Series of names (either of persons or organizations)
Organized alphabetically
Each name has an address and phone number
LDAP is often used by other services for
authentication
LDAP

LDAP directory tree

Often reflects various




Political
Geographic
Organizational boundaries
Depends on the model chosen
LDAP

LDAP deployments today tend to use Domain Name
System (DNS) names for structuring the topmost
levels of the hierarchy

Deep inside the directory might appear entries
representing






People
Organizational units
Printers
Documents
Groups of people
Anything else which represents a given tree entry (or multiple
entries)
LDAP Data Structure
Hierarchical
dc: domain component
ou: organizational unit
Flat
LDAP

Current version is LDAPv3

Specified in a series of Internet Engineering Task
Force Standard Track Requests for comments
(RFCs)

Detailed in RFC 4510
Origin and influences
Origin and influences

Telecommunication companies introduced the
concept of directory services to information
technology and computer networking


Understanding of directory requirements was welldeveloped after some 70 years of producing and managing
telephone directories
The culmination of this input was the comprehensive
X.500 specification

Suite of protocols produced by the International
Telecommunication Union (ITU) in the 1980s
Origin and influences

X.500 directory services

Accessed via the X.500 Directory Access Protocol



Required the Open Systems Interconnection (OSI)
protocol stack
LDAP originally intended to be a "lightweight"
alternative protocol for accessing X.500 directory
services


DAP
Through the simpler TCP/IP protocol stack
Model of directory access was borrowed from other
protocols


DIXIE
Directory Assistance Service
Origin and influences

Standalone LDAP directory servers followed


LDAP has become popular in enterprises


Also directory servers supporting both DAP and
LDAP
Removed any need to deploy an OSI network
X.500 directory protocols including DAP can
also be used directly over TCP/IP
Origin and influences

Protocol was originally created by:





Tim Howes of the University of Michigan
Steve Kille of ISODE
Wengyik Yeong of Performance Systems
International
Circa 1993
Further development done by the IETF
Origin and influences

Early engineering stages of LDAP


Known as Lightweight Directory Browsing
Protocol, or LDBP
Renamed as the scope of the protocol was
expanded to include:


Directory browsing and searching functions
Directory update functions
Origin and influences

LDAP has influenced subsequent Internet
protocols, including





Later versions of X.500
XML Enabled Directory (XED)
Directory Service Markup Language (DSML)
Service Provisioning Markup Language (SPML)
Service Location Protocol (SLP)
Protocol overview
Protocol overview

Client starts an LDAP session by connecting to an
LDAP server


Client sends operation requests to the server


Default on TCP port 389
Server sends responses in turn
With some exceptions the client need not wait for a
response before sending the next request

Server may send the responses in any order
Protocol
overview
Client may request the following operations:


Start TLS



Bind





Generic operation used to define other operations
Unbind


Abort a previous request
Extended Operation


Move or rename an entry
Abandon


Test if a named entry contains a given attribute value
Add a new entry
Delete an entry
Modify an entry
Modify Distinguished Name (DN)


Search for and/or retrieve directory entries
Compare


Authenticate and specify LDAP protocol version
Search


Optional
Protect the connection with Transport Layer Security (TLS)
Close the connection (not the inverse of Bind)
Server may send "Unsolicited Notifications“


Not responses to any request
e.g. before it times out a connection
Protocol overview

Common alternate method of securing LDAP
communication is using an SSL tunnel

Denoted in LDAP URLs by using the URL scheme "ldaps"


Use of LDAP over SSL was common in LDAP Version 2



LDAPv2
Was never standardized in any formal specification
Usage has been deprecated along with LDAPv2


Default port for LDAP over SSL is 636
Officially retired in 2003
LDAP is defined in terms of ASN.1


Protocol messages are encoded in the binary format BER
Uses textual representations for a number of ASN.1
fields/types
Directory structure
Directory structure

Protocol accesses LDAP directories

Follows the 1993 edition of the X.500 model:



directory is a tree of directory entries
Entry consists of a set of attributes
An attribute has





Attributes are defined in a schema
Each entry has a unique identifier:


a name
an attribute type or attribute description
one or more values
Distinguished Name (DN)

Consists of its Relative Distinguished Name (RDN)
constructed from some attribute(s) in the entry

Followed by the parent entry's DN
Think of the DN as a full filename and the RDN as a relative
filename in a folder
Directory structure

DN may change over the lifetime of the entry


For instance, if entries move within a tree
To reliably and unambiguously identify entries

UUID might be provided in the set of the entry's
operational attributes
Directory structure


Note: LDAP is a binary protocol
Example entry represented in LDAP Data Interchange Format (LDIF):

dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1234
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

Where:

dn (distinguished name) is the name of the entry





it's not an attribute nor part of the entry
"cn=John Doe" is the entry's RDN
"dc=example,dc=com" is the DN of the parent entry.
Other lines show the attributes in the entry
Attribute names are typically mnemonic strings




"cn" for common name,
"dc" for domain component
"mail" for e-mail address
"sn" for surname
Directory structure


A server holds a subtree starting from a specific entry, e.g.
"dc=example,dc=com" and its children
Servers may also hold references to other servers



An attempt to access
"ou=department,dc=example,dc=com" could return a
referral or continuation reference to a server which holds that part of
the directory tree
Client can then contact the other server
Some servers also support chaining

Server contacts other server(s) and returns the results to the client
Directory structure

LDAP rarely defines any ordering:

Server may return



the values in an attribute
the attributes in an entry
the entries found by a search operation
…in any order

Follows from the formal definitions



an entry is defined as a set of attributes
an attribute is a set of values
sets need not be ordered
Operations
Operations

Client gives each request a positive Message ID


Response includes a numeric result code indicating:




Server response has the Message ID returned
Success
An error condition
Or some other special cases
Before the response, the server may send other
messages with other result data

For example:

Each entry found by the Search operation is returned as a message
Operations: StartTLS

StartTLS operation


Establishes Transport Layer Security on the connection
 a descendant of SSL
Provides data confidentiality and/or data integrity
protection



Protect from tampering
During TLS negotiation server sends its X.509 certificate
to prove its identity
Client may also send a certificate to prove its identity

Client may then use SASL/EXTERNAL to have this identity
used in determining the identity used in making LDAP
authorization decisions
Operations: StartTLS

Servers often support the non-standard
LDAPS protocol on a separate port (default 636)

Secure LDAP, commonly known as LDAP over SSL

LDAPS differs from LDAP in two ways:



1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a
Start TLS operation)
2) the LDAPS connection must be closed upon TLS closure.
LDAPS primarily used with LDAPv2

StartTLS operation not yet been defined

Use of LDAPS is deprecated

Modern software should only use StartTLS
Operations: Bind (authenticate)

Bind operation authenticates the client to the server

Simple Bind can send the user's DN and password in plaintext


Server typically checks the password



Kerberos or the client certificate sent with TLS
Bind also sets the LDAP protocol version



Against the userPassword attribute in the named entry
Anonymous Bind (with empty DN and password) resets the
connection to anonymous state
SASL (Simple Authentication and Security Layer) Bind provides
authentication services through a wide range of mechanisms


Connection should be protected using Transport Layer Security (TLS)
Normally clients should use LDAPv3
Default in the protocol but not always in LDAP libraries
Bind had to be the first operation in a session in LDAPv2

Not required in LDAPv3 (the current LDAP version)
Operations: Search and Compare

The Search operation is used to both search for and read entries

Its parameters are:

baseObject


scope




Which attributes to return in result entries
sizeLimit, timeLimit


Whether and how to follow alias entries (entries which refer to other entries)
attributes


How to examine each entry in the scope. E.g.
(&(objectClass=person)(|(givenName=John)(mail=john*)))

search for persons who either have given name John or an e-mail address starting
with john.
derefAliases


BaseObject (search just the named entry, typically used to read one entry)
SingleLevel (entries immediately below the base DN)
WholeSubtree (the entire subtree starting at the base DN)
filter


The DN (Distinguished Name) of the entry at which to start the search,
Max number of entries, and max search time
typesOnly

Return attribute types only, not attribute values
Operations: Search and Compare

Server returns




Matching entries
Maybe continuation references (in any order)
Followed by the final result with the result code
Compare operation
 -a DN
 -an attribute name
 -an attribute value

Checks if the named entry contains that attribute with that
value
Operations: Update operations

Add, Delete, and Modify DN


Modify takes a list of attributes to modify and
the modifications to each:




All require the DN of the entry that is to be
changed
Delete the attribute of some values
Add new values
Replace the current values with the new ones.
Add operations also can have additional
attributes and values for those attributes
Operations: Update operations

Modify DN (move/rename entry) takes:




New RDN (Relative Distinguished Name)
(optionally) the new parent's DN
Flag which says whether to delete the value(s) in
the entry which match the old RDN
Server may support renaming of entire directory
subtrees
Operations: Update operations

An update operation is atomic:

Later operations will see either the new entry or
the old one
 LDAP
does not define transactions of multiple
operations
 If you read an entry and then modify it, another client
may have updated the entry in the mean time
 Servers may implement extensions which support this,
however
Operations: Extended operations

Extended Operation


A generic LDAP operation can be used to define
new operations
Examples include the



Cancel
Password Modify
Start TLS operations
Operations:

Abandon



The Abandon operation requests that the server
aborts an operation named by a message ID
The server need not honor the request
Neither Abandon nor a successfully
abandoned operation sends a response

Cancel: an extended operation which does send a
response

Not all implementations support cancel
Operations:

Unbind

The Unbind operation abandons any outstanding
operations and closes the connection


It has no response
Name is of historical origin:


It is not the opposite of the Bind operation.
Clients can abort a session by simply closing the
connection, but they should use Unbind

Otherwise server cannot tell the difference between a failed
network connection (or a truncation attack) and a discourteous
client
LDAP URLs
LDAP URLs

LDAP URL format exists
Clients support in varying degree
 Servers return in referrals and continuation
references

 (see

RFC 4516):
Typical form:

ldap://host:port/DN?attributes?scope?filter?extensions
LDAP URLs

Most components are optional








host is the DNS or IP address of the LDAP server to search
port is the network port of the LDAP server
DN is the distinguished name to use as the search base
attributes is a comma-separated list of attributes to retrieve
scope specifies the search scope and can be "base" (the default), "one" or "sub"
filter is a search filter, e.g. (objectClass=*) (see RFC 4515)
extensions are extensions to the LDAP URL format
Examples:
"ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com“

refers to all user attributes in John Doe's entry in ldap.example.com,

As in other URLs, special characters must be percent-encoded
"ldap:///dc=example,dc=com??sub?(givenName=John)"

searches for the entry in the default server






DN: example.com
No attributes
Scope: sub
Filter: givenName=John
No extensions
There is a similar non-standard "ldaps:" URL scheme for LDAP over SSL
Schema
Schema


Contents of the entries in a subtree are governed by a schema
Schema defines the attribute types that directory entries can
contain

Attribute definitions includes a syntax





Most non-binary values in LDAPv3 use UTF-8 string syntax
For example, a "mail" attribute might contain the value
"user@example.com"
A "jpegPhoto" attribute would contain photograph(s) in binary
JPEG/JFIF format
A "member" attribute contains DNs of other directory entries
Attribute definitions also specify


whether the attribute is single-valued or multi-valued
how to search/compare the attribute


e.g. case-sensitive vs. case-insensitive
whether substring matching is supported, etc.
Schema

The schema defines object classes

Each entry must have an objectClass attribute


The schema definition of the classes of an entry
defines what kind of object the entry may
represent


Containing named classes defined in the schema
E.g. a person, organization or domain
The object class definitions also list which
attributes the entry MAY and MUST contain

For example, an entry representing a person might
belong to the classes "top" and "person"
Schema

The schema defines object classes (cont.)

Membership in the "person" class would

Require:


Allow:


the entry to contain the "sn" and "cn" attributes
the entry also to contain "userPassword",
"telephoneNumber", and other attributes
Since entries may belong to multiple classes



Each entry has a complex of optional and mandatory
attribute sets formed from the union of the object
classes it represents
ObjectClasses can be inherited
A single entry can have multiple objectClasses to
define the available and required attributes of the
Schema

Includes various other information controlling directory
entries


Most schema elements have a name and a globally unique Object
identifier (OID)
Directory servers may publish the directory schema controlling an
entry at a base DN given by the entry's subschemaSubentry
operational attribute


An operational attribute describes operation of the directory rather than
user information and is only returned from a search when it is explicitly
requested
Server administrators can define their own schemas in
addition to the standard ones

A schema for representing individual people within organizations is
termed a white pages schema
Variations
Variations

A lot of the server operation is left to the implementer or
administrator to decide


Accordingly, servers may be set up to support a wide variety of scenarios
For example, data storage in the server is not specified:


Access control is not standardized





Server may use flat files, databases, or just be a gateway to some other server
There has been work on standardization
There are commonly used models
Users' passwords may be stored in their entries or elsewhere
Server may refuse to perform operations when it wishes, and impose various
limits
Most parts of LDAP are extensible

Examples:




One can define new operations
Controls may modify requests and responses, e.g. to request sorted search results
New search scopes and Bind methods can be defined
Attributes can have options that may modify their semantics
Other data models
Other data models

As LDAP has gained momentum:


Vendors have provided it as an access protocol to other services
Implementation then recasts the data to mimic the LDAP/X.500
model


For example:




How closely this model is followed varies
There is software to access SQL databases through LDAP
LDAP does not readily lend itself to this
X.500 servers may support LDAP as well
Similarly, data which were 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
Usage
Usage

Applications

Reasons to choose LDAP for a service:

Widely supported


LDAP is very general and includes basic security



Allows focusing on a few protocols
Instead of having to maintain and upgrade many specialized protocols
Two common applications of LDAP:


Computer user/group data
Address book information (persons, departments etc)


Can support many types of applications
Choosing general protocols like LDAP and HTTP for various services:


Data presented in LDAP is available to many clients and libraries
Many e-mail clients support LDAP lookups
Some tasks LDAP does not handle well:



Model a relational database
Data that is frequently updated
Data whose ordering must be preserved

An extension does exist for this
Usage

Naming structure

An LDAP server can return referrals to other servers for requests the
server itself will not/can not serve


A naming structure for LDAP entries is needed so one can find a server
holding a given DN
A structure already exists in the Domain name system (DNS)


If an organization has domain name foo.example

Its top level LDAP entry will therefore typically have the DN


dc=foo,dc=example
 where dc means domain component
If the ldap server is also named ldap.foo.example, the organization's top
level LDAP URL becomes


Servers' top level names often mimic DNS names
ldap://ldap.foo.example/dc=foo,dc=example
Below the top level, the entry names will typically reflect the
organization's internal structure or needs rather than DNS names
Terminology
Terminology

The LDAP terminology one can encounter can be confusing

Some of this confusion is due to misunderstandings



Other examples are due to its historical origins
Others arise when used with non-X.500 services that use different
terminology
For example,

"LDAP" is sometimes used to refer to the protocol





the attribute type
the contents of an attribute in a directory
an attribute description (an attribute type with options)
An "anonymous" and an "unauthenticated" Bind are different Bind
methods that both produce anonymous authentication state


An "LDAP directory" may be the data or also the access point
An "attribute" may be:


Other times to the protocol and the data
So both terms are being used for both variants
The "uid" attribute should hold user names rather than numeric user IDs
Closing remarks

LDAP is good for retrieving simple
hierarchical type of data




Lookup “directory” type of information
The data is already organized
LDAP is not good for relational type data
LDAP is not a good choice when the data is
changed or updated frequently
Resources:


http://www.ldapman.org/articles/intro_to_lda
p.html
http://quark.humbug.org.au/publications/ldap/
ldap_tut.html
Which is not a good use for LDAP:
1.
2.
3.
4.
Peoples names and
phone numbers
Departments and
department members
Relational Data
User names, userids,
and capabilities
98%
2%
1.
0%
2.
0%
3.
4.