Differences

This shows you the differences between two versions of the page.

--- docpublic:systemes:ldap:ldap_principes [2014/01/10 10:01]
procacci@tem-tsp.eu created
+++ docpublic:systemes:ldap:ldap_principes [2020/01/24 13:07] (current)
procacci@tem-tsp.eu
@@ Line 184: / Line 184: @@
 .5  Sauvegarde en ligne des données PosixAccount
-    Résumé : Ceci est un document de travail en cours d'évolution (le qualificatif ``NEW'' indique les rubriques dernierement mises à jour) , cela explique la présence, notament dans les cadres d'exemple de la partie exploitation, de noms de machines, répertoires ... qui peuvent être différents d'un exemple à l'autre.
+=====  Résumé =====
-    Il s'agit dans un premier temps d'une présentation des concepts, suivi d'un decription détaillée de la mise en oeuvre d'un serveur OpenLdap pour la gestion système des services Unix.
-    Il existe beaucoup d'autres documentations sur le sujet, celle-ci recenses l'ensembles des étapes de la mise en oeuvre de l'annuaire LDAP à l'INT-Evry.
+Ceci est un document de travail en cours d'évolution (le qualificatif NEW indique les rubriques dernierement mises à jour) , cela explique la présence, notament dans les cadres d'exemple de la partie exploitation, de noms de machines, répertoires ... qui peuvent être différents d'un exemple à l'autre.
+Il s'agit dans un premier temps d'une présentation des concepts, suivi d'un decription détaillée de la mise en oeuvre d'un serveur OpenLdap pour la gestion système des services Unix.
+Il existe beaucoup d'autres documentations sur le sujet, celle-ci recenses l'ensembles des étapes de la mise en oeuvre de l'annuaire LDAP à l'INT-Evry.
+===== 1  Introduction =====
-  Introduction
 Le système d'information implique un nombre important d'annuaires. Par annuaire nous entendons un ensemble d'information utile à la réalisation de services. Ce peut être la liste du personnel pour les applications RH (payes, congés ...), une liste de compte pour l'accès aux ressources informatiques, se déclinant souvent en une liste par type de service (comptes Unix, comptes NT/2000, comptes RAS ...) chacun faisant référence à une base propre ( respectivement , Nis, SAM/Active Directory, radius ...), ou encore des informations pour l'autocommutateur, répertoriages de ressources immeubles; salles, prises ..., meubles: mobilier, matériels informatique ... .
 On le voit les besoins sont immenses et souvent redondants. Des solutions existent, elle sont souvent propriétaires et dépendantes des services. Face à ces faits, des standards ont été érigées, c'est notament le cas de la norme X.500, normalisation ISO dédiées aux annuaires électroniques. Elle reste cependant très lourde à mettre en oeuvre, est n'est pas adaptée aux réseaux réellement mis en productions (TCP/IP et non OSI !). C'est ici qu'intervient LDAP (Lightweight Directory Acces Protocol), qui comme son nom l'indique apporte de la souplesse aux normes X.500. L'objectif est le même: fédérer les informations dans une base unique dont l'accès est normalisé et indépendant de tout constructeur. Il apporte essentiellement une solution exploitable sur des réseaux que nous utilisons ( technologies Internet) et une mise en oeuvre abordable. Bien qu'il puisse répondre à l'ensemble des besoins d'un système d'information complexe, il n'est pas de notre volonté d'aboutir directement à ce point. Il conviendra avant tout de concrétiser son utilisation sur des services limités et déjà bien adaptés. Ce sera le cas, par exemple, de l'authentification des utilisateurs sur les différentes ressources informatiques de l'établissement.
-  l'existant
+===== 2  l'existant =====
-.1  X.500
+==== 2.1  X.500 ====
 Le standard X.500 définis en 1988 puis dans sa deuxième version en 1993 comprend plusieurs normes:
