From EduTechWiki - Reading time: 10 min
The Lightweight Directory Access Protocol (LDAP) is a client-server protocol for querying and modifying a directory service. It represents a kind of hierarchical database and as such one can use it for any kind of data, not just directory services. Often, institutions adopt an LDAP server to authenticate users for various internet applications (e.g. an LMS), to manage access to central systems and to manage the email and phone directory. So it's a kind of all-in-one solution to deal with users and their attributes (e-mail, address, user identification, office numbers, hobbies,....)
See also OpenLDAP installation and configuration if you are looking for more operation installation, design and configuration hints regarding a simple LDAP sever used to manage information about TECFA's members, students, etc.
See also: digital identity for some global discussion about systems that manage/identify users.
LDAP has become the de facto access method for directory information, much the same as the Domain Name System (DNS) is used for IP address look-up. Often LDAP is also used to authenticate users, i.e. instead of authenticating users with password files or custom databases (in the case of portails), one may ask an LDAP server to match a username with a password. LDAP is a vendor-independent, open, network protocol standard and thus is as platform-independent as you can get. LDAP is supported by a lot of vendors (Netscape, Sun, Microsoft, Novell, IBM, ...)
Setting up a good LDAP server is a very difficult task and probably needs about two weeks of reading and testing (or more !). Setting up a simple one, e.g. to manage a Phone,Mail,address and URL directory for students can be done much faster. Most Unix-based systems do include for example a copy of the OpenLDAP server. This article is not complete, but can give you an idea of what LDAP is about. See readings and links for more ...
In LDAP world, a directory is defined as follows:
Here is a picture from IBM's LDAP Redbook defining entries and attributes:

