Lightweight Directory Access Protocol --- LDAP

LDAP is a global directory service.  This directory can be used to store all sorts of information.  The directory can be regarded as a database of sorts.  But unlike traditional databases, an LDAP database is especially suited for read, search and browse operations instead of write operations.  It is with reads that LDAP is predominantly popular.

Some well known LDAP implementations are:

• OpenLDAP
• Novell's NetWare Directory Service (eDirectory)
• Microsoft's Active Directory
• iPlanet Directory Server (currently developed by Red Hat)
• IBM's SecureWay Directory

Structure of LDAP Directory:
As in the well known Domain Name System DNS, the directory entries in LDAP are arranged in a hierarchical tree structure.  As in most hierarchical structures, the further you go down the tree, the more specific the content stored therein will be.  The hierarchical tree structure of LDAP is formally known as the Directory Information Tree DIT.  The top of the directory hierarchy has a root element.  The complete path to any node in the tree structure, which uniquely identifies it, is known as the Distinguished Name DN of the node or object.

Once again, like in DNS, the structure of an LDAP directory usually reflects geographic and/or organizational boundaries.  The geographic boundaries can be along country lines, state lines, city lines, or thereof.  Organizational boundaries can be along functional lines, departmental lines, or organizational units.

Client/Server model:
As with most network services, LDAP adheres to the usual client/server topology.  A typical interaction between the client and the server goes like this:
An LDAP client application connects to an LDAP server.  This is sometimes referred to as "binding to a server."
Based on the access restrictions configured on the server, the LDAP server either accepts or refuses the bind/connection request.  Assuming it accepts.......
The client has the choice of querying the directory server, browsing the information stored on the server, or attempting to modify/update the information on the LDAP server.
Again, based on access restrictions, the server can allow or deny any of the operations attempted by the client.  In the event that the server cannot answer a request, it may forward or refer the client to another upstream LDAP server that may have a more authoritative response to the request.


Where and how LDAP is used:
LDAP is a distributed directory service and can be used as storage for various types of information.  Just about any kind of information can be stored in an LDAP directory --- information as varied in nature as plain text information, images, binary data, or public key certificates.

Various LDAP schemas have been created to allow the storage of different data sources.  Examples:

• LDAP can serve as a complete identity management solution for an organization.  It can provide authentication and authorization services for users.  The services provided by NIS can be and has been completely replaced by the more secure LDAP.
• The information stored in DNS records can be stored in LDAP.
• LDAP can be used to provide "yellow pages" services for a company.  Like employee information --- office co-ordinates, phone number, department, reporting tree.
• Mail routing information can be stored in LDAP.

LDAP Terminologies:
Entry (or object) ------>  This is one unit in an LDAP directory.  Each entry is qualified by its distinguished name (DN).  In our example in the diagram,    "dn: uid = ksmith,ou=computer-science,dc=princeton,dc=edu".
Attributes           ------>   These are pieces of information associated with an entry.  For example, a university address or the phone numbers of employees.
objectClass         ------>   This is a special type of attribute.  All objects in LDAP must have an objectClass attribute.  The object Class definition specifies which attributes are required for each LDAP object.  It specifies the object classes of an entry.  The values of this attribute may be modified by clients but the objectClass attribute itself cannot be removed.  The objectClass definitions are themselves stored in schema files.
Schema               ------>   A schema is a collection of rules that determines the structure and contents of the directory.  The schema contains the attribute type definitions, object-class definitions, etc.
The schema lists the attributes of each object type and whether these attributes are required or optional.  Schemas are usually stored in plain-text files.
Examples of schema are:
a.         core.schema                     This schema defines the basic LDAP version 3 attributes and objects.  It is a required core schema in the OpenLDAP implementation.
b.        inetorgperson.schema     Defines the inetOrgPerson object class and its associated attributes.  This object is often used to store contact information of people.
LDIF                      ------>   Stands for LDAP Data Interchange Format.  It is a plain-text file for LDAP entries.  Files that import or export data to and from an LDAP server must be in this format.  The data used for replication among LDAP servers are also in this format.


OpenLDAP

OpenLDAP is an open source implementation of LDAP that runs on Linux.  It is a suite of programs made up of the following components: slapd, slurpd, and libraries, which implements the LDAP protocol, along with various client- and server-side utilities.

Server-side daemons:

slapd    ->    This is  a stand-alone LDAP daemon.  It listens for LDAP connections from clients and responds to the LDAP operations it receives over those connections.

slurpd  ->    This is a stand-alone LDAP replication daemon.  It is used to propagate changes from one slapd database to another.  It is the daemon used for synchronizing changes from one LDAP server to another.  It is only needed when more than one LDAP server is in use.