Sie sind auf Seite 1von 8

Assignment No.

Title of Assignment:
Study OF LDAP (Light weight Directory Access Protocol)

Relevant Theory / Literature Survey:

Directory Service

A Directory is like a database: you can put information in,

and later retrieve it. But it is specialized. Some typical
characteristics are: designed for reading more than writing,
offers a static view of the data, simple updates without
transactions. Directories are tuned to give quick-response
to high-volume lookup or search operations.

A Directory Service sports all of the above, plus a network

protocol used to access the directory. And perhaps also a
replication scheme, a data distribution scheme.

The Lightweight Directory Access Protocol (LDAP) is a

protocol for accessing online directory services. It runs
directly over TCP, and can be used to access directory
services back-ended by X.500, standalone LDAP directory
services or other kinds of directory servers.


LDAP was originally developed as a front end to X.500, the

OSI directory service. X.500 defines the Directory Access
Protocol (DAP) for clients to use when contacting directory
servers. DAP is a heavyweight protocol that runs over a full
OSI stack and requires a significant amount of computing
resources to run. LDAP runs directly over TCP and provides
most of the functionality of DAP at a much lower cost. This
use of LDAP makes it easy to access the X.500 directory.

X500 in more depth

In X.500, the namespace is explicitly stated and is

hierarchical. Such namespaces require relatively complicated
management schemes. The naming model defined in X.500 is
concerned mainly with the structure of the entries in the
namespace, not the way the information is presented to the
user. Every entry in a X.500 Directory Information Tree, or
DIT, is a collection of attributes, each attribute composed
of a type element and one or more value elements.

The X.500 standard defines 17 object classes for directories

as a baseline. Being extensible, X.500 directories may
include other objects defined by implementers. The 17 basic
object classes include:

• Alias
• Country
• Locality
• Organization
• Organizational Unit
• Person

Objects in these object classes are defined by their

attributes. Some of the basic 40 attribute types include:

• Common Name (CN)

• Organization Name (O)
• Organizational Unit Name (OU)
• Locality Name (L)
• Street Address (SA)
• State or Province Name (S)
• Country (C)

Putting this all together, an unambiguous entry for an

addressee would be specified by its distinguished name, say
{C=US, O=Acme, OU=Sales, CN=Fred}

Sample X.500 hierarchy. Starting at the highest level, or

Root, we can traverse the tree to successively lower levels,
called Country, Organization, and Common Name, for instance.

Applications and users access the directory via a directory

user agent, or DUA. A DUA transfers the directory request to
a DSA, or Directory System Agent, via DAP, the Directory
Access Protocol. The directory itself is composed of one or
more DSAs. The DSAs can either communicate among themselves
to share directory information or may perform what is called
a referral, i.e., direct the DUA to use a specific DSA.
Referrals may occur when DSAs are not set up to exchange
directory information, perhaps due to lack of interworking
agreements between the administrators, or for security

The LDAP standard defines

• a network protocol for accessing information in the

directory. It defines the operations one may perform
e.g. search, add, delete, modify, change name. It also
defines how operations and data are conveyed.
• an information model defining the form and character of
the information
• a namespace defining how information is referenced and
• an emerging distributed operation model defining how
data may be distributed and referenced (v3)
• Both the protocol itself and the information model are

Data Types

Any data types can be into the directory: Text, Photos,

URLs, Pointers to whatever, Binary data, Public Key

Different types of data are held in attributes of different

