Login SSO in GLPI con Azure AD (Entra ID): guida completa

SSO in GLPI con Microsoft Entra ID (Azure AD): SAML su GLPI 10, OIDC su GLPI 11 e 12 con il modulo SSO Login o l'oauthsso, profilo dal gruppo Entra, provisioning JIT e la checklist che evita che il login cada in produzione.

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:

PluginProtocolloGLPI 10GLPI 11JITNota
glpisaml (DonutsNL)SAML 2.0SìNo (limitato a 10.9.99)SìSuccessore mantenuto di phpsaml
phpsaml (derricksmith)SAML 2.0LegacyNoSìFermo dal 2022; da evitare su nuovi progetti
oauthssoOpenID ConnectSìSìSìVia pragmatica su GLPI 11; Entra ha OIDC nativo
SSO Login (modulo NexTool)OpenID ConnectNoSì (anche GLPI 12)OpzionaleMulti-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

  1. 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.
Registrazione app in Microsoft Entra ID con più tenant, consenti tutti i tenant e l'URI di reindirizzamento di SSO Login
Registrazione dell'app per più organizzazioni, con l'URI di reindirizzamento copiato dal modulo.
  1. 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.
Panoramica dell'app in Entra ID con i campi ID applicazione, ID oggetto e ID directory
Gli ID dell'applicazione e della directory vanno nella scheda dell'applicazione in GLPI (sfocati nell'immagine).
  1. Configurazione del token: aggiungi le attestazioni facoltative email e upn al token ID. Per assegnare il profilo per gruppo, usa Aggiungi attestazione gruppi, seleziona Gruppi di sicurezza e mantieni ID gruppo.
Pannello di modifica dell'attestazione gruppi in Entra ID con Gruppi di sicurezza selezionato e ID gruppo scelto
L'attestazione gruppi invia gli ID oggetto dei gruppi di sicurezza dell'utente.
Configurazione del token in Entra ID con le attestazioni email, groups e upn
Risultato: email, upn e groups nel token ID.
  1. Autorizzazioni API: Microsoft Graph email, profile e User.Read, delegate. Senza il consenso dell'amministratore, ogni utente conferma l'accesso al primo login.

In GLPI

  1. Configurazione > SSO Login > Aggiungi: provider Microsoft Entra ID, ID client, segreto e tenant (l'ID directory). Per più organizzazioni, usa il tenant organizations con l'elenco dei tenant accettati oppure, se servi qualsiasi cliente, l'opzione di accettare qualsiasi tenant.
  2. 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.
  3. Profilo per gruppo: nell'applicazione, indica groups come 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.
  4. 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=1 alla 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).

  1. App registrations > New registration. Nome "GLPI"; account supportato: solo il Suo tenant (single tenant), a meno che Lei non serva più organizzazioni.
  2. Redirect URI (tipo Web): il callback del plugin - https://glpi.tuaazienda.com/plugins/oauthsso/front/callback.php.
  3. Certificates & secrets > New client secret. Annoti il valore (compare una sola volta) e, soprattutto, la data di scadenza.
  4. Token configuration: assicuri i claim email e preferred_username (o upn) - GLPI abbina l'utente tramite questi.
  5. 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_base nel 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.

Domande Frequenti

Sì, tramite OIDC (OpenID Connect), non SAML. Il plugin SAML più mantenuto, glpisaml, è limitato a MAX_GLPI 10.9.99. Sull'11 e sul 12, le vie sono il modulo SSO Login di NexTool, che consigliamo, e l'oauthsso, distribuito da Teclib con l'abbonamento GLPI Network.

Su GLPI 10 funzionano entrambi: SAML con glpisaml, OIDC con oauthsso. Su GLPI 11 e 12, usa OIDC, perché i plugin SAML non hanno seguito le nuove versioni. OIDC è anche più semplice da gestire con Entra, che espone OpenID Connect nativamente.

Sì. Il core di GLPI non fa login SAML/OIDC nativo (supporta LDAP/AD, CAS, x509 e 'autenticazione inviata nell'header HTTP'). Per Entra ID: glpisaml (SAML, solo GLPI 10), oauthsso (OIDC) o il modulo SSO Login di NexTool (OIDC, GLPI 11 e 12).

Aggiungi l'attestazione gruppi (Gruppi di sicurezza, ID gruppo) alla registrazione dell'app. Nel modulo SSO Login, indica groups come claim dei profili e crea una regola di assegnazione delle autorizzazioni con l'ID oggetto del gruppo: il profilo viene assegnato al primo login e tolto quando l'utente esce dal gruppo.

In Entra, con Enterprise Applications > Properties > Assignment required = Yes: solo chi assegni all'applicazione riceve il token. È essenziale con l'oauthsso, che crea l'utente al primo login e ignora il is_users_auto_add del core. Il modulo SSO Login rispetta questa impostazione di GLPI e crea utenti solo con e-mail verificata in un dominio consentito.

È il JIT senza profilo: l'utente viene creato, ma senza profilo assegnato. Diagnosticalo con un LEFT JOIN tra glpi_users e glpi_profiles_users cercando chi non ha collegamento, e configura una regola di assegnazione delle autorizzazioni (Amministrazione > Regole) per dare un profilo predefinito a chi arriva dal SSO.

Quasi sempre è una scadenza: il client secret OIDC (o il certificato di firma in SAML) è scaduto, e in Entra scadono tra 6 e 24 mesi. Altre cause: url_base con http:// dietro un proxy (redirect_uri_mismatch) e orologio del server non sincronizzato in SAML. Annota la data di scadenza e mantieni NTP attivo.

Hai bisogno di aiuto?