Configurer l’authentification LDAP/AD avec GLPI 11

Saisir manuellement chaque utilisateur dans GLPI au moment de son arrivée et oublier de désactiver son compte au départ est l’une des sources de dette la plus classique d’un service desk. Brancher GLPI 11 sur l’annuaire d’entreprise — Active Directory côté Microsoft, OpenLDAP côté open source — résout le problème en quelques heures de paramétrage, et garantit que le couple identifiant/mot de passe utilisé par vos collaborateurs au quotidien fonctionne aussi sur le portail support.

Ce tutoriel détaille pas à pas la connexion d’une instance GLPI 11.0.7 à un Active Directory existant. La logique reste identique pour OpenLDAP : seuls les attributs et les filtres LDAP changent. Le guide de référence GLPI 11 helpdesk ITIL : déployer un service desk professionnel pose le contexte plus large dans lequel s’inscrit cette intégration.

Étape 1 — Pré-requis et collecte des informations annuaire

Avant de toucher GLPI, rassemblez les informations dont vous aurez besoin sur l’annuaire cible. Pour un AD typique :

• Le FQDN d’un contrôleur de domaine joignable depuis le serveur GLPI (par exemple dc01.exemple.lan)
• Le BaseDN du domaine (par exemple DC=exemple,DC=lan)
• Un compte de service en lecture seule, avec un mot de passe stable et un nommage explicite (par exemple svc-glpi-bind)
• Les OU ou groupes qui contiennent les utilisateurs à autoriser (par exemple OU=Personnel,DC=exemple,DC=lan)
• Le protocole utilisé : LDAP simple en port 389 pour la phase de test, LDAPS en port 636 pour la production

Côté serveur GLPI, vérifiez que le port 389 (ou 636) est joignable :

nc -zv dc01.exemple.lan 389
nc -zv dc01.exemple.lan 636

Les deux commandes doivent renvoyer open ou succeeded. Si elles échouent, le pare-feu ou la route réseau bloquent la connexion : aucun paramétrage GLPI ne pourra contourner ce point.

Vérifiez aussi que l’extension PHP LDAP est bien chargée — elle est dans les paquets recommandés mais pas dans les obligatoires :

php -m | grep -i ldap

Vous devez lire simplement ldap. Si rien ne sort, installez l’extension et redémarrez Apache :

sudo apt install -y php-ldap
sudo systemctl restart apache2

Étape 2 — Tester la connexion LDAP en ligne de commande

Avant de passer à l’interface graphique GLPI, validez que l’annuaire répond correctement avec ldapsearch :

sudo apt install -y ldap-utils
ldapsearch -x -H ldap://dc01.exemple.lan \
  -D "svc-glpi-bind@exemple.lan" \
  -W \
  -b "DC=exemple,DC=lan" \
  "(sAMAccountName=jdupont)" \
  cn mail sAMAccountName

Le mot de passe vous est demandé. La sortie doit contenir l’utilisateur ciblé avec ses attributs cn, mail, sAMAccountName. Si la requête échoue avec Invalid credentials, vérifiez le compte de service. Si elle échoue avec Can't contact LDAP server, c’est un problème réseau ou DNS.

Ce test prouve trois choses : le réseau passe, le compte de bind fonctionne, et le BaseDN est correct. Tant que ces trois preuves ne sont pas en main, n’allez pas plus loin.

Étape 3 — Déclarer l’annuaire dans GLPI

Connectez-vous à GLPI avec un compte super-admin, puis allez dans « Configuration » → « Authentification » → « Annuaires LDAP ». Cliquez sur le « + » pour ajouter un annuaire. Le formulaire propose un préréglage Active Directory qui pré-remplit les filtres et attributs spécifiques Microsoft :

