Le projet d`annuaire LDAP à Rennes 1

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
Harpège 2/2
♦
Actuellement :
♦
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
rennes1,dc=fr?uid?sub?
(|(departmentnumber=57CRI)(departmentnumber=900))
∀
require valid-user
, dc=univ-
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)