Réplication LDAP

Un peu de théorie

Le but de ce document est de présenter les mécanismes de réplication LDAP et de proposer une méthode de mise en oeuvre dans le cas d’une réplication, sans SSL, d’un annuaire LDAP.

Le principe est en fait très simple :

Sur le maître :

Un daemon supplémentaire (slurpd), surveille en permanence les modifications apportées à la base LDAP et consigne ces modifications dans des fichiers de réplica.

En permanence, slurpd tente de mettre à jour l’esclave à partir du fichier de replica.

Pour cela, il se connecte au serveur slapd de l’esclave avec un compte autorisé à modifier l’esclave. Si l’esclave n’est pas disponible les informations sont consignées dans des fichiers de ’rejeu’, et une nouvelle tentative sera effectuée ultérieurement.

Le compte utilisé par slurpd pour modifier l’esclave doit être un compte LDAP ( une ’person’ ) existant sur l’esclave, et disposant des droits d’écriture sur la totalité de la base. On n’utilisera pas le compte Manager, mais un nouveau compte spécifique (Replicator).

Sur l’esclave

Après avoir initialisé la base LDAP de l’esclave à partir du contenu de la base maître, OpenLdap ne se comporte pas comme un serveur Ldap ordinaire. Des directives indiquent qu’il ne peut être mis à jour seulement que par le maître.

L’esclave n’acceptera que les mises à jour en provenance du maître qui se connecte avec le compte prévu à cet effet (Replicator ). Si une tentative de mise à jour est effectuée par un autre client, l’esclave renvera un ’Referral’ indiquant au client le serveur maître à contacter pour la mise à jour. Si le client prend le prend en compte, les modifications seront alors renvoyées au maître. Le maître sera alors mis à jour et slurpd répercutera les modifications sur l’esclave. Si le maître est stoppé à ce moment là, les modifications ne seront pas appliquées à l’esclave ( ni au maître à fortiori )

A ma connaissance ; seul le client ’LdapBrowserEditor en Java’, prend en compte les referrals renvoyés par le serveur esclave.

Samba 3 prend également en charge la retransmission des referrals vers le maître.

• Mise à jour via le Maître

• Mise à jour via l’Esclave

Prérequis

Serveurs

Le serveur esclave doit être physiquement sur une autre machine que le serveur maître. Il n’est pas possible de faire de la réplication d’une base LDAP sur le même serveur que la base principale – de toutes manières cela n’a aucun intérêt.

De plus, le type de backend utilisé doit être identique ainsi que la version majeure d’OpenLdap.

Pour la manipulation il est vivement conseillé de travailler à partir d’un poste tierce ( Windows) dans des fenêtres SSH ( Putty ) de manière à avoir accès aux 2 serveurs.

Les commandes à taper sont de la forme, quand elles sont à faire sur le maître :

• (maître) commande maître

et

• (esclave) commande esclave

quand elles sont à effectuer sur l’esclave.
Pour cet exposé, l’annuaire à répliquer à pour racine :
ou=ddsv44, ou=agriculture, o= gouv, c=fr

Les adresses IP sont 10.44.180.1 pour le maître, 10.44.180.6 pour l’esclave.

Vérifier la synchronisation des heures des 2 serveurs ( ceci est très important ).

Préparation

Préparation de l’esclave

Nous avons besoin de OpenLdap et des schémas nécessaires aux classes d’objet ldap gérées( NIS, samba, etc, … ).

Création d’un compte ’Replicator’ sur le maitre

Un compte ’Replicator’ doit être créé sur le maître, avant la copie de la base ldap sur l’esclave. Ce compte sera utilisé par le maître pour mettre à jour l’esclave. Il n’a pas d’utilité sur le maître , mais
comme nous voulons une réplication parfaite des 2 bases, il est préférable de le créer maintenant.

Pour créer ce compte, utiliser un client LDAP (ici LDAP Browser – Java) :

Ici le mot de passe sera ’replicatorpasswd’, il est crypté en SHA, mais ça n’a pas d’importance.

Les attributs cn,sn et userPassword sont suffisant. Le compte est créer directement sous la racine de
l’annuaire.

