El SSO en GLPI con Microsoft Entra ID (Azure AD) elimina las contraseñas locales y centraliza el MFA en tu tenant. Pero lo que decide entre un inicio de sesión estable y una guardia de madrugada no es hacer clic en "SAML" en el portal: es elegir el protocolo correcto para tu versión de GLPI y anticipar lo que va a caducar.
¿SAML u OIDC? La decisión empieza por la versión de GLPI
Entra ID entrega SSO por dos protocolos: SAML 2.0 y OpenID Connect (OIDC, sobre OAuth 2.0). GLPI no habla ninguno de forma nativa para el login - necesitas un plugin. Y aquí está la trampa que atrapa a quien migra a GLPI 11: el plugin SAML más mantenido de la comunidad, glpisaml, está limitado en MAX_GLPI = 10.9.99. El propio autor declara que no es (ni será) compatible con GLPI 11. Quien llega al 11 esperando "solo reinstalar el plugin SAML" choca contra un muro.
En la práctica, esta es la matriz de decisión que usamos:
| Plugin | Protocolo | GLPI 10 | GLPI 11 | JIT | Nota |
|---|---|---|---|---|---|
glpisaml (DonutsNL) | SAML 2.0 | Sí | No (limitado en 10.9.99) | Sí | Sucesor mantenido de phpsaml |
phpsaml (derricksmith) | SAML 2.0 | Heredado | No | Sí | Detenido desde 2022; evitar en proyectos nuevos |
oauthsso | OpenID Connect | Sí | Sí | Sí | Ruta pragmática en GLPI 11; Entra tiene OIDC nativo |
Resumen: GLPI 10 acepta SAML (glpisaml) u OIDC (oauthsso); GLPI 11, hoy, es OIDC vía oauthsso. El resto de esta guía sigue la ruta OIDC, que es la que sobrevive a la actualización de versión.
1. Registrar la aplicación en Entra ID
Para OIDC, el camino en el portal de Entra ID es App registrations (registro de aplicaciones), no la Enterprise Application con "SAML": registras una app y generas un secreto (client secret).
- App registrations > New registration. Nombre "GLPI"; cuenta admitida: solo tu tenant (single tenant), salvo que atiendas a varias organizaciones.
- Redirect URI (tipo Web): el callback del plugin -
https://glpi.tuempresa.com/plugins/oauthsso/front/callback.php. - Certificates & secrets > New client secret. Anota el valor (aparece una sola vez) y, sobre todo, la fecha de caducidad.
- Token configuration: asegura los claims
emailypreferred_username(oupn) - GLPI empareja al usuario por ellos. - Enterprise Applications > tu app > Properties:
Assignment required = Yes. Esta es tu lista de permitidos real (se explica en el paso 5).
2. Configurar GLPI (ruta OIDC)
Extrae el plugin en plugins/ (o marketplace/) e instálalo por línea de comandos. El error común aquí es ejecutar la consola como root: los archivos generados quedan con el propietario equivocado y el siguiente acceso web se rompe por permisos. Ejecútala como el usuario del servidor web:
# GLPI 11: instalar y activar el plugin como el usuario de Apache (www-data/apache)
php bin/console plugin:install oauthsso
php bin/console plugin:activate oauthsso
# oauthsso NO crea su propia tabla: lo guarda todo en glpi_configs,
# en el contexto 'plugin:oauthsso' (tenant id, client id, client secret).
En la pantalla del plugin (o directamente en glpi_configs), indica el Tenant ID, el Client ID y el Client Secret de la app registrada. La pantalla de login de GLPI pasa a mostrar el botón "Login with Microsoft".
3. La trampa del redirect detrás de un reverse proxy
Este es el ticket que más abrimos en la implantación: GLPI está detrás de un Nginx/Apache que termina el TLS e, internamente, ve la petición como http://. Resultado: arma el callback con http://, Entra recibe una redirect URI que no coincide con la registrada y devuelve redirect_uri_mismatch - o el usuario entra en un bucle de redirección. La corrección definitiva es fijar la URL base en la base de datos:
-- Forzar la URL base correcta (evita un callback http:// detrás del proxy)
UPDATE glpi_configs
SET value = 'https://glpi.tuempresa.com'
WHERE context = 'core' AND name = 'url_base';
-- GLPI cachea la config: limpia la caché después de cambiarla
-- php bin/console cache:clear
Confirma también que el proxy reenvía el esquema real - por ejemplo, RequestHeader set X-Forwarded-Proto "https" en Apache, o proxy_set_header X-Forwarded-Proto $scheme; en Nginx. La URL base correcta más el header correcto acaban con el bucle.
4. JIT: cuando el usuario entra pero no ve nada
El aprovisionamiento Just-in-Time crea el usuario en el primer login - pero no asigna perfil. El síntoma es clásico: la autenticación pasa, el usuario entra y cae en una pantalla vacía ("ningún perfil asignado"). En el soporte, este es el segundo motivo de ticket justo después de "SSO configurado". El diagnóstico es una línea de SQL:
-- Usuarios de SSO (autenticación externa) que quedaron SIN perfil:
-- inician sesión, pero caen en una pantalla vacía.
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 salida te da exactamente quién necesita perfil. La solución escalable es una regla de asignación de autorizaciones (Administración > Reglas) que conceda un perfil por defecto a quien llega por SSO, en lugar de hacerlo a mano con cada nuevo usuario.
5. La lista de permitidos real está en Entra, no en GLPI
Un detalle que solo quien opera descubre a las malas: oauthsso crea el usuario en el primer login e ignora la bandera is_users_auto_add del core de GLPI. Es decir, cualquier cuenta válida del tenant que llegue al callback se convierte en usuario de GLPI. No sirve de nada buscar el candado dentro de GLPI - no existe en el plugin. El control real es el Assignment required = Yes del paso 1: con él activado, Entra solo emite token a quien hayas asignado explícitamente a la aplicación. Esa es tu lista de permitidos, gestionada en el tenant.
Un apunte sobre grupos: si quieres mapear un grupo de AD a un perfil de GLPI, ten en cuenta que Entra envía los grupos como GUID, no como nombre legible. O usas App Roles (nombres que defines tú) o traduces el GUID en el mapeo. Esperar "TI" y recibir 7a2f... es la tercera sorpresa común.
Checklist de sostenimiento: qué se rompe en producción
El SSO no es "configurar y olvidar". En nuestra operación, todo entorno con SSO entra en el inventario con estos elementos monitorizados, porque son los que tumban el login sin que nadie haya tocado nada:
- Caducidad del client secret (OIDC) o del certificado de firma (SAML): es la causa número 1 de "el SSO se paró de la nada". El secreto de Entra caduca (entre 6 y 24 meses); anota la fecha y renuévalo con antelación.
- Reloj del servidor (SAML): la assertion tiene ventana de validez; si la hora se desvía, GLPI la rechaza con "assertion not yet valid". Mantén NTP/chrony activo (
timedatectl status). - Rotación de URL/dominio: ¿cambió el dominio de GLPI? Actualiza la redirect URI en Entra y
url_baseen la base de datos en el mismo despliegue. - Fallback local: mantén al menos una cuenta local de administrador activa. Si el IdP cae, aún puedes entrar por el login tradicional de GLPI.
En NexTool configuramos y sostenemos SSO (Entra ID, Google Workspace y LDAP/AD) en entornos GLPI de clientes, con el inventario de caducidades y el fallback documentados - precisamente para que el login no se convierta en una guardia. Si quieres este diseño aplicado a tu entorno, habla con nosotros sobre soporte y sostenimiento de GLPI.
Este contenido se produjo con ayuda de inteligencia artificial y fue revisado por el equipo de Nextool Solutions.
