LDAP: Difference between revisions
m (using an external editor) |
m (using an external editor) |
||
Line 32: | Line 32: | ||
; Standardization | ; Standardization | ||
* Both ObjectClasses and Attributes must be defined in a schema, else | * 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 | * 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. | * 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:'' | |||
'''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. | |||
== Directory information - entries == | == Directory information - entries == | ||
Line 41: | Line 78: | ||
=== Object Classes === | === Object Classes === | ||
Standard 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 | |||
Person | 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) | |||
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 Name === | === Distinguished Name === | ||
Line 98: | Line 186: | ||
userClass Specifies a category of computer user | userClass Specifies a category of computer user | ||
userpassword | userpassword | ||
Example of my own person (some attributes taken away): | |||
<pre> | |||
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 | |||
</pre> | |||
== LDAP Search == | == LDAP Search == |
Revision as of 17:39, 22 November 2007
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:
- 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:
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.
Directory information - entries
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)
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 Name
Each entry must have a Distinguished Name (DN). It's composed of the entry's relative distinguised 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
LDAP Search
Search Filters
Note that search can be performed on any subtree of the directory tree. See for instance the LDAP URL examples below.
Syntax:
attribute OPERATOR value
Operators:
= 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
http://tecfa.unige.ch/tecfa-people/ldap.html
Documentation
Indexes for Documentation
- RFCs can be found in several places, e.g. at http://www.umich.edu/~dirsvcs/ldap/doc/, at Critical Angle, at X.500 and LDAP: Raw Bibliography of Relevant RFCs, ..
Specifications
Some RFC's (there are many more !)
- 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 (rfc2256)
Other Stuff
- The UniCode doc
FAQs
Programmer's Tutorials
- The JNDI Tutorial Building directory-enabled Java applications by by Rosanna Lee (at Sun)
Articles
- 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
- An Internet Approach To Directories (Netscape specific, but has general value)
- IBM's LDAP Redbook (PDF Format). EXCELLENT !
- LDAP: The next-generation directory? SunWorld Article. Good overview, includes pointers to on-line specs
Links
- 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
- Webopedia's LDAP Page
- Innosoft's LDAP World (no longer fully maintained ?)
- OpenLDAP
- 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
Clients
- 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).
- LDAP Browser/Editor Java-based GUI
- LDAP Web Exploter. (PHP) Under development, dead ?
- gq - The Gentleman's LDAP client Recent X Client (needs gtk installed). Works fine (but I did not figure out how to edit so far empty attributes)
- Under development: Plums (Java/Swing)
- Python cgi client (ldap-client-cgi.py)
LDAP Development Libraries
- PHP has an LDAP library included
Examples
LDAP URLs
See: LDAP URL Format (RFC-1959)
Filter Syntax (much simplified, see also RFC-1558):
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://tecfa2.unige.ch/o=tecfa.unige.ch??sub? ... most everything in our server
- ldap://tecfa2.unige.ch/o=tecfa.unige.ch??sub?(sn=*) .. all things that have sn (Surnames)
- ldap://tecfa2.unige.ch/o=tecfa.unige.ch??one?(sn=*) .. one of all things that have sn (Surnames)
- ldap://tecfa2.unige.ch/o=tecfa.unige.ch??one?(objectClass=person)... Persons only
- [ldap://tecfa2.unige.ch/o=tecfa.unige.ch??one?(&(objectClass=person)(sn=s*)) ldap://tecfa2.unige.ch/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://tecfa2.unige.ch/o=tecfa.unige.ch?mail?one?(objectClass=person) Prints entries (uid) mail
- [ldap://tecfa2.unige.ch/o=tecfa.unige.ch?mail?one?(&(objectClass=person)(sn=s*)) ldap://tecfa2.unige.ch/o=tecfa.unige.ch?mail?one?(&(objectClass=person)(sn=s*))] Print Email for all persons who's surname starts with "s"
Restrict search to organizational units (mhh something I don't like here)
- [ldap://tecfa2.unige.ch/o=tecfa.unige.ch?cn,labeledUri,mail?sub?(ou=staf) ldap://tecfa2.unige.ch/o=tecfa.unige.ch?cn,mail,labeledUri?sub?(ou=staf)]. Shows Common Name Emails labelled URLs of all the members of the "staf" Organizational Unit.
- [ldap://tecfa2.unige.ch/o=tecfa.unige.ch?cn,labeledUri,mail?sub?(&(studentCategory=staf)(studentpromotion=D)) ldap://tecfa2.unige.ch/o=tecfa.unige.ch?cn,labeledUri,mail?sub?(&(studentCategory=staf)(studentpromotion=D))] These are custom entries attached to the tecfaPerson Class
PHP
- [/guides/php/examples/ldap/ php-ldap example dir at Tecfa] See also the PHP Manual
- LDAP Web Exploter. Under development ?