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:
| Plugin | Protocolo | GLPI 10 | GLPI 11 | JIT | Observação |
|---|---|---|---|---|---|
glpisaml (DonutsNL) | SAML 2.0 | Sim | Não (limitado em 10.9.99) | Sim | Sucessor mantido do phpsaml |
phpsaml (derricksmith) | SAML 2.0 | Legado | Não | Sim | Parado desde 2022; evitar em projetos novos |
oauthsso | OpenID Connect | Sim | Sim | Sim | Via pragmática no GLPI 11; o Entra tem OIDC nativo |
| SSO Login (módulo NexTool) | OpenID Connect | Não | Sim (também no GLPI 12) | Opcional | Multi-tenant, perfil pelo grupo do Entra, entrada direta pelo login da Microsoft |
Resumo: GLPI 10 aceita SAML (glpisaml) ou OIDC (oauthsso); GLPI 11 e 12 usam OIDC. Para o 11 e o 12, o caminho que recomendamos é o módulo SSO Login da NexTool, descrito na secção seguinte. O oauthsso, que a Teclib distribui com a subscrição GLPI Network, mantém-se como alternativa nos passos 1 a 5. As partes de proxy inverso, JIT e manutenção valem para os dois.
O caminho recomendado no GLPI 11 e 12: módulo SSO Login
O SSO Login é o módulo da NexTool para iniciar sessão com o Microsoft Entra ID, o Google e qualquer fornecedor OpenID Connect (Keycloak, Okta). Resolve os pontos que mais geram pedidos com o oauthsso: serve várias organizações no mesmo GLPI (multi-tenant, para MSP), atribui o perfil pelo grupo de segurança do Entra logo no primeiro início de sessão, respeita a criação automática de utilizadores do GLPI, termina também a sessão na Microsoft ao sair e pode levar o utilizador diretamente para o login da Microsoft, sem passar pelo ecrã do GLPI.
No Entra ID
- Registos de aplicações > Novo registo. Escolha o tipo de conta: um único inquilino para a sua empresa ou vários inquilinos se o GLPI serve clientes de outras organizações. Em URI de redirecionamento (plataforma Web), cole o endereço que o módulo mostra pronto a copiar, no formato
https://glpi.suaempresa.pt/plugins/nextool/sso/ssologin/callback.

- Descrição geral: anote o ID da aplicação (cliente) e o ID do diretório (inquilino). Em Certificados e segredos, crie o segredo do cliente e copie o valor de imediato: só aparece uma vez. Anote também a data de expiração.

- Configuração do token: acrescente as declarações opcionais
emaileupnao token de ID. Para atribuir o perfil pelo grupo, use Adicionar declaração de grupos, marque Grupos de segurança e mantenha ID do Grupo.


- Permissões de API: Microsoft Graph
email,profileeUser.Read, delegadas. Sem o consentimento do administrador, cada utilizador confirma o acesso no primeiro início de sessão.
No GLPI
- Configurar > SSO Login > Adicionar: fornecedor Microsoft Entra ID, ID do cliente, segredo e inquilino (o ID do diretório). Para várias organizações, use o inquilino
organizationscom a lista de inquilinos aceites ou, se serve qualquer cliente, a opção de aceitar qualquer inquilino. - Campo da primeira correspondência:
upn. No primeiro acesso, o módulo procura o utilizador do GLPI cujo login é o upn; depois disso, a ligação usa o identificador fixo da conta no Entra, e mudar o e-mail lá não quebra o início de sessão. - Perfil pelo grupo: na aplicação, indique
groupscomo claim de perfis e crie uma regra de atribuição de autorizações (Administração > Regras) com o critério Roles (claim) igual ao ID de objeto do grupo de segurança e a ação de perfil. O perfil é dinâmico: quem sai do grupo perde o perfil no início de sessão seguinte. - Teste e liberte: o separador Teste da aplicação valida a configuração e as chaves do fornecedor sem iniciar sessão. Com a aplicação ativa, o botão aparece no ecrã de início de sessão. Para saltar esse ecrã, ligue Ir diretamente para o login SSO no separador Configurações do módulo; o administrador local entra sempre pelo endereço do ecrã de início de sessão com
?noAUTO=1no fim.
Duas diferenças de operação em relação ao oauthsso. As contas locais do GLPI e os administradores não são assumidos por um início de sessão externo, a não ser que o permita na aplicação. E a criação automática de utilizadores respeita a configuração do GLPI e só acontece com e-mail verificado num domínio permitido. O Assignment required do Entra, descrito no passo 5, continua a ser uma boa prática para restringir quem recebe token.
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).
- App registrations > New registration. Nome "GLPI"; conta suportada: apenas o seu tenant (single tenant), a não ser que atenda várias organizações.
- Redirect URI (tipo Web): o callback do plugin -
https://glpi.suaempresa.com/plugins/oauthsso/front/callback.php. - Certificates & secrets > New client secret. Anote o valor (aparece uma única vez) e, sobretudo, a data de validade.
- Token configuration: garanta os claims
emailepreferred_username(ouupn) - é por eles que o GLPI associa o utilizador. - 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_basena 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.
Revisto pela equipa NexTool Solutions.