NexTool Solutions

O SSO no GLPI com o Microsoft Entra ID (Azure AD) elimina palavras-passe locais e centraliza o MFA no seu tenant. Mas a parte que decide entre um início de sessão estável e uma noite de piquete 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 o início de sessão - precisa de um plugin. E aqui está a armadilha que apanha quem migra para o GLPI 11: o plugin SAML mais mantido da comunidade, o glpisaml, está limitado em MAX_GLPI = 10.9.99. O próprio autor declara que não é (nem será) compatível com o GLPI 11. Quem chega ao 11 à espera de "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 resto deste guia segue a via OIDC, que é a que sobrevive à atualização de versão.

1. Registar a aplicação no Entra ID

Para OIDC, o caminho no portal do Entra ID é App registrations (registo de aplicações), não a Enterprise Application com "SAML": regista uma app e gera um segredo (client secret).

1. App registrations > New registration. Nome "GLPI"; conta suportada: apenas o seu tenant (single tenant), a não ser que atenda várias 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, sobretudo, a data de validade.
4. Token configuration: garanta os claims email e preferred_username (ou upn) - é por eles que o GLPI associa o utilizador.
5. Enterprise Applications > a sua app > Properties: Assignment required = Yes. Esta é a sua lista de permitidos real (explicada no passo 5).

2. Configurar o GLPI (via OIDC)

Extraia o plugin em plugins/ (ou marketplace/) e instale pela linha de comandos. O erro comum aqui é correr a consola como root: os ficheiros gerados ficam com o dono errado e o acesso web seguinte quebra por permissões. Corra-a com o utilizador do servidor web:

# GLPI 11: instalar e ativar o plugin como o utilizador 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: guarda tudo em glpi_configs,
# no contexto 'plugin:oauthsso' (tenant id, client id, client secret).

No ecrã do plugin (ou diretamente no glpi_configs), indique o Tenant ID, o Client ID e o Client Secret da app registada. O ecrã de início de sessão do GLPI passa a mostrar o botão "Login with Microsoft".

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

Este é o pedido que mais abrimos na implementação: o GLPI está atrás de um Nginx/Apache que termina o TLS e, internamente, vê o pedido como http://. Resultado: monta o callback com http://, o Entra recebe uma redirect URI que não corresponde à registada e devolve redirect_uri_mismatch - ou o utilizador entra num ciclo de redirecionamento. A correção definitiva é fixar o URL base na base de dados:

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

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

Confirme também que o proxy reencaminha 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 correto mais o header correto terminam o ciclo.

4. JIT: quando o utilizador inicia sessão mas não vê nada

O aprovisionamento Just-in-Time cria o utilizador no primeiro início de sessão - mas não atribui perfil. O sintoma é clássico: a autenticação passa, o utilizador entra e cai num ecrã vazio ("nenhum perfil atribuído"). Na sustentação, este é o segundo motivo de pedido logo a seguir a "SSO configurado". O diagnóstico é uma linha de SQL:

-- Utilizadores de SSO (autenticação externa) que ficaram SEM perfil:
-- iniciam sessão, mas caem num ecrã vazio.
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 predefinido a quem chega pelo SSO, em vez de o fazer à mão a cada novo utilizador.

5. A lista de permitidos real está no Entra, não no GLPI

Detalhe que só quem opera descobre a custo: o oauthsso cria o utilizador no primeiro início de sessão e ignora a flag is_users_auto_add do core do GLPI. Ou seja, qualquer conta válida do tenant que chegue ao callback torna-se utilizador do GLPI. Não vale a pena procurar o bloqueio dentro do GLPI - ele não existe no plugin. O controlo real é o Assignment required = Yes do passo 1: com ele ativo, o Entra só emite token a quem tiver atribuído explicitamente à aplicação. Essa é a sua lista de permitidos, gerida no tenant.

Uma nota sobre grupos: se quer mapear um grupo do AD para um perfil do GLPI, saiba que o Entra envia os grupos como GUID, não como nome legível. Ou usa App Roles (nomes que você 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

O SSO não é "configurou, esqueceu". Na nossa operação, todo o ambiente com SSO entra no inventário com estes itens monitorizados, porque são os que deitam abaixo o início de sessão sem ninguém ter mexido em nada:

• Validade 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); registe a data e renove com antecedência.
• Relógio do servidor (SAML): a assertion tem janela de validade; se a hora derivar, o GLPI rejeita com "assertion not yet valid". Mantenha o 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 na base de dados no mesmo deploy.
• Fallback local: mantenha pelo menos uma conta local de administrador ativa. Se o IdP cair, ainda entra pelo início de sessão 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 validades e o fallback documentados - precisamente para o início de sessão não virar piquete. Se quiser este desenho aplicado ao seu ambiente, fale connosco sobre suporte e sustentação de GLPI.

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