LDIF is the text format that can be used to export/import information from/into a directory server. The LDAP directory server itself uses some kind of binary format.
As you can see, each entry has at least a dn: and an objectclass:. Various LDAP entries are simply defined by a blank line (?) and the start of a new dn:
Examples from TECFA's very small LDAP server:
An organization:
dn: o=tecfa.unige.ch objectclass: top objectclass: organization o: tecfa.unige.ch
An organizational Unit:
dn: ou=tecfa,o=tecfa.unige.ch objectclass: top objectclass: organizationalUnit ou: tecfa description: TECFA
A person:
dn: uid=roiron,o=tecfa.unige.ch userpassword: .... objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: nsCalUser givenname: Cyril sn: Roiron cn: Cyril Roiron uid: roiron title: Assistant ......
Note: Since this server is just for internal use, there was no need to make the base dn more complicated than the one of our main webserver's domain name.
LDIF can be used to define entries, but also to modify entries. Here is an example:
dn: uid=jermann,o=tecfa.unige.ch changetype: modify add: studentCategory studentCategory: studentCategory staf - add: studentPromotion studentPromotion: A -
Not exactly text editor friendly...
The Directory Information Tree (DIT) is the hierarchy of objects that make up the local directory structure. More than one DIT may be supported by an LDAP server.
Standard Object Classes that you may find in a typical LDAP server. The difference between an attribute and an object is that objects have several attributes, attributes only can have values. Objects can (and usually do) inherit from other objects.
objectclass: top
objectclass: person objectclass: organizationalPerson objectclass: organizationalRole objectclass: inetOrgPerson
objectclass: country objectclass: locality objectclass: organization objectclass: organizationalUnit objectclass: domain
Then, you may find any number of other things like organizational roles, rooms, computers, documents, accounts, whatever ....
objectclass: nsCalAdmin objectclass: groupOfUniqueNames (A list of user names (dn) plus owner, etc) objectclass: nginfo (Newsgroup)
These definitions must be loaded as configuration files into the LDAP server. It's like the equivalent of SQL database, table and field definitions. So it's not content, but a schema. Most organizations simply adopt schemas that are defined as standards. This way you can be sure to be able to exchange data or to interface with special clients (like email programs).
The Schema definition language is ASN.1, Abstract Syntax Notation-1 (X.691).
Example of an Object class definition hierarchy:
objectclass ( 2.5.6.6 NAME 'person'
DESC 'RFC2256: a person'
SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
objectclass ( 2.5.6.7 NAME 'organizationalPerson'
DESC 'RFC2256: an organizational person'
SUP person STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )
objectclass ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson'
DESC 'RFC2798: Internet Organizational Person'
SUP organizationalPerson STRUCTURAL
MAY (
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
)
Here is the formal definition of object class (RFC 2252):
ObjectClassDescription = "(" whsp
numericoid whsp ; ObjectClass identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ] ; Superior ObjectClasses
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
; default structural
[ "MUST" oids ] ; AttributeTypes
[ "MAY" oids ] ; AttributeTypes
whsp ")"
Each entry must have a Distinguished Name (DN). It's composed of the entry's relative distinguished name and all of the ancestors of the entry up to the root of the DIT (Directory Information Tree).
Example:
dn: uid=roiron,o=tecfa.unige.ch
From X500 (I believe), e.g. see Summary of the X.500(96) User Schema for use with LDAPv3 (rfc2256). Each attribute value must respect some defined syntax.
cn CommonName (in principle: givenname SN) co Country (or sometimes c?) dc DomainComponent description Describes the Entry dn DistinguishedName (Owner) drink favorite drink of a Person employeeType fax facsimileTelephoneNumber givenname First Name homePhone homePostalAddress (each line must be separated with a $) keywords keywords for the entry. l Locality Name labeledURI URL that is relevant in some way to the entry mail Email mailAlternateAddress manager dn of the entry's manager member dn for each member of the group memberURL URL associated with each member of a group mobile entry's mobile or cellular phone number o Organization Name organizationalStatus person's role in an organization ou Organizational Unit Name personalTitle like Mr. postalAddress (each line must be separated with a $) roomNumber room number of an object sa Street Address secretary secretary or administrative assistant seeAlso related information sn SurName st State or Province Name street entry's house number and street name telephonenumber title Job Title userClass Specifies a category of computer user userpassword
Example of my own person (some attributes taken away):
dn: uid=schneide,o=tecfa.unige.ch
userPassword:: e1NIQxxxxxxxxxxxxxxxxxDRSSHoxczg9
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: tdsTe{{under construction}}
cfaPerson
givenname: Daniel
sn: Schneider
cn: Daniel Schneider
uid: schneide
mail: Daniel.Schneider@tecfa.unige.ch
telephonenumber: +41 (22) 379 93 77
title: MER
description: Maitre d'enseignement et de recherche
......
homepostaladdress: Forget it
l: Geneve
tdsTecfaHomePage: http://tecfa.unige.ch/tecfa-people/schneider.html [Home Page at Tecfa]
personaltitle: Dr.
postalcode: CH-1227
street: 54 route des Acacias
Like object classes, each attribute also must be defined. When you define your own object classes and attributes, you should use standard datatypes.
Examples:
This is the definition of the street attibute:
attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' )
DESC 'RFC2256: street address of this object'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' )
DESC 'RFC2256: organization this object belongs to'
SUP name )
attributetype ( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
attributetype ( 2.16.840.1.113730.3.1.3
NAME 'employeeNumber'
DESC 'RFC2798: numerically identifies an employee within an organization'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
Here is the formal definition of attribute from RFC 2252
AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other
; AttributeType
[ "EQUALITY" woid ; Matching Rule name
[ "ORDERING" woid ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; Syntax OID
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ]; default user modifiable
[ "USAGE" whsp AttributeUsage ]; default userApplications
whsp ")"
In the OPENLDAP server (2004) I found these:
Overview:
LDAP servers must implement query functionalities.
(this section needs to be expanded)
Search can be performed on any subtree of the directory tree. See for instance the LDAP URL examples below.
Filter Syntax: RFC 1558
Simplified syntax:
attribute OPERATOR value
Operators you can use (there may be others).
= equal >= bigger than (including alphabetic) <= =* all entries that have this attribute ~= aprroximate match
& and, entries match ALL criteria | or, one of entries must match ! not
Examples:
(| (sn=roiron) (& (ou=tecfa) (sn=muller)) ) .. returns all roiron and all muller that are members of tecfa
Examples in french - curtesy Dajana :)
| Approximation | (sn~=Mirtain) | nom dont l'orthographe est voisine de Mirtain |
| Equality | (sn=Mirtain) | vaut exactement Mirtain |
| Comparison | (sn>Mirtain) , <= , >= , < | noms situés alphabétiquement après Mirtain |
| Presence | (sn=*) | toutes les entrées ayant un attribut sn |
| Sub-chain | (sn=Mir*), (sn=*irtai*), (sn=Mirt*i*) | expressions régulières sur les chaînes |
| AND | (&(sn=Mirtain) (ou=Semir)) | toutes les entrées dont le nom est Mirtain et du service Semir |
| OR | (¦(ou=Direction) (ou=Semir)) | toutes les entrées dont le service est le Semir ou la Direction |
| Negation | (!(tel=*)) | toutes les entrées sans attribut téléphone |
See: RFC 1959
ldap://SERVER/BASE_DN/?ATTRIBUTES?ITEMS?FILTER SERVER = ldap server URL BASE_DN = The Base DN ATTRIBUTES = What attributes to return for found entries ITEMS = How many (of the same) attributes to return FILTER = Entries must have these attribute value pairs
Some LDAP queries printing WHOLE entries
Some queries printing MUCH less:
Restrictions
Some RFC's (there are many more, see the LDAP Wikipedia article.
Other Stuff
e.g. X500
(not complete !!)
Others: