Introduction à LDAP Licence Pro Avril 2003 Yves Durand , Avril 03 mars 2002 Licence Pro Avril 2003 Introduction à LDAP Support de cours, qui reprend largement les notres de Laurent Mirtain Yves Durand , Avril 03 Mars 2002 Yves Durand Yves Durand

Annuaires LDAP : plan Qu’est-ce que c’est un annuaire mars 2002 Annuaires LDAP : plan Qu’est-ce que c’est un annuaire Protocole de LDAP Modèle d’information Modèle de nommage Partition & duplication Sécurité Modèle fonctionnel Conception d’un modèle de nommage Solutions / vulnérabilités / exemples Plan Qu’est-ce qu’un annuaire: Depuis DNS jusqu’a répertoire de services (Cosnaming à la corba, SLP) Ce que ce n’est pas : quelques différence avec des exemples bien connus Qques exemples Propriétés de LDAP Quelques applications Notes: On s’épargne l’historique de LDAP (laissons cela aux comités de normalisation) On passe rapidement sur l’aspect sécurité Mars 2002 Yves Durand Yves Durand

Qu’est-ce qu’un annuaire mars 2002 Qu’est-ce qu’un annuaire Répertoire en ligne, dynamique Possibilité de faire des recherches Contrôle d’accès à l’information Ce n’est pas: approprié à de fréquentes écritures destiné à manipuler des données volumineuses un substitut à un serveur FTP, un système de fichiers,... Un annuaire électronique est un entrepôt d’informations rendues disponibles sur le réseau: LDAP est A mi-chemin entre un répertoire spécifique à une application, et un mecanisme question réponse à la DNS ou SLP. On parle ici d’annuaire dynamique & en ligne, pas d’une sortie en texte laissée un beau jour sur le net. Un annuaire LDAP est une coquille vide. Il ne connait que des DN ( distinguished name qui est de fait le nom d'une entrée), des objectclass et des attributs. Les Objectclass définissent des attributs, obligatoires, uniques, multi-valués, le type de valeur, la méthode de recherche, les index. En aucun cas une base LDAP ne se préoccupe des vérouillages, de transactions ou de cohérence des données. C'est a l'application de veiller à ce problème. Comparé à DNS: DNS est un annuaire global, il est distribué entre serveurs coopérants, il a un espace de nommage uniforme Mars 2002 Yves Durand Yves Durand

Exemple typique d’annuaire (1) mars 2002 Exemple typique d’annuaire (1) ldap.company.com Serveur d’infrastructure [ ex passerelle mail ] passwords Un annuaire LDAP peut répondre à différents services: Diffusion de données: annuaire web basé sur LDAP Protocole de service pour des applis: gestion de listes, composition d’adresses Passerelle Protocole de service pour services d’infrastructure: depot de certificats, gestion des droits d’accès Exemple: la compagnie NationsBank (#3 aux US) a consolidé 750+ annuaires distincts en un site LDAP: 24 annuaire e-mail Répertoire des firewalls Utilisé pour Données employés Données clients Données d’authentification (certificats) Serveur d’infrastructure [ ex auth. Accès externes] Pages blanches Entreprise (web) Serveur d’application [ ex paye ] Mars 2002 Yves Durand Yves Durand

Exemple typique d’annuaire (2) mars 2002 Exemple typique d’annuaire (2) Serveur d’infrastructure [ ex passerelle mail ] <smtp, <pop3, <imap, ldap> <smtp> MTA MUA (mail user agent) Mailbox virtuelles Postfix+courierIMAP+LDAP Solution Exemple de MTA(mail transfer agent) : sendmail, postfix Pb: éviter de créer un login pour les utilisateur sur le serveur tournant le MTA Plus sur http://albert.washcoll.edu/howto/postfix-courier-howto.txt administration ldap.company.com Mars 2002 Yves Durand Yves Durand

Annuaires versus databases mars 2002 Annuaires versus databases Annuaires Performance ~140 req/sec (**) Ratio Read/write1000<r<10000 Extensibilité Distribution AAA cablé Protocole standard : LDAP Database Performance ~n*100 xAct/s (*) Auth/ etc. à gérer langage “standard”: SQL Source : Howes/Smith/Good page 13 Extensibilité: on peut étendre le schéma à volonté, ajouter des données avec des types folkloriques Distribution des données:distribuer les données sur plusieurs serveurs (ou les répliquer) est plus facile à faire sur un directory (pas de notion de tables dont il faut maintenir l’intégrité. De la même façon, la réplication est prévue d’entrée de jeu sur les directory, plus difficile et gourmande sur les databases Performances : chiffres relativement proches mais a prendre avec des gants (**) [Measurement and Analysis of LDAP Performance dans http://www.cs.columbia.edu/~hgs/papers/Wang0006_Measurement.pdf ] Alors pourquoi on fait des databases ? Les xAct supportées par les directory sont simples: single read || single write En bref Ratio Read/write : Les annuaires sont conçus pour la lecture surtout Extensibilité : grace aux mécanismes de replication de de referral. Plus simple à gérer que ds liens de databases Correct mais moins important: l’authentification est intégrée au standard dans LDAP, pas dans les databases Correct: pas d’aspect transactionel dans LDAP (*) Source : Howes/Smith/Good 1999 Mars 2002 Yves Durand Yves Durand

Facettes de LDAP LDAP définit : mars 2002 Facettes de LDAP LDAP définit : le protocole -- comment accéder à l’information contenue dans l’annuaire, un modèle d’information -- le type d’information contenu dans l’annuaire, un modèle de nommage -- comment l’information est organisée et référencée, un modèle fonctionnel -- comment on accède à l’information, un modèle de sécurité -- comment données et accès sont protégés, un modèle de duplication -- comment la base est répartie entre serveurs, des API -- pour développer des applications clientes, LDIF -- un format d’échange de données. (d’après Mirtain) Mars 2002 Yves Durand Yves Durand

Protocole (1) Communication client/serveur mars 2002 Protocole (1) Communication client/serveur Normalisée (LDAPv3, RFC2251) Communication serveur/serveur Referral défini, replication en cours (LDUP) Messages LDAP encapsulés dans des trames TCP/IP [pas la seule solution, ex. UDP] Pas en ASCII mais en Lightweight Basic Encoding Rules: LBER Le Serveur écoute sur le port 389 (par défaut) / 636 Le protocole nécessite une connection : bind Plus sur http://www.umich.edu/~dirsvcs/ldap/doc/rfc/rfc1777.txt Mars 2002 Yves Durand Yves Durand

Protocole (2): client-serveur mars 2002 Protocole (2): client-serveur bind status requête Réponse 1 Réponse 2 résultat unbind L’opération Abandon existe également, pas de réponse. À noter: Tout est initié depuis le client, on s’appuie sur le transport en dessous. L’authentification est faite pendant le bind. Mars 2002 Yves Durand Yves Durand

Modèle de nommage / modèle d’information mars 2002 Modèle de nommage / modèle d’information country must c may description may searchguide c=fr organization must o may businessCategory may postalAddress o=ventes organizationalUnit must ou may businessCategory may registeredAddress ou=aspirateurs person must cn,sn may description cn=maurice_duplantier Le modèle de nommage définit comment sont organisées les entrées de l’annuaire et comment elles sont référencées. Le modèle d’information définit le type de données pouvant être stockées dans l’annuaire. Bien distinguer modèle d’info & modèle de nommage !! Le modèle d’info est normalisé (IANA) Le modèle de nommage , c’est votre pb (DIT==directory information tree) Mars 2002 Yves Durand Yves Durand

Modèle d’information (1) mars 2002 Modèle d’information (1) Kescekeuçé ? Un jeu de règles qui détermine ce qui peut être stocké dans le répertoire Verification avant stockage d’informations Un jeu de règles qui contrôle l’exploitation de l’information Règles de comparaison Pas les règles d’accès Le modèle d’information définit le type de données pouvant être stockées dans l’annuaire. L’entrée (Entry) = élement de base de l’annuaire. Elle contient les informations sur un objet de l’annuaire. Ces informations sont représentées sous la forme d’attributs décrivant les caractéristiques de l’objet. Toute sorte de classe d’objet (réel ou abstrait) peut être représentées. Le schéma de l’annuaire définit la liste des classes d’objets qu’il connaît. Mars 2002 Yves Durand Yves Durand

Modèle d’information (2) mars 2002 Modèle d’information (2) schéma Décrit les classes d’objets Structurelles Auxiliaires abstraites Décrit les types d’attributs qui sont rattachés user operational Le Directory schema est la « charte » qui définit, pour le serveur, l’ensemble des définitions relatives aux objets qu’il sait gérer. Le schéma décrit les classes d’objets, leurs types d’attributs et leur syntaxe. Chaque entrée de l’annuaire fait obligatoirement référence à une classe d’objet du schéma et ne doit contenir que des attributs qui sont rattachés au type d’objet en question. Classes d’objets : 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. exemple: extensibleObject posixAccount Une classe abstraite désigne des objets basiques de LDAP. exemple: top dnsResourceRecord Mars 2002 Yves Durand Yves Durand

Modèle d’information (3) mars 2002 Modèle d’information (3) Classes d’objets Les classes d’objets modélisent des objets réels ou abstraits en les caractérisant par une liste d’attributs optionnels ou obligatoires. Une classe d’objet est définie par : Un nom, qui l’identifie Un OID, qui l’identifie également Des attributs obligatoires Des attributs optionnels Un type (structurel, auxiliaire ou abstrait) Exemples de classes d’objet : une organisation (o), ses départements (ou), son personnel (organizationalPerson), ses imprimantes (device), ses groupes de travail (groupofnames). (source : L. Mirtain) Mars 2002 Yves Durand Yves Durand

Modèle d’information (4) mars 2002 Modèle d’information (4) Core.schema objectclass ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) top organizationalUnit person objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) organizationalPerson Les classes d’objets forment une hierarchie, au sommet de laquelle on trouve l’objet top Chaque classe d’objet hérite des attributs de la classe père Mars 2002 Yves Durand Yves Durand

Modèle d’information (5) mars 2002 Modèle d’information (5) OID Exemple de classe d’objet ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) Tiré de /usr/share/openldap/schema/core.schéma OID signifie Object identifier. La hiérarchie des Id représente qui a autorité pour définir un nouvel objet Mars 2002 Yves Durand Yves Durand

Object instance example mars 2002 Object instance example dn: uid=tlippert, ou=Development, dc=structure-net, dc=de objectclass: organizationalperson cn: Thomas Lippert sn: Lippert l: Hamburg postalcode: 21033 streetadress: billwiese 22 telephonenumber: 040-7654321 facsmiletelephonenumber: 040-7654321 Cn & sn sont obligatoires pour cet objet parce organizationalPerson hérite de person ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) Une entrée peut appartenir à un nombre non limité de classes d’objets. Les attributs obligatoires sont la réunion des attributs obligatoires de chaque classe. Mars 2002 Yves Durand Yves Durand

