Gestion de parc et support centralisés avec GLPI

Le contexte

Le lab comptait déjà de quoi déployer un poste — FOG — et de quoi surveiller ce qui tourne — Zabbix. Il manquait la pièce du milieu : savoir ce que contient le parc, et garder une trace de ce qu'on y fait.

Un inventaire tenu à la main est faux au bout de trois semaines. Une intervention non tracée n'a jamais eu lieu : personne ne sait ce qui a été changé, ni pourquoi, ni par qui. C'est exactement ce que j'ai retrouvé côté métier pendant mon stage, où le suivi des demandes passe par un outil ITSM du marché — la logique est la même, seul l'outil change.

L'objectif

Monter une plateforme de gestion de parc et de tickets utilisable au quotidien, avec deux exigences que je me suis fixées dès le départ :

• aucun compte local pour les utilisateurs du domaine — ils se connectent avec leur compte Active Directory, et leurs droits découlent de leur appartenance à un groupe ;
• aucune saisie manuelle d'inventaire — une machine du domaine doit apparaître dans GLPI toute seule, avec sa configuration matérielle et logicielle.

Autrement dit : la plateforme devait être branchée sur ce qui existe déjà, pas installée à côté.

Les choix techniques

Apache plutôt que Nginx. C'est le seul serveur web du lab qui ne tourne pas sous Nginx, et c'est délibéré : GLPI livre ses propres règles de protection de répertoires dans des fichiers .htaccess, qu'Apache applique nativement. Sous Nginx, il faut les retranscrire à la main dans la configuration du site — un travail qui n'apporte rien ici, et une occasion de laisser un répertoire sensible accessible.

PHP-FPM 8.4 et MariaDB, dimensionnés pour la charge réelle : un parc de lab, quelques dizaines d'éléments d'inventaire.

L'agent d'inventaire plutôt que la découverte réseau. GLPI sait balayer un réseau en SNMP pour deviner ce qu'il contient. L'agent installé sur le poste remonte la même chose en beaucoup plus précis — numéro de série, disques, mémoire, logiciels installés, correctifs — et il le fait à intervalle régulier sans qu'on le lui demande.

Le déploiement de l'agent par stratégie de groupe, comme pour l'agent Zabbix. Installer un agent à la main sur deux postes de lab est trivial ; c'est justement pour ça que ça n'apprend rien.

Ce que j'ai réalisé

Le serveur

Une machine virtuelle dédiée sous Debian 13 Trixie en installation minimale, avec un adressage statique réservé, sur le même socle que les autres serveurs Linux du lab. Puis la pile applicative : MariaDB avec sa base et son utilisateur dédié, Apache et PHP-FPM, et GLPI 11.0.8.

Deux points traités immédiatement après l'installation, avant toute configuration fonctionnelle :

• les quatre comptes par défaut créés par l'installeur — glpi, tech, normal, post-only — dont les identifiants sont publics et documentés dans tous les guides d'installation ;
• les actions automatiques basculées en mode CLI, déclenchées par le planificateur du système au lieu d'être déclenchées par les visites sur l'interface web.

Pourquoi sortir le cron de l'interface web ? En mode web, les tâches de fond de GLPI ne s'exécutent que lorsqu'un utilisateur charge une page. Sur une plateforme peu fréquentée, la conséquence est silencieuse et systématique : les notifications ne partent pas, les inventaires ne sont pas traités, et rien n'indique que quelque chose ne tourne plus. En CLI, l'exécution ne dépend plus de la présence de quelqu'un devant l'écran.

L'authentification sur l'annuaire

La connexion à l'Active Directory se fait avec un compte de service dédié, rangé dans l'unité d'organisation prévue pour les comptes de service du domaine. Ce compte ne sert qu'à interroger l'annuaire : il n'a besoin que de lire.

C'est le principe appliqué partout ailleurs dans le lab — un compte par usage, avec le strict nécessaire. Un compte administrateur du domaine placé dans une configuration applicative, c'est un mot de passe à privilèges élevés stocké dans une base de données, récupérable par quiconque obtient un accès au serveur.

La connexion d'utilisateurs du domaine a ensuite été validée poste par poste : aucun compte local applicatif n'est nécessaire pour ces utilisateurs.

Les habilitations par groupes

L'authentification dit qui vous êtes, pas ce que vous avez le droit de faire. Les droits sont attribués par des règles d'habilitation qui lisent l'appartenance aux groupes du domaine :

Groupe Active Directory	Profil GLPI attribué
Groupe Techniciens GLPI	Profil technicien — traitement des tickets et du parc
Groupe Administrateurs GLPI	Profil administrateur — configuration de la plateforme

L'intérêt est opérationnel : donner ou retirer l'accès à GLPI ne se fait plus dans GLPI. On ajoute la personne au groupe dans l'annuaire, et l'habilitation suit à la connexion suivante. Le jour où un technicien quitte l'équipe, désactiver son compte de domaine ferme aussi la porte de la plateforme — sans qu'il faille penser à un outil de plus.

L'inventaire automatisé

Le paquet MSI de l'agent GLPI est déposé sur un partage de distribution dédié du serveur de fichiers, et installé par un script PowerShell idempotent exécuté au démarrage des machines via une stratégie de groupe.

Idempotent, c'est-à-dire que le script vérifie d'abord si l'agent est déjà présent et à jour : s'il l'est, il s'arrête là. La stratégie s'applique à chaque démarrage sans réinstaller quoi que ce soit, et sans qu'il faille la retirer une fois le déploiement terminé.

La chaîne complète tient alors toute seule :

FOG déploie le poste  →  jonction automatique au domaine
                      →  la GPO installe l'agent au démarrage
                      →  la machine remonte dans l'inventaire GLPI
                      →  l'agent Zabbix, déployé de la même façon, la met sous supervision

Une machine neuve traverse ces quatre étapes sans aucune intervention manuelle.

Le résultat

Une plateforme de gestion de parc et de tickets adossée à l'annuaire du domaine : authentification centralisée, droits pilotés par les groupes Active Directory, inventaire matériel et logiciel alimenté automatiquement par les postes eux-mêmes.

Une limite assumée à ce stade : la plateforme est accessible en HTTP sur le réseau du lab. Le passage en HTTPS est la prochaine étape — c'est le seul point qui interdirait de considérer cette installation comme utilisable telle quelle dans un contexte réel, puisque les identifiants du domaine transitent en clair sur le réseau à chaque connexion.

Ce que j'en retiens

Le montage technique de GLPI n'est pas la partie difficile : une base, un serveur web, une pile PHP — la même mécanique que pour Zabbix.

Ce qui demande de la réflexion, c'est la place de l'outil dans l'existant. Une gestion de parc qui vit à côté de l'annuaire produit un deuxième référentiel d'utilisateurs à maintenir, qui diverge du premier au bout de quelques mois. Adossée à l'Active Directory, elle en devient une projection : une seule source pour les identités, une seule action pour donner ou retirer un accès.

Et le corollaire, valable pour toute base de données de parc : elle ne vaut que par sa fraîcheur. Un inventaire alimenté par les machines est juste par construction ; un inventaire tenu à la main est une photographie qui vieillit à partir de la seconde où on la range.