Le projet d'annuaire LDAP à Rennes 1 - Raymond Bourges - Gérard Delpeuch
Les besoins De plus en plus d'outils informatiques sont utilisés à l'université Leur accès est souvent lié à une validation de la personne qui souhaite les utiliser Leur accès peut etre lié ou non à l'appartenance à une certaine population (UFR, service...)
Les objectifs Simplifier la tache des administrateurs des systèmes informatiques Faciliter l'utilisation des outils informatiques : mot de passe unique, démarches d'ouverture de compte simplifiées Bénéficier des bases de données existantes
La situation actuelle Inadaptation des annuaires existants : NIS, NetWare, Active Directory... Multiplication des points d'administration Décalage par rapport à la situation «réelle»
Emergence du protocole LDAP Les besoins énumèrés précedemment ne sont pas propres à Rennes 1 Pour ces raisons le protocole LDAP est intègré par de plus en plus de produits informatiques LDAP (Lightweight Directory Acces Protocol) n'est pas un protocole propriétaire, ce qui facilite sa diffusion
L'intérêt de LDAP pour Rennes 1 Avoir une base unique de référence utilisable directement par les outils informatiques Diffuser des informations «fiables» issues des services administratifs de l'université Minimiser les interventions manuelles des administrateurs Simplifier l'utilisation des produits informatiques
Une approche «marketing» Il fallait pouvoir parler du projet à tous le personnel et qu'il se sente concerné La base LDAP va donc délivrer aux utilisateurs un «SESAME» qui leur donnera accès aux services dont l'accès est controlé par LDAP La structure de la base reflète le statut des personnels vis à vis du SESAME
La structure le la base Trois «ou» selon la situation de la personne : Peoplenew : pour les nouveaux arrivants, ceux qui n'ont pas encore validé leur SESAME People : pour les personnes ayant obtenu un SESAME et ayant accès aux services associés Peopleoff : pour ceux qui ont quitté l'université
L'alimentation de la base LDAP à partir d'harpege Une seule base de référence : HARPEGE S'appuie sur une mise à jour rapide d'harpege Permet la validation automatique de tout nouvel arrivant pour les services de base (messagerie...) Permet de définir l'appartenance implicite de la personne à certaines entités et de la valider automatiquement à certains services (listes, intranets...)
Harpège 1 / 2 Application nationale de gestion des personnels Décomposition de la structure de l'établissement sous forme d'un arbre Deux types de population : Hébergés (grands organismes de recherche) Une seule affectation possible Personnels (contractuels, vacataires, titulaires, etc.) Plusieurs affections possibles
Actuellement : Harpège 2/2 Harpège sert de base à un annuaire téléphonique sur le Web Harpège contient des adresses électroniques qui sont à jour (utilisation de vrfy)
Tenir compte de l'existant : NIS Une base NIS (Network Information System) contient déjà un grand nombre d'usagers des services du CRI, en particulier de la messagerie Cela impose : La continuité de service NIS pendant une période assez longue, donc la synchronisation NIS <-> LDAP La fusion des informations NIS et HARPEGE à la création de la base LDAP
Fusion NIS-HARPEGE A faire une fois On importe le fichier revaliases dans Harpège Un programme Perl apparie le n dossier Harpège avec l'uid : 1) Grâce à la relation uid-->email du fichier revaliases importé et de email-->n dossier Harpège 2) Grâce au prénom et au nom Harpège et au champ gecos NIS On met à jour l'attribut LDAP employeenumber On met HARPUR1 dans l'attribut LDAP ur1sourcecreation Résultats : 4100 dans NIS, 4000 Dans Harpège. Il en reste environ 1000 utilisateurs NIS non rapprochés
L'implémentation par le CRI Mise en place d'un serveur LDAP, ainsi que d'un serveur de secours (réplica) Choix du logiciel I-Planet (anciennement Netscape) directory server Acquisition d'un serveur Sun Ultra 250 bi-processeur sous Solaris La synchronisation avec une base NIS pour assurer la transition
Le planning Une maquette, construite à partir d'une fusion de la base HARPEGE et de la base NIS du CRI est en place depuis septembre 2000 Elle est synchronisée avec une base NIS Le démarrage du serveur en exploitation est prévu pour le printemps 2001
Objectif : une base de référence La base doit etre complète et à jour Elle prend ses données à la source : au service du personnel (base HARPEGE) L'effort a porté sur la mise à jour rapide d'harpege (en amont) par la décentralisation de l'alimentation de cette base Ce sont les composantes, voire les personnels qui peuvent ajouter ou mofifier des attributs
Fusion HARPEGE-LDAP A faire régulièrement Un programme Perl met à jour les entrées LDAP de type HARPUR1: Boucle sur les individus sous contrat Mise à jour des entrées de People Création des entrées dans PeopleNew Rapatriement des entrées de PepleOff et maj Boucle sur les entrées de People Si encore sous contrat (+ 8 jours) on ne fait rien Si plus sous contrat (+ 8 jours) Déplacement vers PeopleOff
Objectif : une base robuste L'objectif prioritaire est d'offrir une base robuste et pertinente C'est sur cette base solide que viendront s'appuyer progressivement les services clients
Applications clientes Authentification Unix native Messagerie electronique Listes de diffusion Acces Intranet Acces aux logiciels de gestion de l'université NT, NetWare...
Authentification Unix Soit Unix sait consulter LDAP (ex : Solaris 8) Sinon on peut ajouter un module d'authentification (PAM) (ex : PADL software) 0n conserve le mécanisme de NSSWITCH et en particulier la fonctionnalité des NETGROUPs Le maintien d'une synchronisation NIS permet d'effectuer la transition en douceur
Messagerie Prise en charge des tables d'aliases existantes Rattachement des aliases aux «People»s de la base LDAP Attribution des nouveaux aliases avec contrôle des doublons Passage de SENDMAIL à POSTFIX
Auth-LDAP pour Apache Connexion basic http par user et passwd Recherche du user dans la base LDAP --> DN Connexion à la base LDAP avec DN et passwd Accès autorisé en fonction de la réponse du serveur LDAP Ex : AuthType Basic AuthName LDAP AuthLDAPURL ldap://univers.univ-rennes1.fr:389/ou=people, dc=univrennes1,dc=fr?uid?sub? ( (departmentnumber=57cri)(departmentnumber=900)) require valid-user
LDAP et Oracle Des pistes à explorer : Création d'un trigger au logon sur la base CREATE TRIGGER logontrig AFTER LOGON ON DATABASE Possibilité d'utiliser la package DBMS_LDAP pour accéder à LDAP depuis Oracle Les deux ensemble...
LDAP et Sympa Sympa comme serveur de listes de diffusion LDAP comme référence des abonnements Listes par structure Harpège Listes par campus Etc. include_ldap_query ttl 43200 host univers.univ-rennes1.fr suffix ou=people,dc=univ-rennes1,dc=fr filter ( (departmentnumber=57cri)(departmentnumber=900))
LDAP et NT, NetWare Des idées pour NT Un PDC sur Unix (Samba ou SUN PC NetLink) Echange de fichiers LDIF vers Active Directory Meta Directory et des connecteurs Des idées pour NetWare Meta Directory...
Vers un annuaire étudiants L'étape suivante est la constitution d'un annuaire LDAP des étudiants Alimenté par la base scolarité APOGEE Pour simplifier l'administration de la messagerie étudiante et des salles de TP et de libre-service Synchronisée avec la base du personnel (enseignants)