mars 2002 Le modèle de nommage (1) Organisation des entrées : structure logique arborescente, le directory information tree (DIT) Chaque objet est une instance d’objet Chaque entrée est identifiée par un nom, le DN=distinguished name Le “suffix” définit l’espace de nommage dont le serveur a la gestion Un noeud de l’arbre (entrée de l’annuaire) est appelé DSE (directory service entry) Sommet de l’arbre: BaseDN ou rootDSE racine de l’arbre Le modèle de nommage définit comment sont organisées les entrées de l’annuaire et comment elles sont référencées. Les entrées représentent des objets. L’organisation de ces objets se fait suivant une structure logique hiérarchique : le Directory Information Tree (DIT). Au sein de ce DIT, l’identification d’une entrée se fait à l’aide d’un nom, le Distinguish Name (DN). Un serveur peut gérer plusieurs arbres (donc plusieurs suffixes). Il possède une entrée spéciale, appelée root directory specific entry (rootDSE) qui contient la description du DIT. Avec LDAP, vous êtes libres d’organiser vos données comme bon vous semble (design du DIT). Mars 2002 Yves Durand Yves Durand

cn=maurice_duplantier mars 2002 Le modèle de nommage (2) Racine de l’annuaire dn:dc=domaine,dc=com objectClass:top dn:ou=direction,dc=gazu,dc=com objectClass:organizationalUnit ou:direction dc=gazu, dc=com ou=direction ou=marktg ou=lab cn=adeline_durand cn=maurice_duplantier dn:cn=maurice_duplantier,ou=lab,dc=gazu,dc=com objectClass:organizationalPerson objectClass:person title:larbin cn:maurice_duplantier sn:maurice userPassword:{md5}$3$zw4kD19KJ0h telephoneNumber:047676713 RDN La structure est indiquée uniquement par l’écriture des dn (distinguished names) Designation des entrées : Par le nom absolu (DN): par exemple (cn=Claudie_Martin, ou=class-Mr-Marand, ou=basson, o=CNR-Grenoble, c=FR) Le RDN (relative Distingusihed name): chaque objet n’en possède que un. Mars 2002 Yves Durand Yves Durand

