THE
THELDAP
LDAPPROTOCOL
PROTOCOL
BY:
AJITAV BASAK
Branch-IT
Roll-07602
Regd.-0701287182
Origin of LDAP
Introduction of concept of directory services
X.500 or CCITT first approved in 1988.
X.500 used DAP
LDAP was originally intended to be a
lightweight alternative protocol
LDAP became popular
Today, X.500 directory protocols including
DAP can also be used directly over TCP/IP
Origin of LDAP(contd…)
Origin of LDAP(contd…)
it was primarily known as Lightweight Directory
Browsing Protocol, or LDBP
It was renamed with the expansion of the scope
of the protocol beyond directory browsing and
searching, to include directory update
functions
The latest version of LDAP is Version 3, which
is specified in a series of Internet Engineering
Task Force (IETF)
By whom was it developed?
The protocol was created by Tim Howes of
the University of Michigan, Steve Killes
of Isode Limited, and Wengyik
Yeong of Performance Systems International,
circa in 1993
Further development has come through
the Internet Engineering Task Force
What is LDAP?
Lightweight Directory Access Protocol
Used to access and update information in a
directory built on the X.500 model
Specification defines the content of messages
between the client and the server
Includes operations to establish and disconnect
a session from the server
How LDAP works?
How LDAP works?(contd…)
A client starts an LDAP session by connecting
to an LDAP server, called a Directory System
Agent (DSA), by default on TCP port 389
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
LDAP
Information
Structure of information stored in an LDAP
directory.
Naming
How information is organized and identified.
Functional / Operations
Describes what operations can be performed on the
information stored in an LDAP directory.
Security
Describes how the information can be protected
from unauthorized access.
LDAP Information Storage
LDAP Information Storage(contd…)
Each attribute has a type/syntax and a value
Can define how values behave during
searches/directory operations
Syntax: bin, ces, cis, tel, dn etc.
Usage limits:
ssn – only one, jpeg Photo – 10K
LDAP Information Storage(contd…)
Each ‘entry’ describes an object (Class)
Person, Server, Printer etc.
Example Entry:
InetOrgPerson(cn, sn, ObjectClass)
Example Attributes:
cn (cis), sn (cis), telephone Number (tel), ou (cis),
owner (dn), jpegPhoto (bin)
LDAP Naming
DNs(distinguished names) consist of sequence
of Relative DN
cn=John Smith,ou=Austin,o=IBM,c=US (Leaf 2 Root)
(~use \ for special)
Directory Information Tree (DIT)
Follow geographical or organizational scheme
Aliases: Tree-like
Aliases can link non-leaf nodes
May not store entire DIT
LDAP Functions/Operations
Authentication
BIND/UNBIND
ABANDON
Query
Search
Compare entry
Update
Add an entry
Delete an entry (Only Leaf nodes, no aliases)
Modify an entry, Modify DN/RDN
Client and Server Interaction
Client establishes session with server (BIND)
Hostname/IP and port number
Security
User-id/password based authentication
Anonymous connection - default access rights
Encryption/Kerberos also supported
Client performs operations
Read/Update/Search
SELECT X,Y,Z FROM PART_OF_DIRECTORY
Client ends the session (UNBIND)
Client can ABANDON the session
LDAP Security
Current LDAP version supports
Clear text passwords
KERBEROS version 4 authentication
Other authentication methods possible in
future versions (March 1995)
SASL support added in version 3
Kerberos deemed stronger than SASL…
LDAP Security(contd…)
No Authentication
Basic Authentication
DN and password provided
Clear-text or Base 64 encoded
SASL (RFC 2222)
Parameters: DN, mechanism, credentials
Provides cross protocol authentication calls
Encryption can be optionally negotiated
ldap_sasl_bind() (ver3 call)
Ldap://<ldap_server>/?supportedsaslmechanisms
LDAP Security(contd…)
Why Use LDAP?
an entire organization can be consolidated into
a central repository
sensitive data can be protected from prying
eyes.
supports a number of back-end databases in
which to store directories
Where preferred
• LDAP is well suited for
– Information that is referenced by many
entities and applications
– Information that needs to be accessed from
more than one location
• Roaming, e.g. by “Road Warriors”
• Preference information for web “portals”
– Information that is read more often than it is
written
When not
• LDAP is not well suited for
– Information that changes often (it is not a
relational database)
– Information that is unstructured (it is not a
file system)
Application of LDAP
Supporting vendors
Apache (through Apache Directory Server)
Apple (through Open Directory/OpenLDAP)
AT&T
Banyan
Critical Path
eB2Bcom (through View500)
Fedora Directory Server
Hewlett-Packard
Identyx
IBM/Lotus
Some other Supporting vendors
ISODE (through M-Vault server)
Microsoft (through Active Directory)
Netscape (now in Sun Microsystems and Red Hat
products)
Novell (through eDirectory)
OctetString (through VDE server)
Oracle (through Oracle Internet Directory)
Radiant Logic (through RadiantOne Virtual Directory
Server
Red Hat Directory Server
Siemens AG (through DirX server)
SGI and
Sun (through the iPlanet and Sun ONE directory servers)
Symlabs (through Directory Extender)
