Ligámos um Active Directory de laboratório a um GLPI 11: 7 utilizadores importados em 1,4 segundos, cada um com o perfil certo pelo grupo do AD e início de sessão com a palavra-passe da rede. Até aqui, tudo como esperado. O problema surgiu quando desvinculámos um funcionário no AD: no GLPI, ele continuou ativo, com o mesmo perfil. E alterar a configuração depois não resolveu, porque o GLPI só aplica a regra de desvinculação na primeira vez que deteta a saída.
Usa o Microsoft Entra ID (Azure AD) e quer início de sessão único no navegador? Veja SSO com Microsoft Entra ID no GLPI. Este artigo trata do AD local, por LDAP.
O que a integração com o AD faz
- Início de sessão com a palavra-passe da rede: o utilizador entra no GLPI com o mesmo nome de utilizador e palavra-passe do Windows. A palavra-passe nunca é guardada no GLPI.
- Importação dos dados: nome, apelido, e-mail, telefone, cargo e outros campos vêm do AD.
- Perfil pelo grupo: as regras de autorização atribuem o perfil e a entidade conforme o grupo do AD (técnico, gestor, utilizador).
- Sincronização: as alterações no AD, como a mudança de telefone, de cargo ou a desvinculação, chegam ao GLPI pela sincronização agendada.
O laboratório
Montámos um controlador de domínio Samba (compatível com Active Directory) com o domínio ACME.TEST, a empresa fictícia Acme, três grupos (GLPI-Tecnicos, GLPI-Gestores, GLPI-Usuarios) e oito utilizadores: sete ativos e um desativado numa OU de desvinculados. Do outro lado, um GLPI 11.0.7 de testes.
Passo 1: o diretório LDAP
Em Configurar > Autenticação > Diretórios LDAP:
| Campo | O que usámos | Porquê |
|---|---|---|
| Servidor e porta | o controlador de domínio, 389 (636 com LDAPS) | Em produção, prefira LDAPS ou StartTLS |
| BaseDN | OU=Acme,DC=acme,DC=test |
Comece na OU das pessoas, não na raiz do domínio |
| RootDN e palavra-passe | uma conta de serviço só de leitura | Nunca a conta de um administrador |
| Filtro da conexão | (&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) |
Só pessoas e só contas ativas |
| Campo de login | samaccountname |
O nome de utilizador curto do Windows |
| Campo de sincronização | objectguid |
Não muda se o utilizador mudar de nome ou de OU |
| Grupos | tipo de pesquisa "Em usuários", atributo memberof |
Para usar o grupo do AD nas regras |
O botão Testar verifica a ligação antes de importar o que quer que seja.
Passo 2: o perfil pelo grupo do AD
Em Administração > Regras > Regras para associar permissões a um usuário, uma regra por grupo:
Se o utilizador veio deste diretório e o memberOf contém |
Recebe o perfil | Na entidade |
|---|---|---|
CN=GLPI-Tecnicos, |
Technician | a da empresa |
CN=GLPI-Gestores, |
Supervisor | a da empresa |
CN=GLPI-Usuarios, |
Self-Service | a da empresa |
As autorizações atribuídas por regra são dinâmicas: se a pessoa sair do grupo no AD, o perfil é retirado na sincronização seguinte.
Passo 3: importar e sincronizar
Pelo ecrã (Importar novos usuários) ou pela linha de comandos, que é o que serve para agendar:
php bin/console ldap:synchronize_users --ldap-server-id=1 --deleted-user-strategy=1,0,1
No laboratório, a importação trouxe os 7 utilizadores ativos em 1,4 segundos, e o desativado ficou de fora pelo filtro. O nome, o e-mail e o telefone vieram do AD, e cada um recebeu o perfil do seu grupo. O início de sessão com a palavra-passe do AD funcionou, e com a palavra-passe errada foi recusado.
O que aconteceu quando desvinculámos um funcionário
Desativámos um utilizador no AD e executámos a sincronização, primeiro com a configuração predefinida.
| Teste | Resultado no GLPI |
|---|---|
| Desvinculado no AD, sincronização predefinida | O GLPI deteta a saída, mas não faz nada: utilizador ativo, mesmo perfil |
| Mesmo utilizador, sincronização seguinte com "desativar" | Nada muda: ele já tinha sido marcado como excluído do LDAP |
| Outro utilizador desvinculado, já com "desativar" na primeira sincronização | Utilizador desativado e perfis dinâmicos retirados |
| Utilizador reativado no AD, sincronização com "ativar" | Volta a ficar ativo |
Duas conclusões:
- A predefinição do GLPI é não fazer nada com quem sai do AD (estratégia "0,0,0"). Um ex-funcionário continua com conta ativa no GLPI até alguém reparar.
- A estratégia aplica-se no momento em que o GLPI deteta a saída. Se a primeira sincronização correu com a predefinição, alterar a configuração depois não apanha quem já foi marcado. É preciso tratar estes utilizadores manualmente.
Configure a ação para utilizador excluído do LDAP antes da primeira sincronização (em Configurar > Autenticação, ou com --deleted-user-strategy no comando). A combinação que recomendamos é "1,0,1": desativar a conta, manter os grupos (para o histórico) e retirar as autorizações dinâmicas.
Para o regresso, a estratégia de restauro "3" reativa a conta quando a pessoa é reativada no AD.
Um pormenor sobre o perfil predefinido
Todos os utilizadores importados receberam também o perfil predefinido do GLPI (no nosso caso, Self-Service), além do perfil da regra. Para quem é técnico, isto não atrapalha, mas aparece na troca de perfil. Se não o quiser, reveja qual é o perfil predefinido do GLPI antes de importar.
Checklist
- Conta de serviço só de leitura para o RootDN.
- LDAPS ou StartTLS em produção.
- BaseDN na OU das pessoas e filtro que exclui contas desativadas.
objectguidcomo campo de sincronização.- Regras de autorização por grupo do AD, com entidade definida.
- Ação para utilizador excluído do LDAP configurada antes da primeira sincronização ("1,0,1").
- Sincronização agendada (cron) com
ldap:synchronize_users, pelo menos diária. - Teste com um utilizador fictício: criar, mudar de grupo, desvincular e reativar no AD, e verificar o GLPI em cada passo.
Precisa de ajuda com a integração ou com a auditoria de acessos? Fale com a equipa. Para perceber perfis e permissões, veja perfis e permissões no GLPI.
Teste da NexTool em 4 de outubro de 2026: controlador de domínio Samba (compatível com Active Directory) com utilizadores fictícios e GLPI 11.0.7 de testes. O laboratório foi apagado no final. Comportamento da sincronização verificado no próprio comando do GLPI.
Comentários
Os comentários deste post vêm do GitHub (giscus). Ao carregá-los, o seu navegador liga-se ao GitHub, que recebe o seu endereço IP e pode gravar cookies próprios.
Para carregar automaticamente, ative os cookies funcionais