La question que l'annuaire ne règle pas
Une fois l'authentification branchée, tout le monde peut se connecter. Reste à décider ce que chacun voit et peut faire. C'est là que se joue l'adoption de l'outil, et c'est la partie qu'aucune documentation d'installation ne traite.
Trois notions suffisent, et elles se combinent.
Les entités : qui voit quoi
Une entité est un cloisonnement. Un utilisateur rattaché à une entité ne voit que le matériel et les tickets de cette entité.
Les cas d'usage réels sont peu nombreux et clairs : plusieurs sites géographiques dont les parcs ne se mélangent pas, plusieurs sociétés d'un même groupe, ou un prestataire qui gère plusieurs clients dans une seule instance.
L'arborescence est hiérarchique : un droit posé sur une entité parente descend sur ses filles, sauf indication contraire.
L'erreur fréquente est d'en créer trop. Une PME sur un seul site n'a besoin que de l'entité racine. Des entités par service produisent des tickets qui n'arrivent jamais au bon endroit, et des matériels invisibles à ceux qui en ont la charge.
Les profils : qui peut quoi
Un profil est un ensemble de droits. GLPI en livre plusieurs, qui couvrent la majorité des besoins.
| Profil | Usage |
|---|---|
| Self-Service | déposer un ticket et suivre le sien, rien d'autre |
| Observer | consulter sans modifier |
| Technician | traiter les tickets, gérer le matériel |
| Supervisor | Technician, plus la vue d'équipe et les statistiques |
| Super-Admin | tout, y compris la configuration |
Deux règles de prudence. Partez d'un profil existant plutôt que d'en créer un de zéro : la grille de droits est vaste et une case oubliée se voit tard. Et gardez au moins deux comptes Super-Admin, sinon le départ ou le verrouillage d'une personne vous enferme dehors.
Les règles d'habilitation : qui obtient quoi, automatiquement
C'est le mécanisme qui rend l'ensemble tenable. Une règle d'habilitation lit une information de l'annuaire et en déduit l'entité et le profil.
Le critère le plus solide est l'appartenance à un groupe de l'annuaire :
- membre de
GG_Informatique: profil Technician sur l'entité racine - membre de
GG_Encadrement: profil Observer - tout le reste : profil Self-Service
Le bénéfice est le même que partout ailleurs en administration système : l'attribution des droits redevient un geste d'annuaire. On ajoute quelqu'un au groupe, et GLPI suit. On le retire, et l'accès tombe. Personne n'a besoin d'ouvrir GLPI.
Une règle par défaut, en dernière position, doit attraper les comptes qui ne correspondent à rien. Sans elle, ces utilisateurs se connectent sans aucun droit et ouvrent un ticket pour le signaler, ce qu'ils ne peuvent justement pas faire.
Importer, et garder à jour
Deux modes coexistent.
À la première connexion, le compte se crée automatiquement. Simple, et l'annuaire reste la source.
Par import de masse, pour peupler l'outil avant l'ouverture du service, ou pour rattacher du matériel à des personnes qui ne se sont pas encore connectées.
Dans les deux cas, une synchronisation périodique doit tourner, sinon les changements de l'annuaire ne se répercutent pas. Elle relit les comptes, applique de nouveau les règles, et désactive côté GLPI les comptes disparus de l'annuaire.
Le point à vérifier une fois : que le compte d'une personne partie devienne bien inactif. Un compte qui reste actif après un départ est exactement ce que le branchement sur l'annuaire devait éviter.
À retenir
Une entité par cloisonnement réel, pas par service. Un profil existant plutôt qu'un profil bricolé, et deux Super-Admin au minimum. Des règles d'habilitation fondées sur les groupes de l'annuaire, avec une règle par défaut en dernier. Et une synchronisation périodique, sans laquelle les départs ne se répercutent pas.