Le modèle de nommage: alias & referral mars 2002 Le modèle de nommage: alias & referral C FR O CNR-Grenoble OU Basson piano class-Mr-Marand CN Denis_Marand Claudie_Martin class-Mme-Violette Mauricette_duplantier permettent à une entrée de l’annuaire de pointer vers une autre entrée du même (alias) ou d’un autre(referral) annuaire. L’attribut aliasObjectName de l’objet alias a pour valeur le DN de l’entrée pointée. dn: cn=Claudie_Martin, ou=class-Mr_marand, ou=Basson, o=CNR-Grenoble, c=FR objectclass: alias objectclass: aliasObject aliasedObjectName: cn=Claudie_Martin, ou=class-Mr_marand, ou=Basson, o=CNR-Grenoble, c=FR cn: John Doe Bien sur, le mécanisme d’alias est dangereux: pourquoi. Mars 2002 Yves Durand Yves Durand

Redirection: Referral mars 2002 Redirection: Referral URL Mars 2002 Yves Durand Yves Durand

Modèle de nommage: referral mars 2002 Modèle de nommage: referral dn: dc=univ-nancy2,dc=fr objectClass: top objectClass: domain dc: univ-nancy2 dn: ou=Pers,dc=univ-nancy2,dc=fr ou: Pers objectClass: referral objectClass: extensibleObject ref: ldap://ldap.univ-nancy2.fr:392/ou=Pers,dc=univ-nancy2,dc=fr dn: ou=Etudiants,dc=univ-nancy2,dc=fr ou: Etudiants ref: ldap://ldap.etudiant.univ-nancy2.fr:392/ou=Etudiants,dc=univ-nancy2,dc=fr Attention, un alias est « déréférencé » par le serveur, alors qu’un referral retourne vers le client qui est responsable de le traiter. Les smart referrals sont stockés dans l'attribut ref de l'objet auquel on a rajouté la classe d'objet referral. Dans l'exemple ci-dessous, on indique dans la branche Rocquencourt de l'arbre du serveur de L'Inria Sophia Antipolis (figure 3) qu'il faut s'adresser au serveur LDAP de l'Inria Rocquencourt. Mars 2002 Yves Durand Yves Durand