types. Each attribute type has a particular syntax. The LDAP
standard describes a rich set of standard attribute types
and syntax (based on X.500's set). Plus, you may define your
own attributes, syntax, and even object classes -- you can
tailor your directory to your own site's specific needs.

The information model and namespace

They are based on Entries. An entry is simply a place where

one stores attributes. Each attribute has a type and one or
more values.

Entries themselves are "typed". This is accomplished by the

objectClass attribute.

The namespace is hierarchical, so it has the concept of

fully-qualified names called Distinguished Names (DN).
Here, test Entry's DN is "cn=test entry, ou=people,
dc=stanford, dc=edu"

Accessing an LDAP-based directory is accomplished by using a

combination of DN, filter, and scope. A base DN indicates
where in the hierarchy to begin the search. A filter
specifies attribute types, assertion values, and matching
criteria. A scope indicates what to search: the base DN
itself, one level below the base DN, the entire sub-tree
rooted at the base DN.

How does LDAP work?

LDAP directory service is based on a client-server model.

One or more LDAP servers contain the data making up the LDAP
directory tree. An LDAP client connects to an LDAP server
and asks it a question. The server responds with the answer,
or with a pointer to where the client can get more
information (typically, another LDAP server). No matter
which LDAP server a client connects to, it sees the same
view of the directory; a name presented to one LDAP server
references the same entry it would at another LDAP server.
This is an important feature of a global directory service,
like LDAP.

Key Points of LDAP:

• LDAP is an extensive, vendor-independent, open, network

PROTOCOL standard: so accessing data is done
transparently across a highly heterogeneous network
(i.e. the Internet).
• An LDAP-based directory supports any type of data.
• Can configure an LDAP-based directory to play
essentially any role.
• The LDAP protocol directly supports various forms of
strong security (authentication, privacy, and
integrity) technology.
• Can use general-purpose directory technology, such as
LDAP, to glue together disparate facets of cyberspace,
e.g. email, security, white- & yellow-pages,
directories, collaborative tools, MBone, etc.

Induvidual LDAP records

What's in a name? The DN of an LDAP entry

All entries stored in an LDAP directory have a unique

"Distinguished Name," or DN. The DN for each LDAP entry is
composed of two parts: the Relative Distinguished Name (RDN)
and the location within the LDAP directory where the record

The RDN is the portion of your DN that is not related to the

directory tree structure. Most items that you'll store in an
LDAP directory will have a name, and the name is frequently
stored in the cn (Common Name) attribute. Since nearly
everything has a name, most objects you'll store in LDAP
will use their cn value as the basis for their RDN. If I'm
storing a record for my favorite oatmeal recipe, I'll be
using cn=Oatmeal Deluxe as the RDN of my entry.

• My directory's base DN is dc=foobar,dc=com

• I'm storing all the LDAP records for my recipes in
• The RDN of my LDAP record is cn=Oatmeal Deluxe

Given all this, what's the full DN of the LDAP record for
this oatmeal recipe? Remember, it reads backwards - just
like a host name in DNS.

cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com

Now it's time to tackle the DN of a company employee. For

user accounts, you'll typically see a DN based either on the
cn or on the uid (User ID). For example, the DN for FooBar's
employee Fran Smith (login name: fsmith) might look like
either of these two formats:
LDAP (and X.500) use uid to mean "User ID", not to be
confused with the UNIX uid number. Most companies try to
give everyone a unique login name, so this approach makes
good sense for storing information about employees. You
don't have to worry about what you'll do when you hire the
next Fran Smith, and if Fran changes her name (marriage?
divorce? religious experience?), you won't have to change
the DN of the LDAP entry.

Here we see the Common Name (CN) entry used. In the case of
an LDAP record for a person, think of the common name as
their full name. One can easily see the downside to this
approach: if the name changes, the LDAP record has to "move"
from one DN to another. As indicated above, you want to
avoid changing the DN of an entry whenever possible.

An example of an induvidual LDAP entry.

Let's look at an example. We'll use the LDAP record of Fran

Smith, an employee from Foobar, Inc. The format of this
entry is LDIF, the format used when exporting and importing
LDAP directory entries.

dn: uid=fsmith, ou=employees, dc=foobar, dc=com

objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: foobarPerson
uid: fsmith
givenname: Fran
sn: Smith
cn: Fran Smith
cn: Frances Smith
telephonenumber: 510-555-1234
roomnumber: 122G
o: Foobar, Inc.
userpassword: {crypt}3x1231v76T89N
uidnumber: 1234
gidnumber: 1200
homedirectory: /home/fsmith
loginshell: /usr/local/bin/bash

To start with, attribute values are stored with case intact,

but searches against them are case-insensitive by default.
Certain attributes (like password) are case-sensitive when

Let's break this entry down and look at it piece by piece.

dn: uid=fsmith, ou=employees, dc=foobar, dc=com

This is the full DN of Fran's LDAP entry, including the
whole path to the entry in the directory tree. LDAP (and
X.500) use uid to mean "User ID," not to be confused with
the UNIX uid number.
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: foobarPerson

One can assign as many object classes as are applicable to

any given type of object. The person object class requires
that the cn (common name) and sn (surname) fields have
values. Object Class person also allows other optional
fields, including givenname, telephonenumber, and so on. The
object class organizationalPerson adds more options to the
values from person, and inetOrgPerson adds still more
options to that (including email information). Finally,
foobarPerson is Foobar's customized object class that adds
all the custom attributes they wish to track at their

uid: fsmith
givenname: Fran
sn: Smith
cn: Fran Smith
cn: Frances Smith
telephonenumber: 510-555-1234
roomnumber: 122G
o: Foobar, Inc.

As mentioned before, uid stands for User ID. Just translate

it in your head to "login" whenever you see it.

Note that there are multiple entries for the CN. As

mentioned above, LDAP allows some attributes to have
multiple values, with the number of values being arbitrary.
When would you want this? Let's say you're searching the
company LDAP directory for Fran's phone number. While you
might know her as Fran (having heard her spill her guts over
lunchtime margaritas on more than one occasion), the people
in HR may refer to her (somewhat more formally) as Frances.
Because both versions of her name are stored, either search
will successfully look up Fran's telephone number, email,
cube number, and so on.


Like most companies on the Internet, Foobar uses Sendmail

for internal mail delivery and routing. Foobar stores all
users' mail routing information in LDAP, which is fully
supported by recent versions of Sendmail.

userpassword: {crypt}3x1231v76T89N
uidnumber: 1234
gidnumber: 1200
gecos: Frances Smith
homedirectory: /home/fsmith
loginshell: /usr/local/bin/bash

Note that Foobar's systems administrators store all the NIS

password map information in LDAP as well. At Foobar, the
foobarPerson object class adds this capability. Note that
the user password is stored in UNIX crypt format. The UNIX
uid is stored here as uidnumber.

Thus, the Light weight Directory Access Protocol is