Configuration

Configuration du maître

Il faut maintenant configurer les services slapd et slurpd sur le maître pour que celui ci agisse en tant que tel. Cette configuration se fait dans le fichier /etc/openldap/slapd.conf :

Les directives suivantes sont à ajouter :

• replogfile : fichier de réplication. C’est ce fichier qui est utilisé par slurpd pour la réplication.
• replica : directive de compte de réplication. Ces informations seront utilisées par le maître pour
• contacter et mettre à jour l’esclave :
• host : adresse IP et port ldap de l’esclave
• binddn = compte à utiliser pour mettre à jour l’esclave.
• bindmethod = methode de cryptage et mot de passe du compte de réplication.

ATTENTION : le mot de passe doit être en clair dans ce fichier (methode = simple)

La directive ’replica’ comprend les arguments host, binddn et bindmethod. Si vous passez une ligne entre les arguments assurez vous qu’il y ai au moins un espace en début de ligne .

Effectuer la copie des fichiers du maître sur l’esclave

Tout d’abord, copier le fichier slapd.conf, après avoir stoppé OpenLdap sur l’esclave

• (esclave) service ldap stop

….(changez de console !! )

•  (maitre) scp /etc/openldap/slapd.conf root@10.44.180.6 :/etc/openldap/copiePDC/slapd.conf

Faites ensuite un export de la base LDAP du maître sur l’esclave. Il est nécessaire de stopper le
maître à ce moment pour éviter des problèmes d’intégrité de la base.

• (maitre) service ldap stop
• (maitre) slapcat -l /tmp/maitre.ldif
• (maitre) scp /tmp/maitre.ldif  root@10.44.180.6 :/etc/openldap/copiePDC/maitre.ldif

Redémarrer ensuite openldap sur le mâitre :

• (maitre) service ldap start

Remarquer que le service slurpd démarre également, du aux directives que nous venons d’ajouter.

Configurer l’esclave

Remplacer le fichier slapd.conf de l’esclave par celui du maître. ( faites un copie de l’ancien fichier si
besoin ).

• (esclave) cd /etc/openldap
• (esclave) mv slapd.conf slapd.old
• (esclave) cp copiePDC/slapd.conf slapd.conf

Commenter les lignes de réplication ajoutées précédemment :

Modifier la directive ACL pour donner les droits au compte Replicator de modifier l’esclave.

Indiquer également l’adresse du maître et le compte qu’il utilisera (Replicator ), pour modifier l’esclave

Importer la base sur l’esclave.

• (esclave) cd /etc/openldap
• (esclave) slapadd -l copiePDC/maitre.ldif

Vérifier les droits d »écriture et de lecture dans le répertoire /var/lib/ldap qui doivent être positionnés
pour le compte ’ldap’. A défaut, faire :

• (esclave) chown -R ldap:ldap /var/lib/ldap/*

Démarrer l’esclave

• (esclave) service ldap start

Test de fonctionnement

Pour tester la réplication , vous pouvez lancer 2 sessions de client LDAP, une sur le maître et l’autre sur l’esclave, toutes 2 connectées en tant que Manager.

Test de la modification du maître

Modifier un attribut d’une entrée du maître, la modification doit se répercuter sur l’esclave

Créer une nouvelle entrée sur le maître

Supprimer l’entrée à partir du maître

Test de la modification de l’esclave ( ldapBrowserEditor seulement) :

Si l’esclave est directement modifié, avec un compte autre que Replicator, la modification sera d’abord appliquée au maître avec ce même compte. Si elle réussie , c’est seulement ensuite que l’esclave sera modifié par le maître .

Cette configuration évite toute modification de l’esclave , quand le maître est stoppé. ( ce qui est bien le rôle d’un esclave ). Mais autorise cependant les modifications sur l’esclave ( via le maître ) quand le maître est en fonction quand le client est adapté pour cela.

Test de modification avec un client SAMBA

Utiliser le client SAMBA, USRMGR, pour modifier la base LDAP du maître

et vérifier sur l’esclave

---

Merci à mon ami Jean-Luc qui est à l’origine de cette doc.