Le SSO dans GLPI avec Microsoft Entra ID (Azure AD) supprime les mots de passe locaux et centralise le MFA dans votre tenant. Mais ce qui distingue une connexion stable d'une astreinte à 3 heures du matin, ce n'est pas de cliquer sur "SAML" dans le portail : c'est de choisir le bon protocole pour votre version de GLPI et d'anticiper ce qui va expirer.
SAML ou OIDC ? La décision commence par la version de GLPI
Entra ID délivre le SSO via deux protocoles : SAML 2.0 et OpenID Connect (OIDC, au-dessus d'OAuth 2.0). GLPI ne parle nativement ni l'un ni l'autre pour la connexion - il faut un plugin. Et voici le piège qui attrape celui qui migre vers GLPI 11 : le plugin SAML le plus maintenu de la communauté, glpisaml, est plafonné à MAX_GLPI = 10.9.99. L'auteur déclare explicitement qu'il n'est pas (et ne sera jamais) compatible avec GLPI 11. Quiconque arrive au 11 en pensant "il suffit de réinstaller le plugin SAML" se heurte à un mur.
En pratique, voici la matrice de décision que nous utilisons :
| Plugin | Protocole | GLPI 10 | GLPI 11 | JIT | Remarque |
|---|---|---|---|---|---|
glpisaml (DonutsNL) | SAML 2.0 | Oui | Non (plafonné à 10.9.99) | Oui | Successeur maintenu de phpsaml |
phpsaml (derricksmith) | SAML 2.0 | Hérité | Non | Oui | Arrêté depuis 2022 ; à éviter sur de nouveaux projets |
oauthsso | OpenID Connect | Oui | Oui | Oui | Voie pragmatique sur GLPI 11 ; Entra a l'OIDC natif |
| SSO Login (module NexTool) | OpenID Connect | Non | Oui (aussi GLPI 12) | Optionnel | Multi-tenant, profil par le groupe Entra, accès direct à la connexion Microsoft |
En résumé : GLPI 10 accepte SAML (glpisaml) ou OIDC (oauthsso) ; GLPI 11 et 12 passent par OIDC. Pour le 11 et le 12, la voie que nous recommandons est le module SSO Login de NexTool, décrit dans la section suivante. L'oauthsso, que Teclib distribue avec l'abonnement GLPI Network, reste une alternative dans les étapes 1 à 5. Les parties proxy inverse, JIT et maintenance valent pour les deux.
La voie recommandée sur GLPI 11 et 12 : le module SSO Login
SSO Login est le module NexTool de connexion avec Microsoft Entra ID, Google et tout fournisseur OpenID Connect (Keycloak, Okta). Il règle les points qui génèrent le plus de tickets avec l'oauthsso : il sert plusieurs organisations dans un même GLPI (multi-tenant, pour les MSP), attribue le profil par le groupe de sécurité Entra dès la première connexion, respecte la création automatique d'utilisateurs de GLPI, ferme aussi la session Microsoft à la déconnexion et peut envoyer l'utilisateur directement vers la connexion Microsoft, sans passer par la page de GLPI.
Dans Entra ID
- Inscriptions d'applications > Nouvelle inscription. Choisissez le type de compte : un seul locataire pour votre entreprise, ou plusieurs locataires si GLPI sert des clients d'autres organisations. Dans URI de redirection (plateforme Web), collez l'adresse que le module affiche prête à copier, au format
https://glpi.votreentreprise.com/plugins/nextool/sso/ssologin/callback.

- Vue d'ensemble : notez l'ID d'application (client) et l'ID d'annuaire (locataire). Dans Certificats & secrets, créez le secret client et copiez sa valeur tout de suite : elle n'apparaît qu'une fois. Notez aussi la date d'expiration.

- Configuration du jeton : ajoutez les revendications facultatives
emailetupnau jeton d'ID. Pour attribuer le profil par groupe, utilisez Ajouter une revendication de groupes, cochez Groupes de sécurité et gardez ID de groupe.


- Autorisations d'API : Microsoft Graph
email,profileetUser.Read, déléguées. Sans le consentement de l'administrateur, chaque utilisateur confirme l'accès à la première connexion.
Dans GLPI
- Configuration > SSO Login > Ajouter : fournisseur Microsoft Entra ID, ID client, secret et locataire (l'ID d'annuaire). Pour plusieurs organisations, utilisez le locataire
organizationsavec la liste des locataires acceptés ou, si vous servez n'importe quel client, l'option d'accepter tout locataire. - Champ de la première correspondance :
upn. Au premier accès, le module cherche l'utilisateur GLPI dont l'identifiant est l'upn ; ensuite, le lien utilise l'identifiant fixe du compte dans Entra, et changer l'e-mail là-bas ne casse pas la connexion. - Profil par groupe : dans l'application, indiquez
groupscomme claim de profils et créez une règle d'affectation d'habilitations (Administration > Règles) avec le critère Roles (claim) égal à l'ID d'objet du groupe de sécurité et l'action de profil. Le profil est dynamique : qui quitte le groupe perd le profil à la connexion suivante. - Testez et ouvrez l'accès : l'onglet Test de l'application valide la configuration et les clés du fournisseur sans se connecter. Avec l'application active, le bouton apparaît sur la page de connexion. Pour sauter cette page, activez Aller directement à la connexion SSO dans l'onglet Paramètres du module ; l'administrateur local entre toujours par l'adresse de la page de connexion avec
?noAUTO=1à la fin.
Deux différences d'exploitation par rapport à l'oauthsso. Les comptes locaux de GLPI et les administrateurs ne sont pas repris par une connexion externe, sauf si vous l'autorisez dans l'application. Et la création automatique d'utilisateurs respecte le réglage de GLPI et n'a lieu qu'avec un e-mail vérifié dans un domaine autorisé. L'Assignment required d'Entra, décrit à l'étape 5, reste une bonne pratique pour restreindre qui reçoit un jeton.
1. Enregistrer l'application dans Entra ID
Pour OIDC, le chemin dans le portail Entra ID est App registrations (inscriptions d'applications), pas l'Enterprise Application avec "SAML" : vous enregistrez une app et générez un secret (client secret).
- App registrations > New registration. Nom "GLPI" ; compte pris en charge : votre seul tenant (single tenant), sauf si vous servez plusieurs organisations.
- Redirect URI (type Web) : le callback du plugin -
https://glpi.votreentreprise.com/plugins/oauthsso/front/callback.php. - Certificates & secrets > New client secret. Notez la valeur (affichée une seule fois) et, surtout, la date d'expiration.
- Token configuration : assurez la présence des claims
emailetpreferred_username(ouupn) - GLPI apparie l'utilisateur par ceux-ci. - Enterprise Applications > votre app > Properties :
Assignment required = Yes. C'est votre véritable liste d'autorisation (expliquée à l'étape 5).
2. Configurer GLPI (voie OIDC)
Extrayez le plugin dans plugins/ (ou marketplace/) et installez-le en ligne de commande. L'erreur courante ici est de lancer la console en root : les fichiers générés reçoivent le mauvais propriétaire et l'accès web suivant casse sur les permissions. Lancez-la avec l'utilisateur du serveur web :
# GLPI 11 : installer et activer le plugin en tant qu'utilisateur Apache (www-data/apache)
php bin/console plugin:install oauthsso
php bin/console plugin:activate oauthsso
# oauthsso ne crée PAS sa propre table : il stocke tout dans glpi_configs,
# sous le contexte 'plugin:oauthsso' (tenant id, client id, client secret).
Sur l'écran du plugin (ou directement dans glpi_configs), renseignez le Tenant ID, le Client ID et le Client Secret de l'app enregistrée. L'écran de connexion de GLPI affiche alors le bouton "Login with Microsoft".
3. Le piège du redirect derrière un reverse proxy
C'est le ticket que nous ouvrons le plus lors du déploiement : GLPI est derrière un Nginx/Apache qui termine le TLS et, en interne, voit la requête comme http://. Résultat : il construit le callback avec http://, Entra reçoit une redirect URI qui ne correspond pas à celle enregistrée et renvoie redirect_uri_mismatch - ou l'utilisateur entre dans une boucle de redirection. La correction définitive est de figer l'URL de base en base de données :
-- Forcer l'URL de base correcte (évite un callback http:// derrière le proxy)
UPDATE glpi_configs
SET value = 'https://glpi.votreentreprise.com'
WHERE context = 'core' AND name = 'url_base';
-- GLPI met la config en cache : videz le cache après modification
-- php bin/console cache:clear
Confirmez aussi que le proxy transmet le vrai schéma - par exemple, RequestHeader set X-Forwarded-Proto "https" sous Apache, ou proxy_set_header X-Forwarded-Proto $scheme; sous Nginx. Une URL de base correcte plus le bon header mettent fin à la boucle.
4. JIT : quand l'utilisateur se connecte mais ne voit rien
Le provisionnement Just-in-Time crée l'utilisateur à la première connexion - mais n'attribue pas de profil. Le symptôme est classique : l'authentification passe, l'utilisateur entre et tombe sur un écran vide ("aucun profil attribué"). En maintenance, c'est le deuxième motif de ticket juste après "SSO configuré". Le diagnostic tient en une ligne de SQL :
-- Utilisateurs SSO (authentification externe) restés SANS profil :
-- ils se connectent, mais tombent sur un écran vide.
SELECT u.id, u.name, u.authtype
FROM glpi_users u
LEFT JOIN glpi_profiles_users pu ON pu.users_id = u.id
WHERE pu.id IS NULL
AND u.is_deleted = 0;
La sortie vous donne exactement qui a besoin d'un profil. La solution qui passe à l'échelle est une règle d'attribution d'habilitations (Administration > Règles) qui accorde un profil par défaut à ceux qui arrivent par SSO, plutôt que de le faire à la main pour chaque nouvel utilisateur.
5. La vraie liste d'autorisation est dans Entra, pas dans GLPI
Un détail que seul l'exploitant découvre à la dure : oauthsso crée l'utilisateur à la première connexion et ignore le flag is_users_auto_add du core de GLPI. Autrement dit, tout compte valide du tenant qui atteint le callback devient utilisateur de GLPI. Chercher le verrou dans GLPI ne sert à rien - il n'existe pas dans le plugin. Le vrai contrôle est le Assignment required = Yes de l'étape 1 : activé, Entra n'émet un token qu'à ceux que vous avez explicitement affectés à l'application. C'est votre liste d'autorisation, gérée dans le tenant.
Une note sur les groupes : si vous voulez mapper un groupe AD vers un profil GLPI, sachez qu'Entra envoie les groupes sous forme de GUID, pas de noms lisibles. Soit vous utilisez les App Roles (des noms que vous définissez), soit vous traduisez le GUID dans le mapping. Attendre "IT" et recevoir 7a2f... est la troisième surprise courante.
Checklist de maintenance : ce qui casse en production
Le SSO n'est pas "configuré, oublié". Dans notre exploitation, chaque environnement SSO entre à l'inventaire avec ces éléments surveillés, car ce sont eux qui font tomber la connexion sans que personne n'ait rien touché :
- Expiration du client secret (OIDC) ou du certificat de signature (SAML) : c'est la cause numéro 1 du "le SSO s'est arrêté sans raison". Le secret Entra expire (entre 6 et 24 mois) ; notez la date et renouvelez à l'avance.
- Horloge du serveur (SAML) : l'assertion a une fenêtre de validité ; si l'heure dérive, GLPI la rejette avec "assertion not yet valid". Gardez NTP/chrony actif (
timedatectl status). - Rotation d'URL/domaine : le domaine GLPI a changé ? Mettez à jour la redirect URI dans Entra et
url_baseen base dans le même déploiement. - Repli local : gardez au moins un compte administrateur local actif. Si l'IdP tombe, vous pouvez encore entrer par la connexion traditionnelle de GLPI.
Chez NexTool, nous configurons et maintenons le SSO (Entra ID, Google Workspace et LDAP/AD) dans des environnements GLPI de clients, avec l'inventaire des expirations et le repli documentés - précisément pour que la connexion ne devienne pas une astreinte. Si vous voulez ce design appliqué à votre environnement, parlez-nous de support et maintenance GLPI.
Révisé par l'équipe NexTool Solutions.