-    X500 concepts, modèles, services
+  *     X500 concepts, modèles, services
-    X501 modèles associés aux annuaires X500
+  *     X501 modèles associés aux annuaires X500
-    X509 identification et authentification
+  *     X509 identification et authentification
-    X511 détails des services offerts
+  *     X511 détails des services offerts
-    X518 les services ditribués entre plusieurs annuaires
+  *     X518 les services ditribués entre plusieurs annuaires
-    X519 protocoles de communication entre clients/serveurs
+  *     X519 protocoles de communication entre clients/serveurs
-    X520 attributs d'enregistrement prédéfinis
+  *     X520 attributs d'enregistrement prédéfinis
-    X521 classes d'objets prédéfinies
+  *     X521 classes d'objets prédéfinies
-    X525 réplication sur les serveurs
+  *     X525 réplication sur les serveurs
-.2  les annuaires en exploitation
+===== 2.2  les annuaires en exploitation =====
-.2.1  systèmes d'exploitation Windows
+==== 2.2.1  systèmes d'exploitation Windows ====
 Windows NT: l'information est disséminée dans plusieurs outils et bases de données (gestionnaires de serveurs, gestionnaire wins, gestionnaire des utilisateurs ...). Windows 2000: l'ensemble est regroupé dans un annuaire propriétaire ; Active Directory, mais compatible avec le protocole LDAP, il sera donc possible d'y accéder en lecture/écriture via LDAP grâce notament à l'interface de programmation ADSI.
