L'SSO in GLPI con Microsoft Entra ID (Azure AD) elimina le password locali e centralizza l'MFA nel Suo tenant. Ma ciò che distingue un login stabile da una reperibilità notturna non è cliccare "SAML" nel portale: è scegliere il protocollo giusto per la Sua versione di GLPI e prevedere cosa scadrà.
SAML o OIDC? La decisione parte dalla versione di GLPI
Entra ID eroga l'SSO tramite due protocolli: SAML 2.0 e OpenID Connect (OIDC, sopra OAuth 2.0). GLPI non parla nessuno dei due nativamente per il login - serve un plugin. Ed ecco la trappola che frega chi migra a GLPI 11: il plugin SAML più mantenuto della comunità, glpisaml, è limitato a MAX_GLPI = 10.9.99. L'autore stesso dichiara che non è (e non sarà) compatibile con GLPI 11. Chi arriva all'11 aspettandosi di "reinstallare solo il plugin SAML" sbatte contro un muro.
In pratica, questa è la matrice decisionale che usiamo:
| Plugin | Protocollo | GLPI 10 | GLPI 11 | JIT | Nota |
|---|---|---|---|---|---|
glpisaml (DonutsNL) | SAML 2.0 | Sì | No (limitato a 10.9.99) | Sì | Successore mantenuto di phpsaml |
phpsaml (derricksmith) | SAML 2.0 | Legacy | No | Sì | Fermo dal 2022; da evitare su nuovi progetti |
oauthsso | OpenID Connect | Sì | Sì | Sì | Via pragmatica su GLPI 11; Entra ha OIDC nativo |
| SSO Login (modulo NexTool) | OpenID Connect | No | Sì (anche GLPI 12) | Opzionale | Multi-tenant, profilo dal gruppo Entra, accesso diretto al login Microsoft |
In sintesi: GLPI 10 accetta SAML (glpisaml) o OIDC (oauthsso); GLPI 11 e 12 usano OIDC. Per l'11 e il 12, la via che consigliamo è il modulo SSO Login di NexTool, descritto nella sezione seguente. L'oauthsso, che Teclib distribuisce con l'abbonamento GLPI Network, resta un'alternativa nei passi da 1 a 5. Le parti su proxy inverso, JIT e manutenzione valgono per entrambi.
La via consigliata su GLPI 11 e 12: il modulo SSO Login
SSO Login è il modulo NexTool per accedere con Microsoft Entra ID, Google e qualsiasi provider OpenID Connect (Keycloak, Okta). Risolve i punti che generano più ticket con l'oauthsso: serve più organizzazioni nello stesso GLPI (multi-tenant, per gli MSP), assegna il profilo dal gruppo di sicurezza Entra già al primo accesso, rispetta la creazione automatica degli utenti di GLPI, chiude anche la sessione Microsoft all'uscita e può portare l'utente direttamente al login Microsoft, senza passare dalla pagina di GLPI.
In Entra ID
- Registrazioni app > Nuova registrazione. Scegli il tipo di account: un solo tenant per la tua azienda, oppure più tenant se GLPI serve clienti di altre organizzazioni. In URI di reindirizzamento (piattaforma Web), incolla l'indirizzo che il modulo mostra pronto da copiare, nel formato
https://glpi.tuaazienda.com/plugins/nextool/sso/ssologin/callback.

- Panoramica: annota l'ID applicazione (client) e l'ID directory (tenant). In Certificati e segreti, crea il segreto client e copia subito il valore: compare una sola volta. Annota anche la data di scadenza.

- Configurazione del token: aggiungi le attestazioni facoltative
emaileupnal token ID. Per assegnare il profilo per gruppo, usa Aggiungi attestazione gruppi, seleziona Gruppi di sicurezza e mantieni ID gruppo.


