Activité Réplication et synchronisation de serveurs d'annuaire

EPAI , () — CC BY-NC-SA

Consigne

  1. Avant de commencer l’activité :
    • Lire la mise en situation, prendre connaissance des objectifs, du résultat attendu, et des ressources à disposition.
    • Lire une première fois en entier la section Mise en route.
  2. Effectuez le travail décrit dans la section Mise en route et effectuez les tâches demandées dans la section Tâches.

Mise en situation

Votre équipe est chargée de centraliser l’authentification des utilisateur·rice·s sur les serveurs Linux et les applications Web. Après une phase d’analyse, il a été décidé de mettre en place un système d’annuaire à haute disponibilité avec OpenLDAP. Actuellement, le système d’annuaire se compose d’un unique serveur et une machine Linux utilise cet annuaire pour authentifier les utilisateur·rice·s du système. Toutefois, pour assurer la disponibilité du service d’annuaire en cas de panne ou lors de la maintenance, il est nécessaire d’avoir au moins deux serveurs LDAP. Vous recevez donc la tâche d’installer un second serveur d’annuaire puis de modifier leur configuration de manière à ce que leur contenu soit synchronisé.

Objectifs

À la fin de ce travail, en ayant accès au web, vous devez :

  1. Être capable d’expliquer ce qu’est la réplication dans le contexte des serveurs d’annuaire.
  2. Être capable de configurer un serveur OpenLDAP
  3. Être capable de configurer une synchronisation «provider-consumer» entre les deux serveurs.
  4. Être capable de configurer une synchronisation «multiprovider» entre deux serveurs (miroir).
  5. Connaître les cas d’usage et les limites des deux types de configurations.

Résultat attendu

  • Un rapport qui comprend :
    • Une marche à suivre permettant l’installation et la configuration de OpenLDAP.
    • Les réponses aux questions
  • Une machine virtuelle Linux (Ubuntu server 22.04) avec OpenLDAP configuré.

Ressources

Matériel:

  • Un serveur Linux avec Ubuntu server 22.04 (avec OpenLDAP installé):
    • le nom complet est svr-m159-$NUM-ldap-01.lab.epai-ict.ch ($NUM est le numéro du réseau sur deux ou trois chiffres, en initialisant une variable d’environnement NUM, les commandes peuvent être exécutées telles quelles).
    • le nom d’utilisateur·rice est admin
    • les informations d’indentification se trouvent sur la fiche que vous avez reçu par courriel.
  • Un serveur Linux avec Ubuntu server 22.04 :
    • le nom complet est svr-m159-$NUM-ldap-02.lab.epai-ict.ch ($NUM est le numéro du réseau sur deux ou trois chiffres, en initialisant une variable d’environnement NUM, les commandes peuvent être exécutées telles quelles).
    • le nom d’utilisateur·rice est admin
    • les informations d’indentification se trouvent sur la fiche que vous avez reçu par courriel.

Remarque: Toutes les machines se trouvent dans l’état dans lequel elles auraient dû à la fin de l’activité précédente. Tout le monde part donc du même point.

Mise en route

