NexTool Solutions

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 :

En résumé : GLPI 10 accepte SAML (glpisaml) ou OIDC (oauthsso) ; GLPI 11, aujourd'hui, c'est OIDC via oauthsso. La suite de ce guide suit la voie OIDC, celle qui survit à la montée de version.

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).

1. App registrations > New registration. Nom "GLPI" ; compte pris en charge : votre seul tenant (single tenant), sauf si vous servez plusieurs organisations.
2. Redirect URI (type Web) : le callback du plugin - https://glpi.votreentreprise.com/plugins/oauthsso/front/callback.php.
3. Certificates & secrets > New client secret. Notez la valeur (affichée une seule fois) et, surtout, la date d'expiration.
4. Token configuration : assurez la présence des claims email et preferred_username (ou upn) - GLPI apparie l'utilisateur par ceux-ci.
5. 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_base en 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.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.