Início de sessão SSO no GLPI com Azure AD (Entra ID): guia completo

SSO no GLPI com Microsoft Entra ID (Azure AD): SAML no GLPI 10, OIDC no GLPI 11 e 12 com o módulo SSO Login ou o oauthsso, perfil pelo grupo do Entra, provisionamento JIT e a lista de verificação que evita que o login caia em produção.

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:

PluginProtocoloGLPI 10GLPI 11JITObservação
glpisaml (DonutsNL)SAML 2.0SimNão (limitado em 10.9.99)SimSucessor mantido do phpsaml
phpsaml (derricksmith)SAML 2.0LegadoNãoSimParado desde 2022; evitar em projetos novos
oauthssoOpenID ConnectSimSimSimVia pragmática no GLPI 11; o Entra tem OIDC nativo
SSO Login (módulo NexTool)OpenID ConnectNãoSim (também no GLPI 12)OpcionalMulti-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

  1. 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.
Registo de aplicação no Microsoft Entra ID com vários inquilinos, permitir todos os inquilinos e o URI de redirecionamento do SSO Login
Registo da aplicação para várias organizações, com o URI de redirecionamento copiado do módulo.
  1. 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.
Descrição geral da aplicação no Entra ID com os campos ID da aplicação, ID do objeto e ID do diretório
Os ID da aplicação e do diretório vão para o registo da aplicação no GLPI (desfocados na imagem).
  1. Configuração do token: acrescente as declarações opcionais email e upn ao 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.
Painel de edição da declaração de grupos no Entra ID com Grupos de segurança marcado e ID do Grupo selecionado
A declaração de grupos envia os ID de objeto dos grupos de segurança do utilizador.
Configuração do token no Entra ID com as declarações email, groups e upn
Resultado: email, upn e groups no token de ID.
  1. Permissões de API: Microsoft Graph email, profile e User.Read, delegadas. Sem o consentimento do administrador, cada utilizador confirma o acesso no primeiro início de sessão.

No GLPI

  1. 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 organizations com a lista de inquilinos aceites ou, se serve qualquer cliente, a opção de aceitar qualquer inquilino.
  2. 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.
  3. Perfil pelo grupo: na aplicação, indique groups como 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.
  4. 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=1 no 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).

  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.


Revisto pela equipa NexTool Solutions.

Perguntas Frequentes

Sim, por OIDC (OpenID Connect), não por SAML. O plugin SAML mais mantido, o glpisaml, está limitado a MAX_GLPI 10.9.99. No 11 e no 12, os caminhos são o módulo SSO Login da NexTool, que recomendamos, e o oauthsso, distribuído pela Teclib com a subscrição GLPI Network.

No GLPI 10, ambos funcionam: SAML via glpisaml, OIDC via oauthsso. No GLPI 11 e 12, use OIDC, porque os plugins SAML não acompanharam as novas versões. O OIDC também é mais simples de operar com o Entra, que expõe OpenID Connect nativamente.

Sim. O núcleo do GLPI não faz login SAML/OIDC nativo (suporta LDAP/AD, CAS, x509 e 'autenticação enviada no cabeçalho HTTP'). Para o Entra ID: glpisaml (SAML, só GLPI 10), oauthsso (OIDC) ou o módulo SSO Login da NexTool (OIDC, GLPI 11 e 12).

Acrescente a declaração de grupos (Grupos de segurança, ID do Grupo) ao registo da aplicação. No módulo SSO Login, indique groups como claim de perfis e crie uma regra de atribuição de autorizações com o ID de objeto do grupo: o perfil é atribuído logo no primeiro início de sessão e retirado quando o utilizador sai do grupo.

No Entra, com Enterprise Applications > Properties > Assignment required = Yes: só quem atribui à aplicação recebe token. É essencial no oauthsso, que cria o utilizador no primeiro início de sessão e ignora o is_users_auto_add do núcleo. O módulo SSO Login respeita essa configuração do GLPI e só cria utilizadores com e-mail verificado num domínio permitido.

É o JIT sem perfil: o utilizador é criado, mas sem perfil atribuído. Diagnostique com um LEFT JOIN entre glpi_users e glpi_profiles_users à procura de quem não tem ligação, e configure uma regra de atribuição de autorizações (Administração > Regras) para dar um perfil predefinido a quem chega pelo SSO.

Quase sempre é expiração: o client secret do OIDC (ou o certificado de assinatura no SAML) expirou, e expiram entre 6 e 24 meses no Entra. Outras causas: url_base com http:// atrás de proxy (redirect_uri_mismatch) e relógio do servidor dessincronizado no SAML. Registe a data de expiração e mantenha o NTP ativo.

Precisa de ajuda?