Structure de l'annuaire LDAP
Infrastructure

EduLibre (4) : l'annuaire LDAP, brique de voûte du parc

Une arborescence décidée avant le premier compte, des identifiants numériques stables — parce que les permissions de fichiers ne connaissent que des numéros —, et le chiffrement dès le départ.

La documentation du projet emploie une expression juste : l'annuaire est la brique de voûte. Si le nommage, les identifiants numériques ou les certificats ne sont pas maîtrisés dès le départ, tout ce qui suit — clients d'annuaire, partages de fichiers, déploiement automatisé, authentification unique — devient inextricable.

Ce que l'annuaire porte

  • un référentiel d'identités — utilisateurs, groupes, et à terme les postes eux-mêmes ;
  • une source d'authentification pour les postes et pour les services web ;
  • la cohérence des identifiants numériques, sans laquelle les permissions de fichiers n'ont aucun sens ;
  • la gestion des droits par groupes — y compris un groupe d'administration exploité côté postes pour accorder les privilèges.

Ce dernier point mérite d'être souligné : accorder les droits d'administration par appartenance à un groupe de l'annuaire évite de configurer chaque machine individuellement. Un changement d'équipe se traduit par une modification d'appartenance, pas par une tournée des postes.

Une arborescence décidée avant le premier compte

Structure de l'annuaire et conventions figées

Trois branches — utilisateurs, groupes, postes — et des identifiants numériques attribués une fois pour toutes.

La structure retenue est volontairement simple : une racine correspondant au domaine interne, et trois branches — les utilisateurs, les groupes, les postes. Prévoir la branche des postes dès le départ, alors qu'elle est encore vide, évite une restructuration au moment de l'inventaire du parc.

Les groupes reflètent l'organisation pédagogique : élèves, enseignants, classes, administration du parc. Les identifiants numériques de ces groupes sont choisis et notés avant toute création.

Le point non négociable : des identifiants stables

C'est la décision qui structure tout le reste, et la documentation en donne la raison en une phrase : NFS et les permissions POSIX détestent les identifiants variables.

Un système de fichiers ne connaît pas les noms d'utilisateurs : il ne stocke que des numéros. Si l'identifiant d'un utilisateur change — recréation de compte, réinstallation approximative —, deux catastrophes deviennent possibles : ses fichiers ne lui appartiennent plus, ou bien ils appartiennent désormais à quelqu'un d'autre qui a hérité du numéro.

D'où la règle : les numéros sont attribués dans une plage réservée, notés, jamais réutilisés, et jamais laissés à l'attribution automatique.

Installation et structuration

Installation de l'annuaire et création de l'arborescence

Une reconfiguration explicite du service, des variables d'environnement pour éviter les erreurs de saisie, puis des fichiers LDIF versionnés.

Trois choix de mise en œuvre méritent commentaire.

Reconfigurer explicitement plutôt que subir l'installation

Même si l'installation du paquet pose déjà des questions, le projet repasse par une reconfiguration complète : domaine, organisation, mot de passe d'administration, moteur de base, refus des protocoles obsolètes. On sait ainsi ce qui a été répondu — et on peut le refaire à l'identique.

Des variables d'environnement pour le confort et la sécurité

Les commandes d'administration d'un annuaire sont verbeuses : identifiant de connexion, base de recherche, adresse du serveur. Les placer dans des variables évite les fautes de frappe — et le mot de passe est lu au clavier sans affichage, ce qui l'empêche de finir dans l'historique du shell. Détail d'hygiène qui devrait être systématique.

Des fichiers LDIF plutôt que des commandes interactives

Toute la structure — branches, groupes, comptes — est décrite dans des fichiers texte appliqués au serveur. Conséquence : la structure est versionnable, relisable et rejouable. Reconstruire l'annuaire sur une nouvelle machine consiste à réappliquer les fichiers dans l'ordre, pas à se souvenir de ce qu'on avait cliqué.

TLS, et pourquoi dès le début

L'annuaire est configuré pour chiffrer les échanges avec un certificat interne, et ce certificat est distribué aux clients qui doivent lui faire confiance. Ce n'est pas une précaution cosmétique : sans chiffrement, les mots de passe des élèves et des enseignants circulent en clair sur le réseau de la salle.

Le faire dès le départ évite surtout un piège classique : monter tous les clients en clair, puis découvrir que les activer en TLS demande de repasser sur chaque machine. Le chiffrement s'ajoute mal après coup.

Le compte d'administration de l'annuaire

Le compte créé par l'installation est puissant et technique. Le projet crée à côté un compte d'administration dédié, avec des droits accordés explicitement, et réserve le premier aux opérations exceptionnelles.

C'est le même raisonnement que pour un compte racine système : on n'y travaille pas au quotidien, on l'utilise quand il n'y a pas d'autre moyen — et on sait alors que l'opération est sensible.

La validation avant de continuer

Deux contrôles conditionnent la suite : le serveur répond bien sur la base de son arborescence, et son nom pleinement qualifié se résout correctement. Le second est aussi important que le premier : c'est ce nom qui figure dans le certificat, et un client qui contacte l'annuaire par une adresse IP obtiendra une erreur de validation parfaitement légitime.

La série EduLibre

De la décision à l'industrialisation du parc :

  1. 1. Pourquoi un socle libre pour un parc informatique
  2. 2. L'architecture globale, brique par brique
  3. 3. La passerelle : routage, NAT, DNS et DHCP
  4. 4. L'annuaire LDAP, brique de voûte — vous y êtes
  5. 5. NFS : profils, classes et quotas
  6. 6. PXE et Ansible : le parc en zero-touch
Retour au blog