NexTool Solutions

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:

Resumen: GLPI 10 acepta SAML (glpisaml) u OIDC (oauthsso); GLPI 11 y 12 son OIDC. Para el 11 y el 12, la ruta que recomendamos es el módulo SSO Login de NexTool, descrito en la siguiente sección. El oauthsso, que Teclib distribuye con la suscripción GLPI Network, sigue como alternativa en los pasos 1 a 5. Las partes de proxy inverso, JIT y soporte valen para ambos.

La ruta recomendada en GLPI 11 y 12: el módulo SSO Login

SSO Login es el módulo de NexTool para iniciar sesión con Microsoft Entra ID, Google y cualquier proveedor OpenID Connect (Keycloak, Okta). Resuelve los puntos que más tickets generan con el oauthsso: atiende a varias organizaciones en un mismo GLPI (multi-tenant, para MSP), asigna el perfil por el grupo de seguridad de Entra desde el primer inicio de sesión, respeta la creación automática de usuarios de GLPI, también cierra la sesión en Microsoft al salir y puede llevar al usuario directo al login de Microsoft, sin pasar por la pantalla de GLPI.

En Entra ID

1. Registros de aplicaciones > Nuevo registro. Elija el tipo de cuenta: un único inquilino para su empresa o varios inquilinos si GLPI atiende a clientes de otras organizaciones. En URI de redirección (plataforma Web), pegue la dirección que el módulo muestra lista para copiar, con el formato https://glpi.suempresa.com/plugins/nextool/sso/ssologin/callback.

1. Información general: anote el ID de aplicación (cliente) y el ID de directorio (inquilino). En Certificados y secretos, cree el secreto de cliente y copie el valor en el momento: aparece una sola vez. Anote también la fecha de vencimiento.

1. Configuración del token: agregue las notificaciones opcionales email y upn al token de ID. Para asignar el perfil por grupo, use Agregar notificación de grupos, marque Grupos de seguridad y mantenga ID de grupo.

1. Permisos de API: Microsoft Graph email, profile y User.Read, delegados. Sin el consentimiento del administrador, cada usuario confirma el acceso en el primer inicio de sesión.

En GLPI

1. Configurar > SSO Login > Agregar: proveedor Microsoft Entra ID, ID de cliente, secreto e inquilino (el ID de directorio). Para varias organizaciones, use el inquilino organizations con la lista de inquilinos aceptados o, si atiende a cualquier cliente, la opción de aceptar cualquier inquilino.
2. Campo de la primera coincidencia: upn. En el primer acceso, el módulo busca el usuario de GLPI cuyo login es el upn; después, el vínculo usa el identificador fijo de la cuenta en Entra, y cambiar el correo allí no rompe el inicio de sesión.
3. Perfil por grupo: en la aplicación, indique groups como claim de perfiles y cree una regla de asignación de autorizaciones (Administración > Reglas) con el criterio Roles (claim) igual al ID de objeto del grupo de seguridad y la acción de perfil. El perfil es dinámico: quien sale del grupo pierde el perfil en el siguiente inicio de sesión.
4. Pruebe y libere: la pestaña Prueba de la aplicación valida la configuración y las claves del proveedor sin iniciar sesión. Con la aplicación activa, el botón aparece en la pantalla de inicio de sesión. Para saltar esa pantalla, active Ir directo al inicio de sesión SSO en la pestaña Configuración del módulo; el administrador local siempre entra por la dirección de la pantalla de inicio de sesión con ?noAUTO=1 al final.

Dos diferencias de operación frente al oauthsso. Las cuentas locales de GLPI y los administradores no son tomados por un inicio de sesión externo, salvo que usted lo permita en la aplicación. Y la creación automática de usuarios respeta la configuración de GLPI y solo ocurre con correo verificado en un dominio permitido. El Assignment required de Entra, descrito en el paso 5, sigue siendo una buena práctica para restringir quién recibe token.

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

1. App registrations > New registration. Nombre "GLPI"; cuenta admitida: solo tu tenant (single tenant), salvo que atiendas a varias organizaciones.
2. Redirect URI (tipo Web): el callback del plugin - https://glpi.tuempresa.com/plugins/oauthsso/front/callback.php.
3. Certificates & secrets > New client secret. Anota el valor (aparece una sola vez) y, sobre todo, la fecha de caducidad.
4. Token configuration: asegura los claims email y preferred_username (o upn) - GLPI empareja al usuario por ellos.
5. 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_base en 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.

Revisado por el equipo de NexTool Solutions.