• Nom : un libellé interne, par exemple « AD exemple.lan »
• Serveur par défaut : Oui (le premier annuaire déclaré devient celui par défaut)
• Actif : Oui
• Serveur : dc01.exemple.lan
• Port : 389 (passez à 636 + SSL une fois LDAPS testé)
• DN du compte : svc-glpi-bind@exemple.lan
• Mot de passe : celui du compte de service
• BaseDN : DC=exemple,DC=lan
• Filtre de connexion : (&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
• Champ de l’identifiant : samaccountname

Le filtre exclut automatiquement les comptes désactivés (bit 2 du userAccountControl). Sans ce filtre, un compte désactivé dans l’AD pourrait continuer à se connecter à GLPI tant que son cache n’expire pas.

Cliquez « Ajouter », puis « Tester » sur la fiche. GLPI tente une connexion bind et affiche « Test réussi » si tout va bien. En cas d’échec, l’erreur est explicite : mot de passe invalide, BaseDN inexistant, certificat TLS non vérifié.

Étape 4 — Importer les premiers utilisateurs manuellement

Avant d’automatiser l’import, faites une passe manuelle pour valider que le mapping fonctionne. Allez dans « Administration » → « Utilisateurs », cliquez « Liaison annuaire LDAP », puis « Importation depuis l’annuaire ». GLPI propose une recherche par sAMAccountName ou par cn. Tapez le nom d’un collaborateur connu, cochez-le, validez. L’utilisateur apparaît dans la liste GLPI avec ses attributs (nom, prénom, e-mail, téléphone si présent dans l’AD).

Tentez ensuite de vous connecter à GLPI avec le compte AD de cet utilisateur. La connexion doit fonctionner, et le profil par défaut « Self-Service » doit être appliqué. Si vous obtenez « Identifiant invalide », vérifiez le filtre de connexion et le champ d’identifiant. Si la connexion fonctionne mais l’utilisateur ne voit rien, c’est qu’aucun profil ou aucune entité n’est associé — l’étape suivante règle ce point.

Étape 5 — Mapper les groupes AD sur les profils GLPI

La règle d’or : ne configurez jamais les profils utilisateur un par un dans GLPI. Définissez plutôt des règles automatiques qui associent un groupe AD à un profil GLPI. Allez dans « Administration » → « Règles » → « Règles d’affectation d’une habilitation à un utilisateur ». Ajoutez une règle pour chaque correspondance :

Pour chaque règle, la condition est « Groupes utilisateur » contient le nom du groupe AD. L’action affecte un profil et une entité. Cochez « Recursive » sur l’entité racine pour que le profil descende dans toutes les sous-entités.

Cette logique offre trois avantages : un nouvel arrivant ajouté au bon groupe AD est immédiatement opérationnel sur GLPI au prochain login, un changement de rôle se gère dans l’AD sans toucher GLPI, et un départ se neutralise en désactivant simplement le compte AD.

Étape 6 — Synchronisation périodique automatique

L’import manuel ne tient pas la durée. GLPI propose une tâche automatique « LDAP_Synchronization » dans « Configuration » → « Actions automatiques ». Activez-la avec une fréquence de 1 heure ou 24 heures selon la dynamique de votre annuaire. La tâche fait deux choses : elle met à jour les attributs (e-mail changé, téléphone modifié) des utilisateurs déjà importés, et elle désactive dans GLPI les utilisateurs qui ne sont plus joignables dans l’annuaire (compte AD désactivé ou supprimé).

Pour l’import en masse d’utilisateurs qui ne se sont pas encore connectés à GLPI, lancez ponctuellement la commande console :

cd /var/www/glpi
sudo -u www-data php bin/console glpi:ldap:synchronize_users --ldap-server-id=1

L’option --ldap-server-id=1 cible le premier annuaire déclaré. La commande affiche un compte-rendu : utilisateurs importés, mis à jour, désactivés. Lancée manuellement la première fois, elle se planifie ensuite via cron pour les imports de masse hebdomadaires.

Étape 7 — Activer LDAPS pour la production

Tant que vous interrogez l’annuaire en LDAP simple (port 389), le mot de passe du compte de service transite en clair sur le réseau interne. Sur un réseau d’entreprise non maîtrisé de bout en bout, c’est une exposition inutile. Configurez LDAPS :

1. Récupérez le certificat racine de votre AD (généralement publié par l’Autorité de certification du domaine), placez-le dans /usr/local/share/ca-certificates/exemple-root.crt
2. Mettez à jour le magasin des autorités : sudo update-ca-certificates
3. Dans la fiche annuaire GLPI, passez le port à 636 et cochez « Utiliser SSL »
4. Cliquez « Tester » — la connexion doit fonctionner

Si le test échoue avec une erreur de certificat, vérifiez que le FQDN du serveur correspond bien au CN ou SAN du certificat AD. Pour un AD multi-DC, mieux vaut utiliser le nom du domaine (par exemple exemple.lan) qui résout via SRV records vers un DC disponible, plutôt que le FQDN d’un DC unique qui crée un point de panne.

Étape 8 — Gérer la résilience et les exceptions

Même un annuaire stable a ses pannes. Sans précaution, une coupure réseau ou un DC inaccessible bloque toutes les connexions GLPI. Trois garde-fous :

Premièrement, déclarez plusieurs serveurs annuaire dans GLPI. Le champ « Serveur » accepte une liste séparée par des virgules, GLPI bascule automatiquement sur le suivant en cas d’échec. En pratique, déclarez vos deux contrôleurs de domaine principaux.

Deuxièmement, conservez au moins deux comptes super-admin GLPI locaux (non-LDAP) avec mots de passe robustes, stockés dans un coffre-fort à part. Si l’annuaire tombe et qu’aucun admin local n’existe, vous perdez l’accès à votre service desk au moment où vous en avez le plus besoin.

Troisièmement, journalisez les imports LDAP. GLPI écrit ses logs dans /var/www/glpi/files/_log/event.log. Tailez-le lors d’un import pour repérer les imports manqués :

sudo tail -f /var/www/glpi/files/_log/event.log | grep -i ldap

Les lignes ldap_search returned an error ou Synchronisation impossible sont les signaux à suivre.

Étape 9 — Cas OpenLDAP au lieu d’Active Directory

Pour OpenLDAP, la procédure est strictement identique sauf trois ajustements dans la fiche annuaire :

• Le préréglage « OpenLDAP » remplace celui « Active Directory »
• Le champ d’identifiant devient uid au lieu de samaccountname
• Le filtre de connexion s’écrit (&(objectClass=inetOrgPerson)(!(uid=anonymous))) ou un équivalent selon votre schéma

Les étapes 2 à 8 (test ldapsearch, déclaration, import manuel, mapping groupes, sync automatique, LDAPS, résilience) s’appliquent telles quelles. Le seul piège récurrent : OpenLDAP ne propose pas l’attribut memberOf en standard. Activez l’overlay memberof côté serveur OpenLDAP pour que GLPI puisse récupérer les appartenances de groupe, sinon les règles d’affectation par groupe ne fonctionneront pas.

Erreurs fréquentes

Vérification et indicateurs

Une fois l’intégration en place, deux indicateurs valent le coup d’œil hebdomadaire :

• Le nombre d’utilisateurs GLPI marqués « actif » : doit correspondre au nombre de comptes AD actifs concernés par les règles d’import. Un écart de plus de 5 % signale un problème de synchronisation.
• Le nombre d’utilisateurs GLPI sans profil ni entité : devrait être nul. Une valeur supérieure signale qu’un nouvel arrivant n’est pas tombé dans une règle de mapping et qu’il faut ajouter le groupe AD manquant.

Pensez à automatiser la création des groupes AD dédiés GLPI dès la phase pilote : sans ces groupes, vos administrateurs cliquent profil par profil dans GLPI, ce qui ruine l’intérêt de l’intégration.

Articles associés

• GLPI 11 helpdesk ITIL : déployer un service desk professionnel
• Installer GLPI 11 sur Ubuntu Server 24.04 LTS
• Concevoir le schéma d’OU, comptes et groupes Active Directory pour une PME
• Auditer Active Directory : journaux, alerting et détection

Références

• Authentification GLPI — documentation officielle
• Active Directory Domain Services — Microsoft Learn
• OpenLDAP Administrator’s Guide

Synchronisation des photos de profil et attributs étendus

Au-delà des champs e-mail et téléphone, l’AD contient souvent une photo de profil (attribut thumbnailPhoto), un manager (manager), un service ou une fonction (department, title) et un lieu (physicalDeliveryOfficeName). GLPI peut les récupérer et enrichir les fiches utilisateur, ce qui rend l’expérience plus humaine côté technicien.

Dans la fiche annuaire LDAP, descendez jusqu’à la section « Liaison du contenu de l’utilisateur ». Ajoutez les attributs souhaités :

Lancez ensuite une synchronisation manuelle ciblée sur un utilisateur pour valider que les attributs remontent bien. La photo n’apparaît parfois qu’après vidage du cache navigateur — c’est normal, GLPI sert les images avec un long cache pour ne pas saturer la base.

Désactivation et purge des comptes obsolètes

Que se passe-t-il quand un utilisateur quitte l’organisation ? Idéalement, l’AD désactive immédiatement son compte (processus RH), la prochaine synchronisation LDAP de GLPI détecte que le compte n’est plus actif, et le marque comme désactivé. Ses tickets restent en historique, son nom apparaît toujours dans l’audit, mais il ne peut plus se connecter.

Configurez le comportement dans « Configuration » → « Authentification » → « Comportement par défaut pour les utilisateurs supprimés de l’annuaire » :

• Conserver — l’utilisateur est marqué supprimé en LDAP mais reste actif dans GLPI ; à éviter
• Désactiver — l’utilisateur ne peut plus se connecter, ses données restent ; recommandé pour les départs récents
• Mettre dans la corbeille — l’utilisateur disparaît des listes par défaut, restaurable ; recommandé après 6 à 12 mois
• Supprimer définitivement — perte de l’historique ; à proscrire en environnement audité

Une politique saine combine les deux derniers en deux temps : désactivation immédiate au départ, mise en corbeille un an plus tard une fois passée la période où l’on pourrait consulter ses anciens tickets.