Administration Guides

Hébergement

Localisation

Hébergé sur deux VMs, le cluster LDAP est localisé sur les serveurs technique.

Configuration Initiale

Dimensionnement

Les machines virtuelles LDAP sont composées de :

• CPU : 2
• RAM : 4Go
• Disque : 45G OS

Interfaces

Le composant LDAP offre un point d'accès au service LDAP (port 1636) sur le réseau Technique. Le protocole ldaps est utilisé.

La capacité des 2 machines virtuelles est exposée au travers d'un load-balancer HA Proxy (ldap.technique.artemis).

Fichiers de configuration

La consultation de la configuration doit s'effectuer par des commandes ldapsearch. En effet, la configuration est stockée dans une base à l'intérieur de l'annuaire (cn=config).

Logs

Les logs sont disponibles dans le répertoire suivant : /var/log/openldap/openldap.log

Binaires

Nom	Path	Description succincte
ldapsearch	/usr/bin	Outil de recherche du serveur ldap en CLI (ligne de commande)
ldapadd	/usr/bin	Outil d'ajout d'entrées sur le serveur ldap en CLI (ligne de commande)
ldapcompare	/usr/bin	Outil de comparaison du serveur ldap en CLI (ligne de commande)
ldapdelete	/usr/bin	Outil de suppression d'entrées sur le serveur ldap en CLI (ligne de commande)
ldapmodify	/usr/bin	Outil de modification (combinaison de ldapadd et ldapdelete) du serveur ldap en CLI (ligne de commande)

Combinaison de défaillance

• LDAP est déployé sur 2 VMs réparties sur deux serveurs pour en assurer la haute disponibilité ;
• Un loadbalancer permet de répartir le trafic entre les 2 instances.

Vérifier le bon fonctionnement

Statut du service LDAP

Exécuter la commande suivante pour obtenir le statut du service (sur chacun des nœuds):

sudo -u kosmosldap DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/777/bus systemctl status container-openldap --user

Le statut de ldap est active (running):

