NexTool Solutions

Nous avons connecté un Active Directory de laboratoire à un GLPI 11 : 7 utilisateurs importés en 1,4 seconde, chacun avec le bon profil selon son groupe AD et une connexion avec le mot de passe du réseau. Jusque-là, tout se passait comme prévu. Le problème est apparu lorsque nous avons désactivé un salarié parti dans l'AD : dans GLPI, il est resté actif, avec le même profil. Et modifier la configuration ensuite n'a rien résolu, car GLPI n'applique la règle de départ que la première fois qu'il constate la sortie.

Vous utilisez Microsoft Entra ID (Azure AD) et souhaitez une authentification unique dans le navigateur ? Consultez SSO avec Microsoft Entra ID dans GLPI. Cet article porte sur l'AD local, via LDAP.

Ce que fait l'intégration avec l'AD

• Connexion avec le mot de passe du réseau : l'utilisateur se connecte à GLPI avec le même identifiant et le même mot de passe que sous Windows. Le mot de passe n'est jamais stocké dans GLPI.
• Import des données : nom, prénom, e-mail, téléphone, fonction et d'autres champs proviennent de l'AD.
• Profil par groupe : les règles d'habilitation attribuent le profil et l'entité selon le groupe AD (technicien, responsable, utilisateur).
• Synchronisation : les changements dans l'AD, comme un changement de téléphone, de fonction ou un départ, arrivent dans GLPI par la synchronisation planifiée.

Le laboratoire

Nous avons monté un contrôleur de domaine Samba (compatible Active Directory) avec le domaine ACME.TEST, l'entreprise fictive Acme, trois groupes (GLPI-Tecnicos, GLPI-Gestores, GLPI-Usuarios) et huit utilisateurs : sept actifs et un désactivé dans une OU des départs. De l'autre côté, un GLPI 11.0.7 de test.

Étape 1 : l'annuaire LDAP

Dans Configuration > Authentification > Annuaires LDAP :

Le bouton Tester vérifie la connexion avant d'importer quoi que ce soit.

Étape 2 : le profil selon le groupe AD

Dans Administration > Règles > Règles d'affectation d'habilitations à un utilisateur, une règle par groupe :

Les habilitations attribuées par règle sont dynamiques : si la personne quitte le groupe dans l'AD, le profil est retiré à la synchronisation suivante.

Étape 3 : importer et synchroniser

Depuis l'écran (Importer de nouveaux utilisateurs) ou en ligne de commande, ce qui est nécessaire pour planifier :

php bin/console ldap:synchronize_users --ldap-server-id=1 --deleted-user-strategy=1,0,1

Dans le laboratoire, l'import a ramené les 7 utilisateurs actifs en 1,4 seconde, et le compte désactivé a été écarté par le filtre. Le nom, l'e-mail et le téléphone sont venus de l'AD, et chacun a reçu le profil de son groupe. La connexion avec le mot de passe AD a fonctionné, et avec un mauvais mot de passe elle a été refusée.

Ce qui s'est passé quand nous avons désactivé un salarié parti

Nous avons désactivé un utilisateur dans l'AD et lancé la synchronisation, d'abord avec la configuration par défaut.

Deux conclusions :

1. Par défaut, GLPI ne fait rien pour ceux qui quittent l'AD (stratégie "0,0,0"). Un ancien salarié conserve un compte actif dans GLPI jusqu'à ce que quelqu'un s'en aperçoive.
2. La stratégie s'applique au moment où GLPI détecte la sortie. Si la première synchronisation a tourné avec la valeur par défaut, modifier la configuration ensuite ne rattrape pas ceux qui ont déjà été marqués. Il faut traiter ces utilisateurs à la main.

Configurez l'action pour les utilisateurs supprimés du LDAP avant la première synchronisation (dans Configuration > Authentification, ou avec --deleted-user-strategy dans la commande). La combinaison que nous recommandons est "1,0,1" : désactiver le compte, conserver les groupes (pour l'historique) et retirer les habilitations dynamiques.

Pour le retour, la stratégie de restauration "3" réactive le compte lorsque la personne est réactivée dans l'AD.

Un détail sur le profil par défaut

Tous les utilisateurs importés ont aussi reçu le profil par défaut de GLPI (dans notre cas, Self-Service), en plus du profil de la règle. Pour les techniciens, cela ne gêne pas, mais il apparaît lors du changement de profil. Si vous n'en voulez pas, vérifiez quel est le profil par défaut de GLPI avant d'importer.

Checklist

1. Compte de service en lecture seule pour le RootDN.
2. LDAPS ou StartTLS en production.
3. BaseDN à l'OU des personnes et filtre qui exclut les comptes désactivés.
4. objectguid comme champ de synchronisation.
5. Règles d'habilitation par groupe AD, avec une entité définie.
6. Action pour les utilisateurs supprimés du LDAP configurée avant la première synchronisation ("1,0,1").
7. Synchronisation planifiée (cron) avec ldap:synchronize_users, au moins quotidienne.
8. Test avec un utilisateur fictif : le créer, changer son groupe, le désactiver et le réactiver dans l'AD, et vérifier GLPI à chaque étape.

Besoin d'aide pour l'intégration ou pour l'audit des accès ? Parlez à l'équipe. Pour comprendre les profils et les droits, consultez profils et droits dans GLPI.

Test NexTool du 4 octobre 2026 : contrôleur de domaine Samba (compatible Active Directory) avec des utilisateurs fictifs et un GLPI 11.0.7 de test. Le laboratoire a été supprimé à la fin. Comportement de la synchronisation vérifié dans la commande de GLPI elle-même.