LDAP

This article or chapter is incomplete and its contents need further attention. Some information may be missing or may be wrong, spelling and grammar may have to be improved, use your judgment!

## Contents

* 1 Definition
* 2 Architecture overview
* 3 The LDIF Format
* 4 Directory information - entries and schemas
* 4.1 Typical object classes
* 4.2 Definition of object classes
* 4.3 Distinguished Names
* 4.4 Some common Attribute types
* 4.5 Definition of attributes
* 5 Directory Standards
* 6 LDAP Search
* 6.1 Search Filters
* 7 LDAP URLs
* 8 Documentation
* 8.1 Indexes for Documentation
* 8.2 Specifications
* 8.3 Programmer's Tutorials
* 8.4 Documentation about schemas
* 8.5 Articles and tutorials
* 9 Links
* 10 Software
* 10.1 Indexes
* 10.2 Clients
* 10.3 Web clients
* 10.4 Servers
* 10.5 LDAP Development Libraries

## Definition[edit | edit source]

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

## Architecture overview[edit | edit source]

In LDAP world, a directory is defined as follows:

By its structure

* It is a tree of objects called entries (like a file system or the Windows registry). LDAP is kind of hierarchical database, called a data information tree (DIT).

By having entries

* Each entry is a collection of attributes.
* Entries are instances of ObjectClasses (at least one), i.e. definitions of required or optional attributes So attributes are members of object classes.
* Each entry has a unique identifier: its Distinguished Name (DN). It is constructed as a list of some attributes. DN's must be unambiguous, e.g. an organisation can choose as DN for its users the email address or a department name + Unix login.
* Within a subtree, elements relative distinguised name  (RDN) refer to attributes that are unique within this tree.

Entries having typed attributes

* Each attribute has a name (also called type) and can have one or several values.
* Values must be of a certain data type (e.g. a case-insensitive string, a phone number).

Here is a picture from IBM's LDAP Redbook defining entries and attributes:

LDAP Entries and attributes (IBM Redbook)

Standardization

* Both ObjectClasses and Attributes must be defined in a schema, else an LDAP server will not accept entries.
* LDAP Schemas are files with object classes and attribute definitions. Schemas can be built on top of other schemas.
* Usually, Object classes must contain certain attributes and can contain others
* For most kinds of directories, there exist a series of international standards (schemas) that define both object classes and attribute names and value types. On top of these you can your own schema files.

## The LDIF Format[edit | edit source]

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

## Directory information - entries and schemas[edit | edit source]

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.

### Typical object classes[edit | edit source]

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

Persons

objectclass: person
objectclass: organizationalPerson
objectclass: organizationalRole
objectclass: inetOrgPerson

Units

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

Related to some application

objectclass: nsCalAdmin
objectclass: groupOfUniqueNames (A list of user names (dn) plus owner, etc)
objectclass: nginfo  (Newsgroup)

### Definition of object classes[edit | edit source]

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:

* Each object has a unique number and a human readable name
* DESC: is a description
* SUP: defines the super-class the object inherits from
* MUST: Defines the list of mandatory attributes (separated by $)
* MAY: Defines the list of optional attributes.

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 ")"

### Distinguished Names[edit | edit source]

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

### Some common Attribute types[edit | edit source]

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

### Definition of attributes[edit | edit source]

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:

* It has a unique number
* Two alternative names (usually a short and long one)
* DESC: description referring to a standard
* EQUALITY: E.g. case unsensitive
* SUBSTR: same
* SYNTAX: A number or a name that refers to a data format.
* SUP: An attribute definition it may inherit from
* SINGLE-VALUE: If present, you can't enter more than once this attribute.

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 ")"

## Directory Standards[edit | edit source]

In the OPENLDAP server (2004) I found these:

* corba.schema: Corba Object (RFC 2714)
* core.schema: OpenLDAP "core":
* cosine.schema: COSINE Pilot, This is the biggest file and contains RFC 1274: X.500 Cosine and Internet schema. It is based on other RFC's: RFC 987, RFC 822, RFC 1279, ....
* inetorgperson.schema: InetOrgPerson
* java.schema: Java Object (RFC 2713)
* misc.schema: Miscellaneous Schema (experimental)
* nis.schema: Network Information Service
* openldap.schema: OpenLDAP Project (FYI)

Overview:

* RFC 4519 - Lightweight Directory Access Protocol (LDAP): Schema for User Applications, 2006 (supercedes RFC 2256).

## LDAP Search[edit | edit source]

LDAP servers must implement query functionalities.

### Search Filters[edit | edit source]