-.2.2  Novell NDS
+==== 2.2.2  Novell NDS ====
 Novell à rendu son système d'annuaire indépendant du système d'exploitation (Netware). Novell Directory Service est un annuaire object disponible sur Netware, Solaris et Windows. Il supporte le standard LDAP v3 et les données au format LDIF ( Ldap Data Interchange Format, format texte de données d'import/export dans un annuaire LDAP ).
-.2.3  NIS
-Dès 1985 Sun à introduit le Network Information Service, déjà destiné à centraliser l'administration des informations système. Les informations sont stockées sous forme de map (table de correspondance entre une clé et une valeur: clé titan , valeur 192.163.12.43) dans de simples bases indexées (db, dbm ...), accessibles par des appels RPC (Remote Procedure Call). Dans un premier temps les map s'ajoutaient aux fichiers locaux (ajout d'un caractère ``+'' dans le fichier concerné pour rediriger la recherche vers les nis, remarque: depuis solaris 2 ce signe n'a plus cet effet. Avec solaris 2 et toutes ses sources d'information système (dns, nis+ ...) il devenait difficile de programmer dans chaque service ou utilitaire système, le mode de recherche. Sun a créé une API qui se place entre ces programmes et les différentes sources d'information sur lesquelles ils s'appuient, cette API est le Name Service Switch. Avec cette API les programmes n'ont plus a connaître les détails d'implémentation des services d'information qu'ils contactent. Les appels à cette API sont du type getXbyY (gethostbyname), lisent le fichier /etc/nsswitch.conf dans lequel est associé à chaque type de service de nom une liste des sources disponibles;
+==== 2.2.3  NIS ====
+Dès 1985 Sun à introduit le Network Information Service, déjà destiné à centraliser l'administration des informations système. Les informations sont stockées sous forme de map (table de correspondance entre une clé et une valeur: clé titan , valeur 192.163.12.43) dans de simples bases indexées (db, dbm ...), accessibles par des appels RPC (Remote Procedure Call). Dans un premier temps les map s'ajoutaient aux fichiers locaux (ajout d'un caractère + dans le fichier concerné pour rediriger la recherche vers les nis, remarque: depuis solaris 2 ce signe n'a plus cet effet. Avec solaris 2 et toutes ses sources d'information système (dns, nis+ ...) il devenait difficile de programmer dans chaque service ou utilitaire système, le mode de recherche. Sun a créé une API qui se place entre ces programmes et les différentes sources d'information sur lesquelles ils s'appuient, cette API est le Name Service Switch. Avec cette API les programmes n'ont plus a connaître les détails d'implémentation des services d'information qu'ils contactent. Les appels à cette API sont du type getXbyY (gethostbyname), lisent le fichier /etc/nsswitch.conf dans lequel est associé à chaque type de service de nom une liste des sources disponibles;
 exemple: passwd: files nis nisplus, host: files nis nisplus dns. La recherche se fait d'une source à l'autre dans l'ordre définis tant qu'une correspondance n'est pas trouvée, ce qui abouti à une erreur NOTFOUND en cas d'échec sur toutes les sources listées. On peut d'ailleurs utiliser l'option [NOTFOUND=return] afin d'indiquer aux programmes de consulter uniquement les sources listées à gauche de cette entrée, seulement en cas de disfonctionnement de ces sources celles de droite seront consultées. Exemple: networks: nis [NOTFOUND=return] files. Les NIS fonctionnent sur un système maître-esclave (les modifications se font sur le maître, elles sont répercutées sur le(s) esclave(s) du domaine nis), seulement ils ne sont pas adaptés à des volumes important de données, à chaque modification c'est l'ensemble de la base qui est transférée entre maitre-esclave. Il y à également un manque d'organisation des données sous forme hiérarchique. Enfin la sécurité d'accès à ce service est très faible
-.2.4  NIS+
+==== 2.2.4  NIS plus ====
-Sun à réagit aux défauts de NIS par l'introduction dans solaris 2 des NIS+. Ils répondent aux trois remarques ci-dessus en introduisant un propagation des données entre maître-esclave de manière incrémentale, en ajoutant la notion de root domain master en haut de l'arbre hiérarchique sous lequel de trouvent des subdmain master pouvant eux-mêmes être au-dessus d'autres subdomain-master. Enfin la notion de ``certificat, identité'' (credential) via une paire de clé privée/publique vient combler le problème de sécurité. L'imposition d'une architecture hiérarchique de haut en bas des nis+ qui implique une coopération entre les administrateurs systèmes des différents départements d'une organisation, ainsi que la gestion des paires clé privée/public fut finalement un frein au passage des nis aux nis+. Pourtant ces derniers préfigurent beaucoups de concepts utilisés par la suite dans LDAP.
+Sun à réagit aux défauts de NIS par l'introduction dans solaris 2 des NIS plus. Ils répondent aux trois remarques ci-dessus en introduisant un propagation des données entre maître-esclave de manière incrémentale, en ajoutant la notion de root domain master en haut de l'arbre hiérarchique sous lequel de trouvent des subdmain master pouvant eux-mêmes être au-dessus d'autres subdomain-master. Enfin la notion de **certificat, identité** (credential) via une paire de clé privée/publique vient combler le problème de sécurité. L'imposition d'une architecture hiérarchique de haut en bas des nis+ qui implique une coopération entre les administrateurs systèmes des différents départements d'une organisation, ainsi que la gestion des paires clé privée/public fut finalement un frein au passage des nis aux nis+. Pourtant ces derniers préfigurent beaucoups de concepts utilisés par la suite dans LDAP.
+==== 2.2.5  DNS ====
-.2.5  DNS
 Le Domain Name Service à été crée pour palier à l'élargissement des échanges de fichiers hosts et à la répartition de leur administration déjà conséquente dans le réseau ARPANET, précurseur de l'Internet. C'est un système de nommage hiérarchique à l'échelle de l'Internet. Il dispose d'une redondance et depuis peu d'un minimum de sécurité/contrôle d'accès. Bien que très performant et adapté dans son rôle de service de noms IP, il est reste aussi très spécialisé.
-.2.6  logiciels du marché
+==== 2.2.6  logiciels du marché ====
 Microsoft MS-exchange, Lotus cc:Mail, Novell Groupewise ou Netscape Messaging server utilisent des annuaires propriétaires , souvent liés à une base de donnée propre à leurs besoins pour la gestion de leurs ressources. Des interfaces d'accès (API) à ces bases sont disponibles (ADSI pour Microsoft, VIM pour Lotus).
-.2.7  logiciels spécifiques
-Il existe souvent dans l'entreprise un nombre important de produits ``maison'' basés la plupart du temps sur des SGBD (Oracles, DB2, MySQL, Access ...). Encore une fois, bien souvent une base de comptes est définis pour chacune de ces applications et les interfaces d'accès ne sont pas toujours simples (C, cobol ...) et uniques.
-  LDAP
+==== 2.2.7  logiciels spécifiques ====
+Il existe souvent dans l'entreprise un nombre important de produits maison basés la plupart du temps sur des SGBD (Oracles, DB2, MySQL, Access ...). Encore une fois, bien souvent une base de comptes est définis pour chacune de ces applications et les interfaces d'accès ne sont pas toujours simples (C, cobol ...) et uniques.
+===== 3  LDAP =====
 Après le succès des NIS et beaucoup plus modérément des NIS+ par SUN, le CCITT et l'ISO se sont attelés à définir un standard d'annuaire, dont l'accès serait indépendant des RPC (SUN), il créèrent le protocole X.500. Bien qu'ayant de très bonnes spécifications, les détails d'implémentations n'étaient en revanche pas très heureux que se soit au niveau de la rigidité des règles d'implémentation ou de la pile de protocole envisagée (ISO plutôt que TCP/IP !). C'est dans ces conditions qu'est née une version allégée de X.500 basée sur TCP/IP; Lightweight Directory Acces Protocol qui peut être définis comme étant un protocole de réseaux standard spécialisé dans la manipulation d'annuaires adapté aux réseaux et systèmes en exploitation sur l'Internet.
-.1  Modèles
+==== 3.1  Modèles ====
 Ce standard définis 4 modèles.
-Le modèle d'information
+  * Le modèle d'information qui définis la nature des données: classe, attribut, types..., l'arbre de données (DIT: Directory Information Tree).
-    qui définis la nature des données: classe, attribut, types..., l'arbre de données (DIT: Directory Information Tree).
+  * Le modèle de nommage qui organise et définis des règles de nommages des éléments de l'annuaire. Exemple; l'annuaire dispose d'un schéma, une classe d'objet doit être unique dans l'annuaire, elle est identifiée par un OID.
-Le modèle de nommage
+  * Le modèle fonctionnel qui définis les services offerts, comment accéder aux informations et comment les mettre à jours.
-    qui organise et définis des règles de nommages des éléments de l'annuaire. Exemple; l'annuaire dispose d'un schéma, une classe d'objet doit être unique dans l'annuaire, elle est identifiée par un OID.
+  * Le modèle de sécurité qui définis les droits d'accès et l'identification.
-Le modèle fonctionnel
-    qui définis les services offerts, comment accéder aux informations et comment les mettre à jours.
-Le modèle de sécurité
-    qui définis les droits d'accès et l'identification.
-.2  Réplication LDAP
+==== 3.2  Réplication LDAP ====
 Mécanisme qui permet de copier automatiquement les données d'un annuaire vers un autre serveur d'annuaire. Cela permet d'améliorer les performance en répartissant plusieurs annuaires identiques sur un domaine, un client sera au plus près de son serveur, cela permet aussi une répartition de la charge.
-.3  Subschema
+==== 3.3  Subschema ====
 Dans la norme V3 de LDAP le schéma doit être définis dans l'annuaire lui même. Par l'utilisation de classes (subschema) et attributs spécifiques on permet de lire et modifier le schéma de l'annuaire au moyen du protocole LDAP lui même.
 On peut lire le schéma via l'URL:
 ldap://localhost:port/cn=schema??base?obectclass=*
-.4  RootDSE
+===== 3.4  RootDSE =====
 On parle de RootDSE (Directory Server Agent (Dsa), Specific Entry). Il comprendra des attributs de type: NamingContext, SupportedExtensions, SupportedControl,SupportedSALMechanism,SupportedLDAPVersion. C'est le seul objet qui n'a pas de nom. http://www.techgalaxy.net/Docs/Dev/LDAPv3%20RootDSE%20Overview.htm
-.5  Définitions
+==== 3.5  Définitions ====
+<code>
 Règles
 règles de comparaison d'attributs identifiés par un oid.
@@ Line 3649: / Line 3665: @@
     Ce document a été traduit de LATEX par HEVEA.
+    </code>

docpublic/systemes/ldap/ldap_principes.1389348063.txt.gz · Last modified: 2014/01/10 10:01 by procacci@tem-tsp.eu

Show page Old revisions

[unknown link type]Back to top