Sie sind auf Seite 1von 8

Assignment No.

5
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.

X500

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
reasons.
LDAP

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
organized
• an emerging distributed operation model defining how
data may be distributed and referenced (v3)
• Both the protocol itself and the information model are
extensible

Data Types

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


URLs, Pointers to whatever, Binary data, Public Key
certificates.

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
resides.

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
ou=recipes
• 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:
uid=fsmith,ou=employees,dc=foobar,dc=com
(login-based)
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.

cn=FranSmith,ou=employees,dc=foobar,dc=com
(name-based)
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.
mailRoutingAddress: fsmith@foobar.com
mailhost: mail.foobar.com
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
searching.

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
company.

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.

mailRoutingAddress: fsmith@foobar.com
mailhost: mail.foobar.com

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.

Conclusion:
Thus, the Light weight Directory Access Protocol is
studied.