mars 2002 Loi des partitions Tous les objets d’une partition doivent partager un ancêtre commun, et cet ancêtre doit appartenir à la partition O O le partitionnement est une solution pour les trop gros volumes d’entrées (> 10000), ou des organisations éclatées en unités autonomes. Les mécanismes de referral peuvent être une alternative à la duplication. Quelques précautions : limiter les referrals à des suffixes ou des branches principales de l’arbre (ne pas s’en servir comme alias pour des entrées), maintenir la cohérence des liens... et vérifier la disponibilité du serveur distant, attention au contrôle d’accès et à l’authentification : les authentifications et les règles d’accès du serveur initial ne s’appliquent plus aux données du serveur pointé, attention au temps de réponse : traversée de réseaux WAN, problème de sécurité : les données transitent sur les réseaux WAN... Mars 2002 Yves Durand Yves Durand

Duplication: replication mars 2002 Duplication: replication Le modèle de duplication (replication service) définit comment dupliquer l’annuaire sur plusieurs serveurs. Pas encore standard, mais est proposé par la plupart des serveurs. L’IETF prépare le protocole LDUP. Master slapd Pourquoi Dupliquer l’annuaire : Pallier à une panne de l’un des serveurs, une coupure du réseau, surcharge du service. garantir la qualité de service : temps de réponse et sûreté de fonctionnement. améliorer les performances en plaçant les serveurs près des clients, gérer les entrées localement et de les diffuser sur plusieurs sites. de répartir le travail entre plusieurs serveurs (load balancing) Plusieurs politiques de replication (temps réel, heures fixes) mais: Les serveurs doivent utiliser les memes schémas (arbres ou sous-arbres, arbres filtrés) Il faut dupliquer les règles d’accès slave slapd Mars 2002 Yves Durand Yves Durand