Pour ce travail, vous disposez de trois machines:

  • La première (svr-m159-##-ldap-01) est un serveur d’annuaire (DSA) qui contient les comptes d’utilisateur·rice·s de l’entreprise.
  • La deuxième (svr-m159-##-ldap-02) est un serveur d’annuaire dont la configuration est identique au premier, mais qui ne contient rien.
  • Enfin, la troisième (svr-m159-##-01) est une machine Linux qui utilise le service d’annuaire pour authentifier les utilisateur·rice·s du système.

Vérification du système

Avant de débuter, assurons-nous que tout fonctionne correctement en nous connectant avec SSH en tant que admin sur la machine Linux (svr-m159-##-01 où ## est le numéro de votre machine). Pour cela, définissez une variable NUM avec le numéro de la machine qui figure sur la fiche de connexion que vous avez reçue (p. ex. NUM=42), puis lancez la commande ci-après et saisissez le mode de passe si vous y êtes invité (le cas échéant, pensez à copier votre clé SSH publique sur cette machine).

1

ssh admin@svr-m159-$NUM-01.lab.epai-ict.ch
Fig. 1 – Connexion au système Linux

Lorsque vous êtes connecté en tant que admin, lancez la commande suivante pour vous assurer que l’authentification à l’aide du serveur d’annuaire fonctionne correctement.

1

sudo -u bornetj bash -c "whoami && sudo whoami"

1
2

bornetj
root
Fig. 2 – Test d'authentification LDAP et résultat attendu

Vous pouvez également essayer d’ouvrir une nouvelle session en tant que bornetjtruc, largeys ou n’importe quel autre compte d’utilisateur·rice de l’annuaire, avec la commande sudo login (tous les comptes de l’annuaire ont le même mot de passe: epai123).

Vérifions encore que les deux serveurs LDAP fonctionnent. Pour cela, lancez les deux commandes ci-après. La première récupère les données de la base de données principale du premier serveur (svr-m159-##-ldap-01) et renvoie le nombre d’entrées qu’elle contient. Elle devrait contenir 25 entrées. La seconde commande fait la même chose pour la base de données principale du second serveur (svr-m159-##-ldap-02). Elle ne devrait contenir que deux entrées.

1
2
3
4
5
6
7
8

ldap_server_01=ldaps://svr-m159-$NUM-ldap-01.lab.epai-ict.ch
ldap_server_02=ldaps://svr-m159-$NUM-ldap-02.lab.epai-ict.ch

ldapsearch -x -H $ldap_server_01 -b dc=lab,dc=epai-ict,dc=ch \
    | grep numResponses | awk '{ print "Server 1: " $3 }'

ldapsearch -x -H $ldap_server_02 -b dc=lab,dc=epai-ict,dc=ch \
    | grep numResponses | awk '{ print "Server 2: " $3 }'

1
2

25
2
Fig. 3 – Test des serveurs LDAP et résultat attendu

Lorsque vous avez effectué vos vérifications, revenez dans la session admin et restez-y pour effectuer le reste de ce travail.

Qu’est-ce que la réplication ?

D’une manière générale, la réplication est un processus qui implique un serveur principal souvent appelé fournisseur (producer) et un ou plusieurs serveurs secondaires souvent appelés consommateurs (consumer). Ce processus permet aux serveurs consommateurs d’obtenir et de maintenir une copie conforme des données du serveur fournisseur. Seul le serveur fournisseur gère les requêtes d’ajout et de modification. Les serveurs consommateurs gèrent uniquement les requêtes de lecture. Cette configuration est utilisée pour la haute disponibilité et la répartition de charge des serveurs consommateurs. Elle permet en outre d’optimiser les index des serveurs consommateurs pour la lecture et ceux du serveur fournisseur pour l’écriture.

Il est également possible de mettre en œuvre une réplication multi-fournisseur (multi-provider) entre plusieurs serveurs. Cette configuration est utilisée pour la haute disponibilité des serveurs fournisseur. La réplication ne permet pas la répartition de charge pour les requêtes d’ajout et de modification. En effet, même si chaque serveur fournisseur ne traite qu’une partie des requêtes d’ajout et de modification, chaque opération d’écriture sur l’un des serveurs fournisseurs doit être propagée sur tous les autres. Ainsi, chaque serveur se retrouve avec une charge similaire à celle qu’il aurait eue s’il avait traité l’ensemble des requêtes.

Les deux types de réplication peuvent être combinés pour avoir à la fois une haute disponibilité des serveurs fournisseur et une haute disponibilité et une répartition de charge des serveur consommateur. Encore une fois, la réplication ne permet pas la répartition de charge des serveurs fournisseurs. Sans entrer dans les détails, pour répartir la charge des serveurs fournisseurs, nous pouvons avoir recours à différentes techniques de sharding qui consistent à partitionner les données pour les répartir dans plusieurs bases de données. Toutefois, dans le cas de serveur d’annuaire, les requêtes d’ajout et de modification ne représentent qu’une petite partie de la charge et peuvent le plus souvent être gérées par un unique serveur.

OpenLDAP supporte la réplication fournisseur-consommateur (producer-consumer) avec un fournisseur unique et de multiples consommateurs, et la réplication multi-fournisseur (multi-provider) à l’aide du module LDAP Sync Replication (syncrepl). Ce module est inclus dans la distribution que nous utilisons, il n’y a donc rien à installer.

Remarque: Cette activité ne concerne que la réplication. La mise en œuvre de la haute disponibilité fera l’objet d’une prochaine activité, et la répartition de charge ne sera abordée que de manière théorique.

Tâche

Réplication fournisseur-consommateur

Nous allons tout d’abord configurer le premier serveur (svr-m159-##-ldap-01) comme fournisseur et le second (svr-m159-##-ldap-02) comme consommateur. Dans cette configuration, seul le premier serveur gère les requêtes d’ajout et de modification. Le second serveur ne gère que les requêtes de lecture.

Configuration du consommateur

Commençons par configurer le serveur fournisseur (svr-m159-##-ldap-01). Pour cela, nous allons réaliser les actions suivantes:

  1. Créer un compte d’utilisateur pour la réplication (cn=replicator,dc=lab,dc=epai-ict,dc=ch)
  2. Ajuster les permissions de l’utilisateur replicator.
  3. Charger le module syncprov.
  4. Configurer le module syncprov pour la base de données principale (olcDatabase={1}mdb,cn=config).

Pour créer le compte d’utilisateur·rice, nous devons ajouter une dans la base de données principale avec l’utilisateur cn=admin,dc=lab,dc=epai-ict,dc=ch (mot de passe Epai123). La figure 4 présente la description de l’entrée au format LDIF et la commande à exécuter pour l’ajouter.

1
2
3
4
5
6
7

# Contenu du fichier repl-user.ldif
dn: cn=replicator,dc=lab,dc=epai-ict,dc=ch
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
description: Replication user
userPassword: {SSHA}+3+EBcmZ+i2jGvVDLgB9b0wnPAGVyMlZ

1
2
3

ldapadd -x -H ldaps://svr-m159-$NUM-ldap-01.lab.epai-ict.ch \
    -D cn=admin,dc=lab,dc=epai-ict,dc=ch -w 'Epai123' \
    -f repl-user.ldif
Fig. 4 – Création de l'utilisateur replicator

Pour la suite de la configuration, nous devons ouvrir une session SSH sur le premier serveur svr-m159-##-ldap-01, car les modifications doivent être apportées à la base de données de configuration à l’aide de l’utilisateur root avec la commande sudo. Lancez la commande ci-dessous pour établir la connexion.

1

ssh svr-m159-$NUM-ldap-01
Fig. 5 – Ouvrir une session SSH sur le premier serveur LDAP

Une fois la connexion établie, commencez par ajuster les permissions de l’utilisateur replicator. L’utilisateur replicator doit disposer d’un accès en lecture seule, sans restrictions de taille ou de durée, à l’ensemble des données de la base de données principale. La figure 6 présente la description LDIF de la modification à apporter, ainsi que la commande à exécuter pour l’appliquer.

1
2
3
4
5
6
7
8
9
10
11
12

# Contenu du fichier repl-user-perm.ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to *
  by dn.exact="cn=replicator,dc=lab,dc=epai-ict,dc=ch" read
  by * break
-
add: olcLimits
olcLimits: dn.exact="cn=replicator,dc=lab,dc=epai-ict,dc=ch"
  time.soft=unlimited time.hard=unlimited
  size.soft=unlimited size.hard=unlimited

1

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f repl-user-perm.ldif
Fig. 6 – Modifier les permissions

Pour achever la configuration du fournisseur, nous devons encore charger le module syncprov et le configurer. Pour cela il faut effectuer les modifications suivantes:

  1. Ajouter la valeur syncprov à l’attribut olcModuleLoad de l’entrée cn=module{0},cn=config pour indiquer que le module syncprov doit être chargé.
  2. Ajouter l’entrée olcOverlay=syncprov,olcDatabase={1}mdb,cn=config. Cette entrée contient la configuration du module syncprov et indique au serveur qu’il agit en tant que fournisseur (provider).

La figure 7 montre la description de la modification et la commande à exécuter pour l’appliquer.

1
2
3
4
5
6
7
8
9
10
11
12
13

# Contenu du fichier syncprov-config.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionLog: 100

1

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f syncprov-config.ldif
Fig. 7 – Charger et configurer le module sysprov

La configuration du serveur fournisseur est désormais achevée. Il ne nous reste plus qu’à configurer le serveur consommateur (svr-m159-##-ldap-02). Pour ce faire, vous devez interrompre la connexion SSH avec le premier serveur LDAP et établir une nouvelle connexion SSH avec le second serveur (svr-m159-##-ldap-02).

Configuration du consommateur

Lorsque la connexion SSH est établie avec le serveur svr-m159-##-ldap-02, vous devez ajouter l’attribut olcSyncRepl à l’entrée de la base de données de configuration qui décrit la base de données principale (olcDatabase={1}mdb,cn=config). Cet attribut informe le serveur qu’il agit en tant que consommateur (consumer) et fournit les informations requises pour obtenir les données du serveur fournisseur. Nous pouvons facilement identifier les informations de connexion (URI du fournisseur (provider), DN du compte d’utilisateur et mot de passe, base de la recherche). La propriété type=refreshAndPersist implique que la réplication doit se dérouler à intervalles réguliers (pull) et sur notification du fournisseur (push) tandis que l’option alternative type=refreshOnly correspond à une réplication à intervalles réguliers uniquement. La propriété retry="60 +" signifie qu’en cas d’échèque, la réplication doit être retentée indéfiniment (+) toutes les 60 secondes. La propriété rid définit l’identifiant unique du répliqua (un entier à trois chiffres) pour chaque consommateur au sein d’un groupe de serveurs.

L’attribut olcUpdateRef ne s’applique qu’à un serveur consommateur et permet au serveur de renvoyer l’URI du serveur fournisseur auquel il se réfère en réponse à une requête d’ajout ou de modification.

La figure 8 montre la description LDIF des modifications à apporter et la commande à exécuter pour les appliquer. Attention: n’oubliez pas de remplacer ## par le numéro de votre serveur.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Contenu du fichier syncrepl-config.ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl:
  rid=002
  provider=ldap://svr-m159-##-ldap-01.lab.epai-ict.ch
  bindmethod=simple
  binddn="cn=replicator,dc=lab,dc=epai-ict,dc=ch"
  credentials=Epai123
  searchbase="dc=lab,dc=epai-ict,dc=ch"
  schemachecking=on
  type=refreshAndPersist
  retry="60 +"
  starttls=critical
  tls_reqcert=demand
-
add: olcUpdateRef
olcUpdateRef: ldap://svr-m159-##-ldap-01.lab.epai-ict.ch

1

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f syncrepl-config.ldif
Fig. 8 – Configurer le consommateur

La configuration de la réplication est maintenant terminée et vous pouvez interrompre la connexion SSH avec le serveur consommateur.

Vérification

Vérifiez que la réplication fonctionne correctement en exécutant une nouvelle fois les commandes de la figure 3. Les deux serveurs devraient maintenant avoir le même nombre d’entrées. Ajoutez un compte d’utilisateur·rice dans le premier serveur (svr-m159-##-ldap-01.lab.epai-ict.ch) et vérifiez une nouvelle fois que les deux serveurs contiennent le même nombre d’entrées.

Si cela ne fonctionne pas, utiliser la commande de figure 9 sur chacun des serveurs LDAP pour vérifier leur configurations respetive. Demandez de l’aide en cas de besoin.

1
2

sudo ldapsearch -Y EXTERNAL -H ldapi:/// -LLL \
    -b cn=config '(!(objectclass=olcSchemaConfig))
Fig. 9 – Afficher la configuration du server OpenLDAP

Questions

Répondez aux questions suivantes:

  1. À quoi sert le compte d’utilisateur replicator que vous avez créé à la première étape? Où est-il utilisé?
  2. Quels sont les droits de cet utilisateur?
  3. Afficher la configuration du serveur fournisseur (voir fig. 9). Quelle entrée indique que ce serveur est un fournisseur (provider)?
  4. Afficher maintenant la configuration du serveur consommateur. Quel attribut de la base de données principale (olcDatabase={1}mdb,cn=config) indique que le serveur est un consommateur (consumer)? Décrivez brièvement la valeur de cet attribut.
  5. À quoi sert l’attribut olcUpdateRef? Que se passe-t-il si vous essayez d’ajouter un utilisateur dans le second serveur (svr-m159-##-ldap-02.lab.epai-ict.ch)?
  6. Dans la réplication des bases de données, les termes provider et consumer remplacent les termes master et slave. Pourquoi n’utilise-t-on plus ces dernier?

Réplication multi-fournisseur

Pour configurer la réplication multi-fournisseur (multi-provider) entre les deux serveurs, il faut effectuer les opérations suivantes:

  1. Ajouter les permissions de l’utilisateur de réplication dans le second serveur.
  2. Configurer le second serveur en tant que fournisseur.
  3. Supprimer l’attribut olcUpdateRef dans le second serveur.
  4. Configurer le premier serveur en tant que consommateur.
  5. Ajouter l’attribut olcMultiProvider: TRUE dans les deux serveurs.

Configuration du second serveur

Établissez une connexion SSH avec le second serveur (svr-m159-##-ldap-02). La figure 10 montre les modifications à réaliser pour ajuster les permissions de l’utilisateur replicator dans la base de données principale de ce serveur.

1
2
3
4
5
6
7
8
9
10
11
12

# Contenu du fichier repl-user-perm.ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to *
  by dn.exact="cn=replicator,dc=lab,dc=epai-ict,dc=ch" read
  by * break
-
add: olcLimits
olcLimits: dn.exact="cn=replicator,dc=lab,dc=epai-ict,dc=ch"
  time.soft=unlimited time.hard=unlimited
  size.soft=unlimited size.hard=unlimited

1

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f repl-user-perm.ldif
Fig. 10 – Modifier les permissions

En restant connecté au second serveur (svr-m159-##-ldap-02), référez-vous maintenant à la figure 11 pour ajouter le chargement et la configuration du module syncprov, supprimer l’attribut olcUpdateRef et ajouter l’attribut olcMultiProvider

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Contenu du fichier multiprov-config.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionLog: 100

dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcUpdateRef
-
add: olcMultiProvider
olcMultiProvider: TRUE

1

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f multiprov-config.ldif
Fig. 11 – Modification de la configuration du second serveur pour la réplication multi-provider.

Affichez la configuration du serveur (voir fig. 9) et vérifiez que vous y trouvez bien toutes les modifications. Assurez-vous en particulier que l’attribut olcUpdateRef a bien été supprimé.

Configuration du premier serveur

Fermez la connexion SSH avec le second serveur et établissez une nouvelle connexion avec le premier serveur (svr-m159-##-ldap-02), puis référez-vous à la figure 12 pour configurer le premier serveur également en tant que consommateur. Attention: assurez-vous de remplacer ## par le numéro de votre serveur.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Contenu du fichier syncrepl-config.ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl:
  rid=001
  provider=ldap://svr-m159-##-ldap-02.lab.epai-ict.ch
  bindmethod=simple
  binddn="cn=replicator,dc=lab,dc=epai-ict,dc=ch"
  credentials=Epai123
  searchbase="dc=lab,dc=epai-ict,dc=ch"
  schemachecking=on
  type=refreshAndPersist
  retry="60 +"
  starttls=critical
  tls_reqcert=demand
-
add: olcMultiProvider
olcMultiProvider: TRUE

1

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f syncrepl-config.ldif
Fig. 12 – Configurer le consommateur

Vérifiez la configuration du premier serveur.

Vérification

Vérifiez que la réplication fonctionne correctement en effectuant au moins une fois la procédure suivante:

  1. Ajoutez un compte d’utilisateur·rice dans le premier serveur (svr-m159-##-ldap-01.lab.epai-ict.ch) et exécutez les commandes de la figure 3. Les deux serveurs devraient maintenant avoir le même nombre d’entrées.
  2. Ajoutez un compte d’utilisateur·rice dans le second serveur (svr-m159-##-ldap-02.lab.epai-ict.ch) et assurez-vous une nouvelle fois que les deux serveurs contiennent le même nombre d’entrées.

Questions

Répondez aux questions suivantes:

  1. Expliquez en quelques mots ce qu’est la réplication multi-fournisseur.
  2. Expliquez pourquoi la réplication multi-fournisseur est utile pour la haute disponibilité, mais pas pour la répartition de charge dans le cas des requêtes d’ajout et de modification?
  3. Que faut-il faire pour activer la réplication multi-fournisseur? Quelles sont les différences entre la configuration du premier et celle du second serveur?