Ce que l'annuaire change
Sans annuaire, chaque utilisateur a un compte GLPI local, créé à la main, avec un mot de passe de plus à retenir et à réinitialiser. Le service support passe une part mesurable de son temps là-dessus, et les comptes des personnes parties restent actifs.
Avec un annuaire, l'authentification se fait contre l'Active Directory. Les comptes existent déjà, les départs se répercutent, et l'utilisateur ne connaît qu'un seul mot de passe.
Le compte de service, d'abord
GLPI a besoin d'un compte pour interroger l'annuaire. Trois règles.
Un compte dédié, pas celui d'un administrateur. Il vit dans une unité d'organisation de comptes de service, et son nom dit à quoi il sert.
En lecture seule. GLPI lit l'annuaire, il n'y écrit jamais. Un compte à privilèges élevés ici est un risque gratuit.
Mot de passe long, non expirant, tracé. Un compte de service dont le mot de passe expire fait tomber l'authentification de toute l'entreprise un matin, sans que personne ne comprenne pourquoi.
Les cinq champs qui décident de tout
La préconfiguration Active Directory de GLPI remplit le filtre de connexion ; vous fournissez le reste.
Le serveur. Adresse ou nom du contrôleur de domaine. Un nom vaut mieux qu'une adresse, et il en faut idéalement deux, pour la redondance.
Le BaseDN. Le point de départ de la recherche, écrit en nom distinctif : OU=Utilisateurs,DC=exemple,DC=local. Il se récupère dans l'éditeur d'attributs de la console Active Directory, sur l'attribut distinguishedName, après avoir activé l'affichage des fonctionnalités avancées.
Choisir le bon BaseDN compte : pointer la racine du domaine fait remonter les comptes de service, les comptes machines et les boîtes partagées. Pointez l'unité d'organisation des personnes.
Le DN du compte de connexion. Le distinguishedName complet du compte de service, copié tel quel.
Le champ de l'identifiant. samaccountname sur un Active Directory.
Le champ de synchronisation. C'est le piège de cette leçon.
Pourquoi objectGuid et rien d'autre
GLPI a besoin d'une clé stable pour reconnaître un utilisateur déjà importé. Trois candidats se présentent, et deux sont mauvais.
Le nom de connexion change quand quelqu'un se marie ou quand la convention de nommage évolue. Le nom distinctif change dès qu'on déplace le compte d'une unité d'organisation à une autre, opération banale.
Dans les deux cas, GLPI ne reconnaît plus la personne : il crée un second compte, et l'historique des tickets reste attaché au premier.
objectGuid est attribué à la création et ne change jamais, ni au renommage, ni au déplacement. C'est la seule valeur qui tienne le rôle.
Vérifier, puis durcir
L'onglet de test dit si la connexion aboutit. S'il échoue, l'ordre de vérification est stable : le compte et son mot de passe, puis le BaseDN, puis le port et le pare-feu.
Deux durcissements méritent d'être faits tout de suite.
Chiffrer la liaison, en LDAPS sur le port 636, faute de quoi le mot de passe du compte de service et ceux des utilisateurs circulent en clair sur le réseau interne.
Déclarer un second serveur, pour que la panne d'un contrôleur de domaine n'empêche pas toute l'entreprise de se connecter à GLPI.
À retenir
Un compte de service dédié, en lecture seule, au mot de passe non expirant. Un BaseDN qui pointe les personnes et non la racine. Et objectGuid comme champ de synchronisation : un identifiant qui change fabrique des doublons et détache l'historique.