Implémentation dans openldap mars 2002 Implémentation dans openldap ldap2ldif /var/lib/ldap/*.dbb truc.ldif /usr/sbin/slapd ldapmodify include /etc/openldap/slapd.conf # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.7 2001/09/27 20:00:31 kurt Exp $ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. include %SYSCONFDIR%/schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org […] # Sample Access Control # Allow read access of root DSE # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate #access to dn="" by * read #access to * # by self write # by users read # by anonymous auth # if no access controls are present, the default is: # Allow read by all # rootdn can always write! ####################################################################### # ldbm database definitions database ldbm suffix "dc=my-domain,dc=com" #suffix "o=My Organization Name,c=US" rootdn "cn=Manager,dc=my-domain,dc=com" #rootdn "cn=Manager,o=My Organization Name,c=US" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd/tools. Mode 700 recommended. directory %LOCALSTATEDIR%/openldap-ldbm # Indices to maintain index objectClass eq /usr/share/openldap/core.schema Mars 2002 Yves Durand Yves Durand

mars 2002 modèle de sécurité Le modèle de sécurité décrit le moyen de protéger les données de l’annuaire des accès non autorisés. La sécurité se fait à plusieurs niveaux : par l’authentification pour se connecter au service (phase de bind) par un modèle de contrôle d’accès aux données (les acl) – non standard - par le chiffrement des transactions entre clients et serveurs ou entre serveurs. Acl <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 Mars 2002 Yves Durand Yves Durand

mars 2002 modèle de sécurité (2) par l’authentification pour se connecter au service (phase de bind) Anonyme ou RootDN Mot de passe en clair ou SSL/TLS (eg certificats SSL) Mécanisme extérieur : SASL SASL: Simple Authentification and Security Layer Mars 2002 Yves Durand Yves Durand

mars 2002 modèle de sécurité (3) par un modèle de contrôle d’accès aux données (les acl) – non standard – <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 Acl <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 Mars 2002 Yves Durand Yves Durand

mars 2002 modèle de sécurité (4) par le chiffrement des transactions entre clients et serveurs ou entre serveurs. LDAPv3 supporte le chiffrement des transactions (entre clients et serveurs ou entre serveurs) via l’utilisation de SSL ( ldaps ) ou de son successeur, TLS ( startTLS extended operation ). SSL ou TLS servent également pour l’authentification par certificats : permet au client de prouver son identité au serveur et, en retour, à celui- ci d’en faire de même vis à vis du client. Acl <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 Mars 2002 Yves Durand Yves Durand

vulnérabilités Déni de service mars 2002 vulnérabilités Déni de service Codes BER semi-valides, requete malformées => freeze Mesures compensatoires Firewall Opérations signées Buffer overflow Attaquant récupère les privilèges système, ou privilège de la database Tourner ldap en chroot Mars 2002 Yves Durand Yves Durand

Modèle fonctionnel Ldapsearch, outils web, API Ldapmodify, GQ,… * mars 2002 Modèle fonctionnel Interrogation Search compare Modification Add Modify Rename delete Connection Bind Unbind Abandon Ldapsearch, outils web, API Ldapmodify, GQ,… * Mars 2002 Yves Durand Yves Durand

Requête (1) LDAP ne fournit pas d’opération de lecture d’entrée. mars 2002 Requête (1) LDAP ne fournit pas d’opération de lecture d’entrée. Pour connaître le contenu d’une entrée, il faut écrire une requête qui pointe sur cette entrée. Une requête est composée de 8 paramètres : base object l’endroit de l’arbre où doit commencer la recherche scope la profondeur de la recherche derefAliases si on suit les liens ou pas size limit nombre de réponses limite time limit temps maxi alloué pour la recherche attrOnly renvoie ou pas la valeur des attributs en plus de leur type search filter le filtre de recherche list of attributes la liste des attributs Mars 2002 Yves Durand Yves Durand

Requête (3) : format des filtres mars 2002 Requête (3) : format des filtres (<operator>(<search operation>)(<search operation>)...)) Ex : (&(objectclass=inetOrgPerson)(!(mail=*))) Toutes les entrées de type utilisateur sans adresse mail : Exemples de filtres de recherche (cn=Laurent Mirtain) égalité Nom vaut "Laurent Mirtain" (cn=*Mart*) sous-chaîne Nom contient "Mart" (cn~=martin) approximation Nom sonne comme "martin" (employeenumber>=100) comparaison Numéro supérieur à 100 (sn=*) existence Tous les noms propres (&(sn=Mirtain)(l=sophia)) ET Nom vaut "Mirtain" ET localisation vaut Sophia (|(ou=sophia)(ou=rocquencourt)) OU ou vaut sophia ou rocquencourt (!(tel=*)) NON Toutes les entrées sans attribut téléphone D’après Mirtain, encore Mars 2002 Yves Durand Yves Durand

mars 2002 Requête (2) Mars 2002 Yves Durand Yves Durand

mars 2002 URLS LDAP syntaxe : 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 : s’arrête au niveau courant (par défaut) - one : descend d’un niveau - sub : parcourt tous les sous- niveaux <filter> : filtre de recherche, par défaut (objectClass=*) Slide empruntée à l’excllent jeu de Laurent Mirtain exemples : ldap:// ldap. netscape. com/ ou= Sales, o= Netscape, c= US 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) Mars 2002 Yves Durand Yves Durand

url ldap depuis ie mars 2002 Yves Durand Ldap://zugzwang.grenoble.hp.com/dc=gazu,dc=fr??sub? Mars 2002 Yves Durand Yves Durand

mars 2002 Conception du modèle Définir son système d’information: quelles applis, quelle capacités, quelle topologie en  avec l’espace de nommage Directory peut être plat, ou branché par organisations Choix des RDN pour designer les personnes. cn significatif, cn abstrait (event. Avec un alias) uid abstrait, unique&non ambigu Recommendation IETF : email Hierarchique: + Reflète l’organisation interne, Minimise le problème de DNs identiques. Facilite le partitionnement des données entre plusieurs serveurs. Mais: - Longueur du DN. Problème si l’organisation change. Durée de recherche augmentée. A plat: + Pas de soucis de classification des entrées, DN courts , stabilité du DIT, Meilleure rapidité de recherche. - Risque de DNs identiques. Mal adapté au listage des entrées Choix des RDN: Cn=marc_dubois : pratique mais peut changer, pb si homonyme Uid=12345 : directory devient illisible, mais garantit l’unicité. Necessité de maintenir une info (type cn) pour les outils type mail. Propal de l’IETF: uid=yves_durand@hp.com,dc=hp,dc=com Choix du suffixe (suite) Il pourra s’exprimer sous deux formes : • 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 Cette dernière forme est préconisée par l’IETF. Mars 2002 Yves Durand Yves Durand

Qques solutions Serveurs Clients Openldap Slapd (u Michigan) mars 2002 Qques solutions Serveurs Openldap Slapd (u Michigan) Netscape directory server IBM LDAP MS Active Directory !! Clients GQ Web browsers Clients mail Ldapsearch Cygsoft LDAP browser Mars 2002 Yves Durand Yves Durand

Acronymes DIT ? Directory information tree OID ? Object IDentifier mars 2002 Acronymes DIT ? Directory information tree OID ? Object IDentifier CN ? Common name SN ? LDIF Format d’encodage des données DN & RDN ? [relative] distinguished name LBER Lightweight Basic Encoding Rules RTFM ? Lisez le manuel !! J CN est une classe d’objets: Mars 2002 Yves Durand Yves Durand

Ce qu’il faut retenir A quoi cela sert Différences avec une database mars 2002 Ce qu’il faut retenir A quoi cela sert Différences avec une database Modèle d’objets et modèle de nommage Se retenir de re-inventer des schémas (oid etc.) Se rappeller que ça existe ! Mars 2002 Yves Durand Yves Durand

Références bibliographiques mars 2002 Références bibliographiques “Understanding and Deploying LDAP directory Services” Howes/Smith/Good, MacMillan tech. Publishing Une bible… http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/LDAP.html Lisible & utile Les RFC Understanding LDAP. - IBM téléchargeable a partir de http://tux.iut2.upmf-grenoble.fr/~bonnaud/LP/reseaux/2002/reseaux.html Mars 2002 Yves Durand Yves Durand

TP Lancement/configuration d’un annuaire mars 2002 TP Lancement/configuration d’un annuaire Utilisation d’un outil client en consultation (GQ) Modification d’une base existante. Questions possibles: comment implémenter des transactions Mars 2002 Yves Durand Yves Durand