NexTool Solutions

SSO no GLPI com o Microsoft Entra ID (Azure AD) elimina senhas locais e centraliza o MFA no seu tenant. Mas a parte que decide entre um login estável e um plantão de madrugada não é clicar em "SAML" no portal: é escolher o protocolo certo para a sua versão do GLPI e prever o que vai expirar.

SAML ou OIDC? A decisão começa na versão do GLPI

O Entra ID entrega SSO por dois protocolos: SAML 2.0 e OpenID Connect (OIDC, sobre OAuth 2.0). O GLPI não fala nenhum dos dois nativamente para login - você precisa de plugin. E aqui está a armadilha que pega quem migra para o GLPI 11: o plugin SAML mais mantido da comunidade, o glpisaml, trava em MAX_GLPI = 10.9.99. O próprio autor declara que ele não é (e não será) compatível com o GLPI 11. Quem chega no 11 esperando "só reinstalar o plugin SAML" bate numa parede.

Na prática, a matriz de decisão que usamos é esta:

Resumo: GLPI 10 aceita SAML (glpisaml) ou OIDC (oauthsso); GLPI 11, hoje, é OIDC via oauthsso. O restante deste guia segue a rota OIDC, que é a que sobrevive à atualização de versão.

1. Registrar a aplicação no Entra ID

Para OIDC, o caminho no portal do Entra ID é App registrations (registro de aplicativo), não a Enterprise Application com "SAML": você registra um app e gera um segredo (client secret).

1. App registrations > New registration. Nome "GLPI"; conta suportada: apenas o seu tenant (single tenant), salvo se você atender múltiplas organizações.
2. Redirect URI (tipo Web): o callback do plugin - https://glpi.suaempresa.com/plugins/oauthsso/front/callback.php.
3. Certificates & secrets > New client secret. Anote o valor (aparece uma única vez) e, principalmente, a data de expiração.
4. Token configuration: garanta os claims email e preferred_username (ou upn) - é por eles que o GLPI casa o usuário.
5. Enterprise Applications > sua app > Properties: Assignment required = Yes. Esse é o seu whitelist real (explico no passo 5).

2. Configurar o GLPI (rota OIDC)

Extraia o plugin em plugins/ (ou marketplace/) e instale pela linha de comando. O erro comum aqui é rodar o console como root: os arquivos gerados ficam com dono errado e o próximo acesso via web quebra por permissão. Rode como o usuário do servidor web:

# GLPI 11: instalar e ativar o plugin como o usuário do Apache (www-data/apache)
php bin/console plugin:install oauthsso
php bin/console plugin:activate oauthsso

# O oauthsso NÃO cria tabela própria: grava tudo em glpi_configs,
# no contexto 'plugin:oauthsso' (tenant id, client id, client secret).

Na tela do plugin (ou direto no glpi_configs), informe o Tenant ID, o Client ID e o Client Secret do app registrado. A tela de login do GLPI passa a exibir o botão "Login with Microsoft".

3. A armadilha do redirect atrás de reverse proxy

Este é o chamado que mais abrimos em implantação: o GLPI está atrás de um Nginx/Apache que termina o TLS e, internamente, enxerga a requisição como http://. Resultado: ele monta o callback com http://, o Entra recebe uma redirect URI que não bate com a cadastrada e devolve redirect_uri_mismatch - ou o usuário entra num loop de redirecionamento. A correção definitiva é fixar a URL base no banco:

-- Forçar a URL base correta (evita callback http:// atrás do proxy)
UPDATE glpi_configs
SET value = 'https://glpi.suaempresa.com'
WHERE context = 'core' AND name = 'url_base';

-- O GLPI cacheia a config: limpe o cache após alterar
-- php bin/console cache:clear

Confirme também que o proxy repassa o esquema real - por exemplo, RequestHeader set X-Forwarded-Proto "https" no Apache, ou proxy_set_header X-Forwarded-Proto $scheme; no Nginx. URL base correta somada ao header correto encerra o loop.

4. JIT: quando o usuário loga mas não vê nada

O provisionamento Just-in-Time cria o usuário no primeiro login - mas não atribui perfil. O sintoma é clássico: a autenticação passa, o usuário entra e cai numa tela vazia ("nenhum perfil atribuído"). Na sustentação, esse é o segundo motivo de ticket logo depois de "SSO configurado". O diagnóstico é uma linha de SQL:

-- Usuários de SSO (autenticação externa) que ficaram SEM perfil:
-- logam, mas caem numa tela vazia.
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;

A saída dá exatamente quem precisa de perfil. A solução escalável é uma regra de atribuição de autorizações (Administração > Regras) que conceda um perfil padrão a quem chega pelo SSO, em vez de fazer isso na mão a cada novo usuário.

5. O whitelist real fica no Entra, não no GLPI

Detalhe que só quem opera descobre na marra: o oauthsso cria o usuário no primeiro login e ignora a flag is_users_auto_add do core do GLPI. Ou seja, qualquer conta válida do tenant que chegue ao callback vira usuário do GLPI. Não adianta procurar a trava dentro do GLPI - ela não existe no plugin. O controle real é o Assignment required = Yes do passo 1: com ele ligado, o Entra só emite token para quem você atribuiu explicitamente à aplicação. Esse é o seu whitelist, gerenciado no tenant.

Um adendo sobre grupos: se você quer mapear grupo do AD para perfil do GLPI, saiba que o Entra manda os grupos como GUID, não como nome legível. Ou você usa App Roles (nomes que você mesmo define) ou traduz o GUID no mapeamento. Esperar "TI" e receber 7a2f... é a terceira surpresa comum.

Checklist de sustentação: o que quebra em produção

SSO não é "configurou, esqueceu". Na nossa operação, todo ambiente com SSO entra no inventário com estes itens monitorados, porque são os que derrubam o login sem ninguém ter mexido em nada:

• Expiração do client secret (OIDC) ou do certificado de assinatura (SAML): é a causa número 1 de "o SSO parou do nada". O secret do Entra expira (entre 6 e 24 meses); registre a data e renove antes.
• Relógio do servidor (SAML): a assertion tem janela de validade; se o horário derivar, o GLPI rejeita com "assertion not yet valid". Mantenha NTP/chrony ativo (timedatectl status).
• Rotação de URL/domínio: mudou o domínio do GLPI? Atualize a redirect URI no Entra e o url_base no banco no mesmo deploy.
• Fallback local: mantenha ao menos uma conta local de administrador ativa. Se o IdP cair, você ainda entra pelo login tradicional do GLPI.

Na NexTool, configuramos e sustentamos SSO (Entra ID, Google Workspace e LDAP/AD) em ambientes GLPI de clientes, com o inventário de expirações e o fallback documentados - justamente para o login não virar plantão. Se quiser esse desenho aplicado ao seu ambiente, fale com a gente sobre sustentação de GLPI.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.