(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

## LDAP URLs[edit | edit source]

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

* ldap://someserver.org/o=tecfa.unige.ch??sub? ... most everything in our server
* ldap://someserver.org/o=tecfa.unige.ch??sub?(sn=*) .. all things that have sn (Surnames)
* ldap://someserver.org/o=tecfa.unige.ch??one?(sn=*) .. one of all things that have sn (Surnames)
* ldap://someserver.org/o=tecfa.unige.ch??one?(objectClass=person)... Persons only
* ldap://someserver.org/o=tecfa.unige.ch??one?(&(objectClass=person)(sn=s*))
* ldap://someserver.org/o=tecfa.unige.ch??one?(&(objectClass=person)(sn=s*))] (Almost) full entries for persons who's surname starts with "s"

Some queries printing MUCH less:

* ldap://someserver.org/o=tecfa.unige.ch?mail?one?(objectClass=person) Prints entries (uid) mail
* ldap://someserver.org/o=tecfa.unige.ch?mail?one?(&(objectClass=person)(sn=s*))
* ldap://someserver.org/o=tecfa.unige.ch?mail?one?(&(objectClass=person)(sn=s*))] Print Email for all persons who's surname starts with "s"

Restrictions

* ldap://someserver.org/o=tecfa.unige.ch?cn,labeledUri,mail?sub?(&(studentCategory=staf)(studentpromotion=D)) * ldap://someserver.org/o=tecfa.unige.ch?cn,labeledUri,mail?sub?(&(studentCategory=staf)(studentpromotion=D))]

## Documentation[edit | edit source]

### Indexes for Documentation[edit | edit source]

* RFCs can be found in several places, e.g. at http://www.umich.edu/~dirsvcs/ldap/doc/ or
* Jeff Hodge's LDAP Roadmap & FAQ

### Specifications[edit | edit source]

Some RFC's (there are many more, see the LDAP Wikipedia article.

* Lightweight Directory Access Protocol (RFC 1777)
* LDAP URL Format (RFC 1959)
* String Representation of LDAP Search Filters (RFC 1558)
* Summary of the X.500(96) User Schema for use with LDAPv3 (RFC 2256)

Other Stuff

* The UniCode doc

### Programmer's Tutorials[edit | edit source]

* The JNDI Tutorial  Building directory-enabled Java applications by by Rosanna Lee (at Sun)
* With PHP (missing)

### Documentation about schemas[edit | edit source]

e.g. X500

* Appendix E: LDAP - Object Classes and Attributes

### Articles and tutorials[edit | edit source]

(not complete !!)

* LDAP for Rocket Scientists. Best resource according to Daniel K. Schneider. Also includes a glossary
* IBM's LDAP Redbook (HTML/PDF Format). Also good.
* Introduction to Directories and the Lightweight Directory Access Protocol (Jeff Hodges@Stanford). Good set of introductory slides
* Why do I need a Directory when I could use a Relational Database? Powerpoint slides from a talk given at Stanford
* LDAP (Wikipedia)
* LDAP Data Interchange Format (Wikipedia)
* LDAP: Framework, Practices, and Trends
* Understanding LDAP (DevShed introductory article)

## Links[edit | edit source]

* LDAP Central. Good and large Index (has most major links)
* Netscape's Directory Developer Centeral. Good ressource (with a lot of Netscape centered information of course, but more ...)
* LDAP Quellen
* University of Michigan's Lightweight Directory Access Protocol
* LDAP at Yahoo
* Mark Wilcox's List o' Links on LDAP minimalistic presentation, but good stuff
* LDAP Resources  A short rated list from B. Foote"Directory" Entries at Dmoz

## Software[edit | edit source]

### Indexes[edit | edit source]

* List of LDAP software (Wikipedia)

### Clients[edit | edit source]

* Apache Directory (In 2007, the favorite one for Daniel K. Schneider). Java-based, cross-platform
* JXplorer (Java-based, not tested).
* LDAP Administration Tool (lat). Linux. Tested with Ubuntu 7.x. Works, but DKS preferes Apache Directory.
* LDAP Admin Windows. Freeware. (not tested)
* MaXware Directory Explorer 4.0 IE/Outlook plugin.(not tested)
* GQ \- GTK-based LDAP client. You will have to compile it...

Others:

* Netscape Communicator used to be LDAP aware. The LDAP URLs did work. Can't use LDAP URL's with Mozilla /Firefox anymore (nov. 2007).
* Most mail clients can access directory services (but not edit LDAP directories or make custom queries for other information than names, firstnames, emails and such).
* LDAP Browser/Editor Java-based GUI. Works but the URL is dead and you will now have to buy it...

### Web clients[edit | edit source]

* phpLdapAdmin. This is a PHP application which Daniel K. Schneider successfully installed and recommends if you want something like this. Note: Will not work if you run php in safe-mode, you just get a blank screen. There are loads of options to configure access and security. Needs about 1 hour at least to edit the configuration file (... plus more to figure out that safe mode was a problem. With safe-mode mode enabled it can't even write debug log files).

### Servers[edit | edit source]

* OpenLDAP. Distributed as package for most Linuxes. On Solaris available in the /opt/sfw directory.
* See OpenLDAP installation and configuration
* Sun, Novell and Microsoft (Active Directory) ship their own LDAP servers with their OSs

To play on windows, try one of these (not tested)

* http://www.ilex.fr/openldap.htm
* http://mguessan.free.fr/nt/openldap_en.html

### LDAP Development Libraries[edit | edit source]

* PHP has an LDAP library included
* You may find php classes in various places. The PHP library is not exactly end-programmer friendly.