● container-openldap.service - Podman container-openldap.service
     Loaded: loaded (/opt/openldap/.config/systemd/user/container-openldap.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2025-05-14 09:52:33 UTC; 5min ago
       Docs: man:podman-generate-systemd(1)

Accéder au LDAP

Un administrateur infrastructure peut accéder aux VM LDAP depuis le bastion.

Le compte d'admin (COMPTE_ADMIN) et son mot de passe (PASS) sont dans le vault.

Réaliser une recherche sur le serveur LDAP

ldapsearch -xLLLD "cn=COMPTE_ADMIN,dc=artemis" -w "PASS" -b dc=artemis -H ldaps://ldap.technique.artemis

La recherche renvoie un résultat valable.

Exemple pour consulter un utilisateur métier :

ldapsearch -xLLLD "cn=COMPTE_ADMIN,dc=artemis" -w "PASS" -b uid=supervisdon,ou=utilisateurs,ou=metier,dc=artemis -H ldaps://ldap.technique.artemis
dn: uid=supervisdon,ou=utilisateurs,ou=metier,dc=artemis
userPassword:: e1NTSEE1MTJ9c3Z6NHJ3VlE4cmVHUTVQcW9xL3VDTzRsOUxVZWk4empna1pmT0t
 DYjBPMElTVDhpdkV5bWVUMmtaRHBuWnpiZnVKcHNTMmxKb3VqenZuUUxZNWh6SjVkRkZqaHJNcVg0
memberOf: cn=datascientist,ou=groupes,ou=metier,dc=artemis
memberOf: cn=supervisdon,ou=groupes,ou=metier,dc=artemis
pds: AXazSJuM8dXfE/MayibPO94spWpVL0KPv1ZZji9ZOvb93YUFTQ==
cn: superviseur
sn: data
mail: supervisdon@kosmos.fr
uid: supervisdon
objectClass: inetUser
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: inetOrgPersonWithPds
objectClass: top
objectClass: person

Mise à jour, suppression d'un groupe

Créer un fichier ldif ("group_to_delete.ldif") contenant les groupes à supprimer sous le format suivant :

Pour un rôle métier :

dn: cn=MYGROUPE,ou=groupes,ou=metier,dc=artemis
changetype: delete

ou pour un rôle technique :

dn: cn=GROUPE,ou=groupes,ou=primaire,ou=administrateurs,dc=artemis
changetype: delete

Puis lancer la commande :

ldapmodify -H ldaps://ldap.technique.artemis -D "cn=COMPTE_ADMIN,dc=artemis" -w "PASS" -f group_to_delete.ldif

Exemple :

ldapmodify -H ldaps://ldap.technique.artemis -D "cn=kosmosadmin,dc=artemis" -w "j0ge4C4Dg1fFhEbwaEGnNxxxxxxx" -f /tmp/group_to_delete.ldif

deleting entry "cn=ivvqpilotes,ou=groupes,ou=metier,dc=artemis"

Arrêter/Démarrer le service

Exécuter l'une des commandes ci-dessous suivant le besoin

sudo -u kosmosldap DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/777/bus systemctl stop container-openldap --user
sudo -u kosmosldap DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/777/bus systemctl start container-openldap --user
sudo -u kosmosldap DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/777/bus systemctl restart container-openldap --user

Sauvegarde\Restauration

Sauvegarde

Se connecter sur la vm ldap et exécuter les commandes suivantes:

export BACKUP_DIR="/path/to/backup_directory
mkdir -p $BACKUP_DIR
sudo su - kosmosldap -s /bin/bash -c "podman exec -it openldap slapcat -n 0 -F /opt/bitnami/openldap/etc/slapd.d" | tee $BACKUP_DIR/config.ldif
sudo su - kosmosldap -s /bin/bash -c "podman exec -it openldap slapcat -n 2 -F /opt/bitnami/openldap/etc/slapd.d" | tee $BACKUP_DIR/data.ldif

Les deux fichiers d'output sont créés sans erreur

head -n 5 $BACKUP_DIR/config.ldif
head -n 5 $BACKUP_DIR/data.ldif

Restauration

La procédure suivante décrit les commandes à réaliser pour restaurer la base LDAP

• Arrêter l'instance

• Supprimer le contenu de l'instance sudo rm -rf /opt/openldap/data/{data,slapd.d}

• Editer le fichier /opt/openldap/.config/systemd/user/container-openldap.service et ajouter à la suite des volumes --volume /opt/openldap/ldifs:/docker-entrypoint-initdb.d \

• Recharger le service sudo -u kosmosldap DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/777/bus systemctl --user daemon-reload

• Créer le fichier /opt/openldap/ldifs/restore.sh avec les droits d'execution. sudo touch /opt/openldap/ldifs/restore.sh && sudo chmod 755 /opt/openldap/ldifs/restore.sh

• Ajouter le contenu suivant

rm -rf /opt/bitnami/openldap/etc/slapd.d/{cn=config,cn=config.ldif}
slapadd -F slapadd -n 0 -F /opt/bitnami/openldap/etc/slapd.d -l /docker-entrypoint-initdb.d/config.ldif
slapadd -F slapadd -n 2 -F /opt/bitnami/openldap/etc/slapd.d -l /docker-entrypoint-initdb.d/data.ldif

• Copier les fichiers sous /opt/openldap/ldifs et appliquer les droits de lecture chmod a+r /opt/openldap/ldifs/{config,data}.ldif

• Recharger le service sudo -u kosmosldap DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/777/bus systemctl --user start container-openldap

• Tester que le restore a bien fonctionné en listant les utilisateurs après avoir adapté la commande avec le domaine de la plateforme:

ldapsearch -H "ldaps://127.0.0.1:2636" -D "cn=kosmosadmin,dc=kosmos" -W -b dc=kosmos -o TLS_REQCERT=never '(ObjectClass=inetOrgPerson)'

Répeter la procédure de restore sur la seconde instance.

• Supprimer les fichiers sous /opt/openldap/ldifs

La sauvegarde a été restaurée.

Vérification

Vérifier que les uidConfig et gidConfig sont bien présent dans le ldap

ldapsearch -H ldaps://ldap.technique.artemis:1636 -b dc=artemis -D "cn=kosmosadmin,dc=artemis" -W cn=uidConfig
ldapsearch -H ldaps://ldap.technique.artemis:1636 -b dc=artemis -D "cn=kosmosadmin,dc=artemis" -W cn=gidConfig

Récupérer le dernier uidNumber et gidNumber

LASTUID=$(ldapsearch -H ldaps://ldap.technique.artemis -b dc=artemis -D "cn=kosmosadmin,dc=artemis" -W |grep uidNumber | sort|tail -n 1|awk '{print $NF}')

LASTGID=$(ldapsearch -H ldaps://ldap.technique.artemis -b dc=artemis -D "cn=kosmosadmin,dc=artemis" -W |grep gidNumber | sort|tail -n 1|awk '{print $NF}')

Attention pour éviter les risques de doublons les configurations entre les 2 instances concernant cn=uidConfig et cn=gidConfig.

L'instance une à une valeur comprise entre 5000 et 10000 et l'instance 2 une valeur comprise entre 15000 et 20000.

Il faut donc modifier uidMax et gidMax en conséquence.

cat > /tmp/restore_uidgid.ldif << EOF
dn: cn=uidConfig,dc=artemis
uidNextValue: $LASTUID
uidMax: 10000
objectClass: uidNextConfig
cn: uidConfig

dn: cn=gidConfig,dc=artemis
gidNextValue: $LASTGID
gidMax: 10000
objectClass: gidNextConfig
cn: gidConfig
EOF

ldapadd -H ldaps://ldap.technique.artemis -D "cn=kosmosadmin,dc=artemis" -W -f /tmp/restore_uidgid.ldif

Synchronisation avec un annuaire extérieur

Procédure permettant de comprendre le fonctionnement du script de synchronisation des utilisateurs vers un LDAP externe.

Comprendre le fonctionnement

Le script a pour but de récupérer un groupe d'utilisateurs stockés dans un LDAP source et de recopier ces utilisateurs dans notre LDAP, pour cela il exécute un script python3 avec un fichier de propriétés qu'il faudra éditer pour aller chercher le groupe d'utilisateurs voulu.

Modifier les propriétés du script

Pour cela, vous devrez éditer le fichier de propriété voulu :

properties_admin.yml : pour synchroniser les admin properties_user.yml : pour synchroniser les utilisateurs

Les propriétés

EXT_ldap_url: "URL du ldap externe source -> str"

EXT_ldap_user: "utilisateurs LDAP externe source -> str"

EXT_ldap_password: "mot de passe LDAP externe source -> str"

EXT_ldap_base_dn: "le base dn du LDAP externe source -> str"

EXT_ldap_groups: "le chemin vers le CN du LDAP externe source -> str"

search_filter_group: "les filtres du LDAP externe source -> str"

EXT_ldap_groups_attribut: "attribut du LDAP externe source -> str"

ARTEMIS_ldap_url: "URL du ldap  destination -> str"

ARTEMIS_ldap_user: "utilisateurs LDAP  destination -> str"

ARTEMIS_ldap_password: "mot de passe LDAP  destination -> str"

ARTEMIS_ldap_base_dn: "le base dn du LDAP  destination -> str"

ARTEMIS_ldap_users: "le chemin vers le OU du LDAP destination -> str"

search_filter: "les filtres du LDAP destination -> str"

search_attribute: "les attributs recherché dans le LDAP externe source -> array"

log_file_name: "chemin vers le fichier de log du script -> path"

A moins d'une erreur visible dans les logs (par défaut dans : /var/log/syncsia/), nous devrions voir une copie entre les utilisateurs du groupe recherché vers l'OU du LDAP artemis.