- Autorizzazioni API: Microsoft Graph
email,profileeUser.Read, delegate. Senza il consenso dell'amministratore, ogni utente conferma l'accesso al primo login.
In GLPI
- Configurazione > SSO Login > Aggiungi: provider Microsoft Entra ID, ID client, segreto e tenant (l'ID directory). Per più organizzazioni, usa il tenant
organizationscon l'elenco dei tenant accettati oppure, se servi qualsiasi cliente, l'opzione di accettare qualsiasi tenant. - Campo della prima corrispondenza:
upn. Al primo accesso, il modulo cerca l'utente GLPI il cui login è l'upn; dopo, il collegamento usa l'identificatore fisso dell'account in Entra, e cambiare l'e-mail lì non interrompe il login. - Profilo per gruppo: nell'applicazione, indica
groupscome claim dei profili e crea una regola di assegnazione delle autorizzazioni (Amministrazione > Regole) con il criterio Roles (claim) uguale all'ID oggetto del gruppo di sicurezza e l'azione di profilo. Il profilo è dinamico: chi esce dal gruppo perde il profilo al login successivo. - Prova e abilita: la scheda Test dell'applicazione verifica la configurazione e le chiavi del provider senza accedere. Con l'applicazione attiva, il pulsante compare nella pagina di login. Per saltare quella pagina, attiva Vai direttamente all'accesso SSO nella scheda Impostazioni del modulo; l'amministratore locale entra sempre dall'indirizzo della pagina di login con
?noAUTO=1alla fine.
Due differenze operative rispetto all'oauthsso. Gli account locali di GLPI e gli amministratori non vengono presi in carico da un login esterno, a meno che tu non lo consenta nell'applicazione. E la creazione automatica degli utenti rispetta l'impostazione di GLPI e avviene solo con e-mail verificata in un dominio consentito. L'Assignment required di Entra, descritto al passo 5, resta una buona pratica per limitare chi riceve il token.
1. Registrare l'applicazione in Entra ID
Per OIDC, il percorso nel portale di Entra ID è App registrations (registrazioni app), non la Enterprise Application con "SAML": registra un'app e genera un segreto (client secret).
- App registrations > New registration. Nome "GLPI"; account supportato: solo il Suo tenant (single tenant), a meno che Lei non serva più organizzazioni.
- Redirect URI (tipo Web): il callback del plugin -
https://glpi.tuaazienda.com/plugins/oauthsso/front/callback.php. - Certificates & secrets > New client secret. Annoti il valore (compare una sola volta) e, soprattutto, la data di scadenza.
- Token configuration: assicuri i claim
emailepreferred_username(oupn) - GLPI abbina l'utente tramite questi. - Enterprise Applications > la Sua app > Properties:
Assignment required = Yes. Questa è la Sua vera lista di autorizzati (spiegata al passo 5).
2. Configurare GLPI (via OIDC)
Estragga il plugin in plugins/ (o marketplace/) e lo installi da riga di comando. L'errore comune qui è lanciare la console come root: i file generati finiscono con il proprietario sbagliato e il successivo accesso web si rompe sui permessi. La lanci come l'utente del server web:
# GLPI 11: installare e attivare il plugin come l'utente di Apache (www-data/apache)
php bin/console plugin:install oauthsso
php bin/console plugin:activate oauthsso
# oauthsso NON crea una propria tabella: salva tutto in glpi_configs,
# nel contesto 'plugin:oauthsso' (tenant id, client id, client secret).
Nella schermata del plugin (o direttamente in glpi_configs), inserisca il Tenant ID, il Client ID e il Client Secret dell'app registrata. La schermata di login di GLPI mostra poi il pulsante "Login with Microsoft".
3. La trappola del redirect dietro un reverse proxy
È il ticket che apriamo di più durante l'implementazione: GLPI è dietro un Nginx/Apache che termina il TLS e, internamente, vede la richiesta come http://. Risultato: costruisce il callback con http://, Entra riceve una redirect URI che non coincide con quella registrata e restituisce redirect_uri_mismatch - oppure l'utente entra in un loop di reindirizzamento. La correzione definitiva è fissare l'URL di base nel database:
-- Forzare l'URL di base corretto (evita un callback http:// dietro il proxy)
UPDATE glpi_configs
SET value = 'https://glpi.tuaazienda.com'
WHERE context = 'core' AND name = 'url_base';
-- GLPI mette in cache la config: svuota la cache dopo la modifica
-- php bin/console cache:clear
Verifichi anche che il proxy inoltri lo schema reale - ad esempio, RequestHeader set X-Forwarded-Proto "https" in Apache, oppure proxy_set_header X-Forwarded-Proto $scheme; in Nginx. URL di base corretto più l'header corretto chiudono il loop.
4. JIT: quando l'utente accede ma non vede nulla
Il provisioning Just-in-Time crea l'utente al primo login - ma non assegna un profilo. Il sintomo è classico: l'autenticazione passa, l'utente entra e finisce su una schermata vuota ("nessun profilo assegnato"). In manutenzione, è il secondo motivo di ticket subito dopo "SSO configurato". La diagnosi è una riga di SQL:
-- Utenti SSO (autenticazione esterna) rimasti SENZA profilo:
-- accedono, ma finiscono su una schermata vuota.
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;
L'output Le dà esattamente chi ha bisogno di un profilo. La soluzione scalabile è una regola di assegnazione delle autorizzazioni (Amministrazione > Regole) che conceda un profilo predefinito a chi arriva via SSO, invece di farlo a mano per ogni nuovo utente.
5. La vera lista di autorizzati sta in Entra, non in GLPI
Un dettaglio che solo chi opera scopre a proprie spese: oauthsso crea l'utente al primo login e ignora il flag is_users_auto_add del core di GLPI. In altre parole, qualsiasi account valido del tenant che raggiunga il callback diventa utente di GLPI. Cercare il blocco dentro GLPI è inutile - non esiste nel plugin. Il controllo reale è il Assignment required = Yes del passo 1: attivo, Entra emette un token solo a chi ha assegnato esplicitamente all'applicazione. È la Sua lista di autorizzati, gestita nel tenant.
Una nota sui gruppi: se vuole mappare un gruppo AD su un profilo GLPI, sappia che Entra invia i gruppi come GUID, non come nome leggibile. O usa gli App Roles (nomi che definisce Lei) oppure traduce il GUID nel mapping. Aspettarsi "IT" e ricevere 7a2f... è la terza sorpresa comune.
Checklist di manutenzione: cosa si rompe in produzione
L'SSO non è "configurato e dimenticato". Nella nostra operatività, ogni ambiente con SSO entra nell'inventario con questi elementi monitorati, perché sono quelli che fanno cadere il login senza che nessuno abbia toccato niente:
- Scadenza del client secret (OIDC) o del certificato di firma (SAML): è la causa numero 1 del "l'SSO si è fermato dal nulla". Il secret di Entra scade (tra 6 e 24 mesi); annoti la data e lo rinnovi in anticipo.
- Orologio del server (SAML): l'assertion ha una finestra di validità; se l'ora deriva, GLPI la rifiuta con "assertion not yet valid". Tenga NTP/chrony attivo (
timedatectl status). - Rotazione di URL/dominio: è cambiato il dominio di GLPI? Aggiorni la redirect URI in Entra e
url_basenel database nello stesso deploy. - Fallback locale: mantenga almeno un account amministratore locale attivo. Se l'IdP va giù, può comunque entrare dal login tradizionale di GLPI.
In NexTool configuriamo e manteniamo l'SSO (Entra ID, Google Workspace e LDAP/AD) in ambienti GLPI di clienti, con l'inventario delle scadenze e il fallback documentati - proprio perché il login non diventi una reperibilità. Se vuole questo disegno applicato al Suo ambiente, parli con noi di supporto e manutenzione GLPI.
Revisionato dal team NexTool Solutions.