NexTool Solutions

L'SSO in GLPI con Microsoft Entra ID (Azure AD) elimina le password locali e centralizza l'MFA nel tuo tenant. Ma ciò che distingue un login stabile da una reperibilità notturna non è cliccare "SAML" nel portale: è scegliere il protocollo giusto per la tua 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:

In sintesi: GLPI 10 accetta SAML (glpisaml) o OIDC (oauthsso); GLPI 11, oggi, è OIDC via oauthsso. Il resto di questa guida segue la via OIDC, quella che sopravvive all'aggiornamento di versione.

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": registri un'app e generi un segreto (client secret).

1. App registrations > New registration. Nome "GLPI"; account supportato: solo il tuo tenant (single tenant), a meno che tu 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. Annota il valore (compare una sola volta) e, soprattutto, la data di scadenza.
4. Token configuration: assicura i claim email e preferred_username (o upn) - GLPI abbina l'utente tramite questi.
5. Enterprise Applications > la tua app > Properties: Assignment required = Yes. Questa è la tua vera lista di autorizzati (spiegata al passo 5).

2. Configurare GLPI (via OIDC)

Estrai il plugin in plugins/ (o marketplace/) e installalo 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. Lanciala 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), inserisci 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

Verifica 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 ti 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 hai assegnato esplicitamente all'applicazione. È la tua lista di autorizzati, gestita nel tenant.

Una nota sui gruppi: se vuoi mappare un gruppo AD su un profilo GLPI, sappi che Entra invia i gruppi come GUID, non come nome leggibile. O usi gli App Roles (nomi che definisci tu) oppure traduci 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); annota la data e rinnovalo 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". Tieni NTP/chrony attivo (timedatectl status).
• Rotazione di URL/dominio: è cambiato il dominio di GLPI? Aggiorna la redirect URI in Entra e url_base nel database nello stesso deploy.
• Fallback locale: mantieni almeno un account amministratore locale attivo. Se l'IdP va giù, puoi 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 vuoi questo disegno applicato al tuo ambiente, parla con noi di supporto e manutenzione GLPI.

Questo contenuto è stato prodotto con l'aiuto dell'intelligenza artificiale e revisionato dal team Nextool Solutions.