LDAP

The educational technology and digital learning wiki
Jump to navigation Jump to search

This article or section is currently under construction

In principle, someone is working on it and there should be a better version in a not so distant future.
If you want to modify this page, please discuss it with the person working on it (see the "history")

Definition

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.

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), on 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, ...)

Architecture overview

In LDAP world, a directory is defined as follows:

By its structure
  • It is a tree of entries (like a file system or the Windows registry)
By having entries
  • Each entry is a collection of attributes
  • 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.
  • Entries can be typed with ObjectClasses, i.e. a schema that allows to define which attributes are required and which are optional.
Entries having typed attributes
  • Each attribute has a name, called type and can have several values.
  • Each value must be of a certain 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.
  • Object classes must contain certain attributes and can contain others
  • For most kinds of directories, there exist a series of international standards that define both object classes and attribute names and value types.

The LDIF Format

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

Typical object classes

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

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

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


Distinguished Names

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

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        entry's 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: tdsTecfaPerson
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

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 )


Directory Standards

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)

LDAP Search

LDAP servers must implement query functionalities.

Search Filters

Note that 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

Example: 

(| (sn=roiron) (&ou=tecfa) (sn=muller))
.. returns all roiron   all muller that are members of tecfa


LDAP URLs

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

Indexes for Documentation

Specifications

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

Other Stuff

Programmer's Tutorials

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

Articles and tutorials

(not complete !!)

Links

Software

Clients


Others:

  • Netscape Communicator used to be LDAP aware. The LDAP URLs work and its mail client can access LDAP servers.
  • 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).

Servers

  • OpenLDAP
  • Sun, Novell and Microsoft ship their own LDAP-like servers with their OSs

LDAP Development Libraries

  • PHP has an LDAP library included
  • You may find php classes in various places. The PHP library is not exactly end-programmer friendly.
Retrieved from "https://edutechwiki.unige.ch/mediawiki/index.php?title=LDAP&oldid=16380"