LDAP

Un annuaire électronique est une base de donnée spécialisée, dont la fonction première est de retourner un ou plusieurs attributs d'un objet grâce à des fonctions de recherche multi-critères. Contrairement à un SGBD, un annuaire est très performant en lecture mais l'est beaucoup moins en écriture. Sa fonction peut être de servir d'entrepôt pour centraliser des informations et les rendre disponibles, via le réseau à des applications, des systèmes d'exploitation ou des utilisateurs. Lightweight Directory Access Protocol (LDAP) est né de la nécessaire adaptation du protocole DAP (protocole d'accès au service d'annuaire X500 de l'OSI) à l'environnement TCP/IP. Initialement frontal d'accès à des annuaires X500, LDAP  est devenu en 1995, un annuaire natif (standalone LDAP) sous l'impulsion d'une équipe de l'Université du Michigan (logiciel U-M LDAP).

Sommaire

---

Les concepts de LDAP

• le protocole permettant d'accéder à l'information contenue dans l'annuaire,
• un modèle d'information définissant le type de données contenues dans l'annuaire,
• un modèle de nommage définissant comment l'information est organisée et référencée,
• un modèle fonctionnel qui définit comment on accède à l'information ,
• un modèle de sécurité qui définit comment données et accès sont protégés,
• un modèle de duplication qui définit comment la base est répartie entre serveurs,
• des APIs pour développer des applications clientes,
• LDIF, un format d'échange de données.

Le protocole LDAP

La plupart des logiciels serveurs LDAP proposent également un protocole de communication serveur-serveur permettant à plusieurs serveurs d'échanger leur contenu et de le synchroniser (replication service) ou de créer entre eux des liens permettant ainsi de relier des annuaires les uns aux autres (referral service).

La communication client-serveur est normalisée par l'IETF dans la version actuelle, la 3, du protocole LDAP (RFC2251). Concernant la communication serveur-serveur, le referral service est définit par LDAPv3, par contre le replication service est encore en cours de normalisation sous la dénomination LDAP Duplication Protocol (LDUP) dont la parution est prévu pour décembre 99.

Contrairement à d'autres protocoles d'Internet, comme HTTP, SMTP ou NNTP, le dialogue LDAP ne se fait pas en ASCII mais utilise le format de codage Basic Encoding Rule (BER).

Le modèle de données LDAP

Le Directory Information Tree

Les entrées correspondent à des objets abstraits ou issus du monde réel, comme une personne, une imprimante, ou des paramètres de configuration. Elles contiennent un certain nombre de champs appelés attributs dans lesquelles sont stockées des valeurs. Chaque serveur possède une entrée spéciale, appelée root directory specific entry (rootDSE) qui contient la description de l'arbre et de son contenu.

figure 1. exemple de DIT

Le schéma

Les attributs

• Un nom qui l'identifie
• Un Object Identifier (OID) qui l'identifie également
• S'il est mono ou multi-valué
• Une syntaxe et des règles de comparaison
• Un indicateur d'usage
• Un format ou une limite de taille de valeur qui lui est associée

La syntaxe indique le type de données associées à l'attribut et la manière dont l'annuaire doit comparer les valeurs lors d'une recherche (tableau 2).

Certains serveurs LDAP respectent les standards X500 de hiérarchisation des attributs, qui permettent de décrire un attribut comme étant un sous-type d'un attribut super-type et d'hériter ainsi de ses caractéristiques. Par exemple, les attributs cn, sn, givenname sont des sous-types de l'attribut super-type name. Ces attributs super-types peuvent être utilisés comme critère de recherche générique qui porte sur tous ses sous attributs.

Les classes d'objets

• Un nom qui l'identifie
• Un OID qui l'identifie également
• Des attributs obligatoires
• Des attributs optionnels
• Un type (structurel, auxiliaire ou abstrait)

• Une classe structurelle correspond à la description d'objets basiques de l'annuaire : les personnes, les groupes, les unités organisationnelles... Une entrée appartient toujours au moins à une classe d'objet structurelle.
• Une classe auxiliaire désigne des objets qui permettent de rajouter des informations complémentaires à des objets structurels. Par exemple l'objet mailRecipient rajoute les attributs concernant la messagerie électronique d'une personne. L'objet labeledURIObject fait de même concernant les infos Web.
• Une classe abstraite désigne des objets basiques de LDAP comme les objets top ou alias.

    objectClass: top
    objectClass: person 
    objectClass: organizationalPerson 
    objectClass: inetOrgPerson

Une entrée peut appartenir à un nombre non limité de classes d'objets. Les attributs obligatoires sont dans ce cas la réunion des attributs obligatoires de chaque classe.

Les OIDs

Un OID est une séquence de nombres entiers séparés par des points. Les OID sont alloués de manière hiérarchique de telle manière que seule l'autorité qui a délégation sur la hiérachie "1.2.3" peut définir la signification de l'objet "1.2.3.4". Par exemple :

  2.5           - fait référence au service X500
  2.5.4         - est la définition des types d'attributs
  2.5.6         - est la définition des classes d'objets
  1.3.6.1               - the Internet OID
  1.3.6.1.4.1   - IANA-assigned company OIDs, used for private MIBs
  1.3.6.1.4.1.4203      - OpenLDAP

La définition du schéma

• slapd.conf : fichier de configuration utilisé par U-M slapd, OpenLDAP et Netscape Directory
• ASN.1 :  utilisé dans les documents décrivant les standards LDAP et X500
• LDAPv3 : La version 3 du protocole LDAP introduit l'obligation pour un serveur de publier son schéma via LDAP, pour permettre aux applications clientes d'en connaître le contenu. Le schéma est localisé par l'attribut opérationnel subschemaSubentry de l'entrée rootDSE. La valeur de cet attribut est une liste de DNs qui pointent vers des entrées, dont la classe d'objet est subschema, dans lesquelles sont stockées les descriptions des objets et des attributs.

Quand une entrée est créée, le serveur vérifie si sa syntaxe est conforme à sa classe ou ses classes d'appartenance : c'est le processus de Schema Checking.

Il existe deux objets abstraits particuliers : les aliases et les referrals qui permettent à une entrée de l'annuaire de pointer vers une autre entrée du même ou d'un autre annuaire. L'attribut aliasObjectName de l'objet alias a pour valeur le DN de l'entrée pointée. L'attribut ref de l'objet referral a pour valeur l'URL LDAP de l'entrée désignée.

Le Distinguish Name

    uid=mirtain,ou=people,dc=inria,dc=fr

    ou=people 
    ou=groups 
    cn=Semir,ou=groups 
    uid=mirtain, ou=people

LDIF

LDIF est utilisé dans deux optiques :

• faire des imports/exports de base
• faire des modifications sur des entrées.

La forme générale est :

    dn: <distinguished name 
    objectClass: <object class 
    objectClass: <object class 
    ... 
    <attribute type:<attribute value 
    <attribute type:<attribute value 
    ...

    dn: cn= June Rossi, ou= accounting, o= Ace Industry, c= US
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    cn: June Rossi
    sn: Rossi
    givenName: June
    mail: rossi@aceindustry.com
    userPassword: {sha}KDIE3AL9DK
    uid: rossi
    telephoneNumber: 2616
    roomNumber: 220

    dn: distinguished name
    changetype <identifier
    change operation identifier
    list of attributes...
    ...
    -
    change operation identifier
    list of attributes
    ...
    <identifier : 
           add (ajout d'une entrée), 
        delete (suppression), 
        modrdn (modification du RDN), 
        modify (modification : add, replace, delete d'un attribut)

Par exemple :

    Ajouter le numéro de téléphone et le nom du manager pour la personne Lisa Jangles :

     dn: cn= Lisa Jangles, ou= Sales, o= Ace Industry, c= US 
     changetype: modify 
     add: telephonenumber
     telephonenumber: (408) 555- 2468
     -
     add: manager
     manager: cn= Harry Cruise, ou= Manufacturing, o= Ace Industry, c= US

    dn: cn= Lisa Jangles, ou= Sales, o= Ace Industry, c= US 
    changetype: delete

Par exemple, on peut avoir pour un objet personne, un attribut description en français et un autre en japonais :

    description, lang-fr : le texte en français
    description, lang-ja : le même en japonais

Le modèle fonctionnel

Les commandes search et compare se font sous la forme d'une requête composée de 8 paramètres (tableau 5) :
 

Le scope définit la profondeur de la recherche dans le DIT. La figure 2 met en relief la portée d'une recherche ou d'une comparaison en fonction du paramètre scope :

figure 2. le scope

search scope = base	search scope = onelevel search	searchscope = subtree

Il n'existe pas de fonction read dans LDAP. Cette fonction est simulée par la fonction search avec un search scope égal à base.

Le filtre de recherche s'exprime suivant une syntaxe spécifique dont la forme générale est :

    (< operator(< search operation)(< search operation)...))

Lors de la connexion au serveur (bind), ce dernier demande une authentification. Le client doit alors fournir un DN et le mot de passe correspondant, celui-ci transitant en clair. Pour sécuriser les transactions,. LDAPv3 fournit la possibilité d'utiliser du chiffrement (SSL ou TLS) et le mécanisme Simple Authentification and Security Layer (SASL) procurant des outils d'authentification plus élaborés à base de clés ( OTP...). Une fois connecté, le client peut envoyer autant de commandes qu'il souhaite jusqu'à ce qu'il ferme la session (unbind).

Chaque commande se voit attribuer un numéro de séquence, qui permet au client de reconnaître les réponses lorsque celles-ci sont multiples - ce qui peut parfois arriver lors d'une recherche simple qui peut renvoyer jusqu'à plusieurs milliers d'entrées. A chaque opération, le serveur renvoie également un acquittement pour indiquer que sa tâche est terminée ou qu'il y a une erreur.

Les URLs LDAP

    ldap[s]://<hostname>:<port>/<base_dn>?<attributes>?<scope>?<filter>
      <base_dn>   : DN de l'entrée qui est le point de départ de la recherche
      <attributes>: les attributs que l'on veut consulter
      <scope>     : la profondeur de recherche dans le DIT à partir du
                    <base_dn> :"base" | "one" | "sub"
      <filter>    : filtre de recherche, par défaut (objectClass=*)

    ldap://ldap.netscape.com/ou=Sales,o=Netscape,c=US?cn,tel,mail?scope=sub?(objetclass=person)
    ldap://ldap.loria.fr/cn=Laurent%20Mirtain,ou=Moyens%20Informatiques,o=loria.fr
    ldap://ldap.loria.fr/o=loria.fr?mail,uid,sub?(sn=Mirtain)

Exemples d'application de LDAP

• Un protocole de diffusion de données : annuaire LDAP de type pages blanches pour contacter les personnes.
• Un protocole de service pour des applications : annuaire LDAP des adresses mail qui permet aux outils ou serveurs de mail de composer ou vérifier les adresses, utilisé par des gestionnaires de liste (sympa), base permettant de stocker les préférences de configuration d'une application (profiles communicator).
• Une passerelle entre applications : permettant l'échange de données entre applications incompatibles, par exemples les carnets d'adresses Netscape Communicator et Microsoft Outlook.
• Un protocole de service pour les systèmes d'exploitation ou les services Internet : base LDAP des utilisateurs utilisée par les systèmes pour assurer l'authentification (certificats d'authentification) et gérer les droits d'accès aux ressources réseau - Des projets sont en cours pour remplacer NIS, NIS+ par LDAP.

LDAP est disponible sur de nombreux types de plates-formes, ce qui lui confère un statut de service fédérateur, pouvant centraliser des informations issues de différentes sources - et en simplifier ainsi la gestion - et destinées à différentes applications et différents utilisateurs.

De ce fait, LDAP peut devenir la clef du système d'information de l'entreprise. Cela en rend la conception et la maintenance d'autant plus cruciales. C'est pourquoi la mise en place d'un tel service, à une telle échelle, relève d'une mission longue et délicate pouvant impliquer de nombreux intervenants et sources d'informations et pouvant parfois remettre en cause certains fonctionnements existants.

---

Déployer un service LDAP

Déterminer les besoins en service d'annuaire et ses applications

Déterminer quelles données sont nécessaires

Choisir son schéma

La plupart du temps, les schémas standards, issus de X500 et de LDAP conviennent aux besoins de modélisation. De plus, en fonction du logiciel que l'on choisira, des objets supplémentaires seront fournis. Il reste, au final, la possibilité de créer ses propres objets, spécifiques à ses besoins. En règle générale, il faut éviter de modifier le schéma existant car l'on risque de rendre son annuaire inutilisable par les applications clients ou les autres serveurs.
Il est préférable de créer une sous classe d'une classe d'objet existante et exploiter le mécanisme d'héritage d'attributs des classes objets. Par exemple on peut vouloir créer la classe d'objet inriaPerson fille de inetOrgPerson dans laquelle on définira les attributs nécessaires à ses besoins :

    objectclass inriaPerson
    superior inetOrgPerson
    requires
         sn,
         cn
    allows
         uidNumber,
         gidNumber,
         homeDirectory,
         loginShell,
         dateArrive,
         dateDepart

Concevoir son espace (modèle) de nommage

 Les paramètres qu'il faut prendre en compte lors de cette étude sont les suivants :

• Le nombre d'entrées prévu et son évolution ?
• La nature (type d'objet) des entrées actuelles et futures ?
• Vaut-il mieux centraliser les données ou les distribuer ?
• Seront-elles administrées de manière centrale ou faudra-t-il déléguer une partie de la gestion ?
• La duplication est-elle prévue ?
• Quelles applications utiliseront l'annuaire et imposent-elles des contraintes particulières ?
• Quel attribut utiliser pour nommer les entrées et comment garantir son unicité ?

Le Directory Tree

figure 3. espace de  nommage X500	figure 4. espace de  nommage plat
figure 5. espace de  nommage basé sur l'organisation	figure 6. espace de  nommage basé sur les objets
figure 7. espace de  nommage en vue de dupliquer

En règle générale, en terme de performance, il vaut mieux avoir un arbre le plus plat possible. Par contre, en terme de facilité d'administration, il vaut mieux introduire du branchage par type d'objet ou par organisation. Cela facilite les mises à jour de données ou la mise en place de règles d'accès spécifiques à une partie de l'annuaire ou la répartition de la gestion de l'arbre entre plusieurs serveurs. Si votre organisation change souvent ou bien que le personnel est très mobile, le branchage par organisation est alors à proscrire.

Nommage des entrées

Choix du suffixe

Dans la norme X500 le top level est le pays et vient ensuite le nom de l'organisation, ce qui donne par exemple comme suffixe :

    o=INRIA, c=FR

• utilisation de l'attribut organization (o) :  o=inria.fr
• utilisation de  l'attribut Domain Component (dc) défini par le RFC 2377  : dc=inria, dc=fr

    _ldap._tcp.inria.fr.  IN   SRV   0 0 389 ldap.inria.fr

Définir la topologie de son service

• Les applications qui vont utiliser l'annuaire et le nombre d'utilisateurs.
• Les capacités du logiciel serveur qui va être choisi.
• La topologie de son réseau.
• Le design de son espace de nommage.

La question principale de cette phase est de déterminer si la base et sa gestion seront centralisées sur un seul serveur ou si elles devront être éclatées sur plusieurs serveurs. La deuxième étude porte sur le nombre de serveurs redondants à déployer et leur emplacement sur le réseau physique.

Le partitonnement

Le service referral

Ces liaisons permettent à un serveur de faire suivre les requêtes des utilisateurs lorsque l'objet recherché n'appartient pas à l'arbre qu'il gère. La résolution de nom est le mécanisme par lequel un serveur détermine quel objet de sa base est désigné par le DN qu'un client lui fournit. Si le DN est bien dans son contexte de nommage, il exécute la requête du client (search, modify, bind...), sinon il renvoie un signal " object not found ". Si l'objet n'est pas dans son espace de nommage, le serveur utilise alors ses liens knowledge reference soit pour faire suivre la requête vers le serveur qui peut fournir l'objet, soit pour indiquer au client lequel contacter.

La figure 8 montre le cas de figure de deux serveurs gérant chacun deux suffixes, dont un des deux est un lien vers l'autre serveur.

figure 8. referral

1. Le Referral est une information que retourne au client le serveur LDAP, lorsque l'entrée recherchée n'appartient pas à son arborescence, lui indiquant vers quel serveur il doit reformuler sa requête. Il utilise pour cela les URLs LDAP. Le mécanisme de referral est standardisé dans le protocole LDAPv3.
2. Le chaînage (chaining) est un mécanisme où c'est le serveur qui se charge de contacter un autre serveur pour le compte du client et lui retourne la réponse. Le chaînage n'est pas un standard du protocole LDAP, il est plutôt utilisé dans les logiciels X500.

Concernant les referral, les serveurs ne les positionnent pas tous au même endroit. Netscape Directory utilise deux types de referral : le default referral et le smart referral. Le premier est indiqué au niveau de la racine du serveur et agit comme une redirection par défaut pour toute requête hors espace de nommage. Le second est placé dans une entrée quelconque et agit comme un lien symbolique vers une autre entrée d'un autre serveur.  Les deux utilisent les URLs LDAP pour rediriger la requête.

Le default referral est positionné dans le fichier slapd.conf de Netscape Directory ou OpenLDAP sous la forme d'une ligne :

    referral ldap://ldap.airius.com:389/o=airius.com

    dn:  l=Rocquencourt, dc=inria, dc=fr
    objectclass: top
    objectclass: organization
    objectclass: referral
    o: Rocquencourt
    description: INRIA Rocquencourt
    l: Rocquencourt
    ref: ldap://rocquencourt.inria.fr:389/l=rocquencourt,dc=inria,dc=fr

La duplication (replication)

Un exemple de duplication est représenté dans la figure 9. Les traits rouge représentent des liens de duplication. La société Airius possède une antenne à New York et l'autre à Los Angeles. Chaque antenne gère sa propre branche de l'annuaire, qu'elle duplique vers l'autre site, et duplique la totalité de l'arbre sur un deuxième serveur. Cette exemple illustre la mise en oeuvre du partitionnement dans le but de déléguer la gestion d'une partie de l'arbre et de la duplication dans l'optique de rapprocher les données des utilisateurs et d'assurer une redondance du service.

figure 9. service multi-site

Mettre en service la duplication

• une panne de l'un des serveurs,
• une coupure du réseau ,
• surcharge du service.

figure 10. duplication

On pourra choisir de dupliquer l'arbre entier ou seulement un sous arbre ou même, comme il est prévu dans le standard X500, une partie des entrées et de leurs attributs qu'on aura spécifiés via un filtre du genre :
      " on ne duplique que les objets de type personne "
      " on ne duplique que les attributs non confidentiels " (annuaire interne vs annuaire externe)

Il existe plusieurs manières de synchroniser les serveurs - mise à jour totale ou incrémentale - et plusieurs stratégies de duplications - single-master replication (un serveur maître en lecture-écriture les serveurs replica étant read-only) ou multiple-master replication (plusieurs maîtres qui se synchronisent mutuellement). Une autre méthode consiste à cascader la duplication, une partie des serveurs consumer devant supplier pour d'autres consumers.
En général la duplication se fait en temps-réel, ce qui peut être pénalisant dans le cas de gros transferts de données, on peut alors fixer le délai de synchronisation, certains serveurs permettant de lancer celle-ci à heure fixe (scheduling replication).

Deux précautions :

• les serveurs doivent tous utiliser le même schéma de données,
• les règles d'accès aux données dupliquées doivent également être dupliquées. En général,  les serveurs stockent les ACLs en tant qu'attributs de l'objet. Cependant certaines ACLs sont définies à la racine et s'appliquent à tout l'arbre ; certains logiciels ne les dupliquent pas et il faut les recopier "à la main".

Sécuriser le service

• Les accès non autorisés.
• Les attaques de type denial-of-service.
• Les droits d'accès aux données.

Les mécanismes qui peuvent être mis en oeuvre sont ceux que l'on retrouve dans nombre de services/serveur de l'Internet :

• L'authentification
• Les signatures électroniques
• La cryptographie
• Le filtrage réseau
• Les règles d'accès (ACLs) aux données
• L'audit des journaux

Authentification

• anonymous authentification - correspond à un accès au serveur sans authentification, qui permet uniquement de consulter les données accessible en lecture pour tous.
• Root DN Authentication - c'est l'utilisateur privilégié. Il a accès en modification à toutes les données.
• mot de passe en clair - c'est la méthode classique où le mot de passe transite en clair sur le réseau. Convient au cas d'un réseau commuté ou derrière un Firewall et de données non sensibles.
• mot de passe + SSL ou TLS - la session entre le serveur et le client est chiffrée et le mot de passe ne transite plus en clair.
• certificats + SSL -
• Simple Authentification and Security Layer (SASL) - permet de faire appel des mécanismes d'authentification plus élaborés à base de clés (OTP, Kerberos...)

Contrôle d'accès

        <target> <permission> <bind rule>
 
        <target> : point d'entrée de l'annuaire auquel s'applique la règle
        <permission> : permet ou refuse un type d'accès (lecture, écriture...)
        <bind rule> : identifie le bindDN utilisé en connexion

<permissions>
        Read    permet de lire les données
        Write   changer ou créer. Permet également de détruire dew
                données, mais pas l'entrée qui les contient (permission Delete)
        Search  les données peuvent être une clef de recherche. La différence avec
                le droit Read est que celui-ci permet de lire les données issues
                d'une recherche.
                Ex : droit search sur le common name et read sur le room number
                autorise l'affichage du room number pour les résultats de la sélection
                sur le common name, mais ne permet pas de rechercher les résidents
                du bureau.
        Compare utilisable pour des critères de comparaison. Implique le droit search mais
                renvoie en retour un simple booléen.
        Selfwrite uniquement pour la gestion des groupes. Permet soi-même de s'ajouter ou se
                supprimer d'un groupe.
        Add     permet de créer des entrées filles (en dessous de la branche de l'entrée
                considérée).
        Delete  droit d'effacer une entrée.

Il n'y a pas encore de standard LDAP concernant les règles d'accès mais en géréral les logiciels proposent des fonctionnalités d'ACLs. Netscape Directory utilise par exemple un attribut aci pour stocker les ACLs. En LDIF, la syntaxe est la suivante :

Exemple d'ACL pour la connexion de type anonymous

    aci: (target="ldap:///o=sophia.inria.fr")
         (targetattr != "userPassword")
         (version 3.0; acl "Anonymous access"; 
          allow (read, search, compare) userdn = "ldap:///anyone";)

    aci: (target="ldap:///o=sophia.inria.fr") 
         (targetattr = "telephoneNumber||roomNumber||labeledURI")
         (version 3.0; acl "Allow self entry modification"; 
          allow (write) userdn = "ldap:///self";)

Protections réseau

---

Les logiciels LDAP

Les logiciels serveurs

• OpenLDAP server,
• Innosoft's Distributed Directory Server,
• Netscape Directory Server,
• Sun Microsystems's Directory Services,
• IBM's DSSeries LDAP Directory,
• University of Michigan's SLAPD.

• Novell's NetWare Directory Services (NDS) 3.0,
• Microsoft's Active Directory (AD),
• Lotus Domino.

Les logiciels clients

Les logiciels offrant un accès natif :

• Navigateur Web utilisant URLs LDAP
• Netscape Communicator
• Microsoft Outlook
• Serveurs Netscape SuiteSpot (leur serveur mail, news, web...)

• LDAP versX. 500 et X. 500 vers LDAP
• HTTP vers LDAP (web500gw)
• WHOIS++ vers LDAP
• FINGER vers LDAP
• PH vers LDAP

• U-M LDAP SDK -- C (UMICH, OpenLDAP)
• Innosoft LDAP Client SDK (ILC-SDK) -- C (InnoSoft)
• Netscape Directory SDK -- Java, C (Netscape)
• PerLDAP Modules -- Perl (Netscape)
• Net- LDAPapi -- PERL (GNU)
• Java Naming and Directory Interface (JUNI) -- Java (SUN)
• Active Directory Service Interface (ADSI) -- COM (Microsoft)

• Microsoft Windows NT 5.0 utilise une base LDAP à la place des bases SAM
• PADL software :
• ypldapd : a gateway between NIS/YP and LDAP
• NSS LDAP : Nameservice switch library module
• PAM LDAP : Pluggable authentication module
• Sun
• NSS : Nameservice switch library module
• Linux
•  Linux Directory Services : projet de remplacement de NIS par LDAP

Bibliographie

• Linuxworld LDAP in action:

http://linuxworld.com/linuxworld/lw-1999-07/lw-07-ldap_1.html
• Linux LDAP services:

http://www.rage.net/ldap/
• OPenLDAP.org:

http://www.openldap.org
• Netscape Deployment Guide:

http://developer.netscape.com/docs/manuals/directory/deploy30/index.htm
• LDAP FAQ:

http://www.critical-angle.com/ldapworld/ldapfaq.html
• LDAP roadmap and FAQ:

http://www.kingsmountain.com/ldapRoadmap.shtml
• RFC 1777 The Lightweight Directory Access Protocol:

http://www.umich.edu/~dirsvcs/ldap/doc/rfc/rfc1777.txt
• LDAP Version 2 standard:

http://www.ietf.org/rfc/rfc1777.txt
• LDAP Version 3 standard:

http://www.ietf.org/rfc/rfc2251.txt
• The LDAP Extensions Working Group of the IETF:

http://www.ietf.org/html.charters/ldapext-charter.html
• The LDAP Duplication/Update Protocol Working Group of the IETF:

http://www.ietf.org/html.charters/ldup-charter.html
• Understanding and Deploying LDAP Directory Services, Tim Howes, Mark C. Smith, Gordon S. Good (Macmillan Technical Publishing, January 1999):

http://www.amazon.com/exec/obidos/ASIN/1578700701/qid%3D931400785/002-1316415-0583202
• "Don't make me LDAP you," Mark Komarinski and Cary Collett (LinuxWorld, March 1999). In a lightweight installation of the Lightweight Directory Access Protocol, perhaps its most useful feature for the harried sysadmin is that it helps prevent users from bugging you to ask about other users' e-mail addresses:

http://www.linuxworld.com/linuxworld/lw-1999-03/lw-03-uptime.html
• "Lighting up LDAP," Cameron Laird and Kathryn Soraiz (Sunworld, July 1999). Do you know how to develop LDAP applications? This beginner's tutorial traces the initial steps to learning LDAP:

http://www.sunworld.com/sunworldonline/swol-07-1999/swol-07-ldap.html
• "LDAP: The next-generation directory?" Dave Kosiur (Sunworld, October 1996). A good introduction to this handy protocol:

http://www.sunworld.com/swol-10-1996/swol-10-ldap.html
• "Life after DNS," Rawn Shah (Sunworld, October 1996). A comparison of LDAP and DNS:

http://www.sunworld.com/swol-10-1996/swol-10-connectivity.html
• An overview of LDAP-based directory service from the University of Michigan

http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/1.html#RTFToC1