Ligamos um Active Directory de laboratório a um GLPI 11: 7 usuários importados em 1,4 segundo, cada um com o perfil certo pelo grupo do AD e login com a senha da rede. Até aqui, tudo como esperado. O problema apareceu quando desligamos um funcionário no AD: no GLPI, ele continuou ativo, com o mesmo perfil. E mudar a configuração depois não resolveu, porque o GLPI só aplica a regra de desligamento na primeira vez que percebe a saída.
Usa Microsoft Entra ID (Azure AD) e quer login ú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
- Login com a senha da rede: o usuário entra no GLPI com o mesmo login e senha do Windows. A senha nunca é guardada no GLPI.
- Importação dos dados: nome, sobrenome, e-mail, telefone, cargo e outros campos vêm do AD.
- Perfil pelo grupo: regras de autorização dão o perfil e a entidade conforme o grupo do AD (técnico, gestor, usuário).
- Sincronização: mudanças no AD, como troca de telefone, cargo ou desligamento, chegam ao GLPI pela sincronização agendada.
O laboratório
Montamos 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 usuários: sete ativos e um desativado numa OU de desligados. 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 usamos | Por quê |
|---|---|---|
| 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 senha | 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 login curto do Windows |
| Campo de sincronização | objectguid |
Não muda se o usuário trocar 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 confere a conexão antes de importar qualquer coisa.
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 usuário 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 dadas por regra são dinâmicas: se a pessoa sair do grupo no AD, o perfil sai na próxima sincronização.
Passo 3: importar e sincronizar
Pela tela (Importar novos usuários) ou pela linha de comando, que é o que vale 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 usuários ativos em 1,4 segundo, e o desativado ficou de fora pelo filtro. Nome, e-mail e telefone vieram do AD, e cada um recebeu o perfil do seu grupo. O login com a senha do AD funcionou, e com a senha errada foi negado.
O que aconteceu quando desligamos um funcionário
Desativamos um usuário no AD e rodamos a sincronização, primeiro com a configuração padrão.
| Teste | Resultado no GLPI |
|---|---|
| Desligado no AD, sincronização padrão | O GLPI detecta a saída, mas não faz nada: usuário ativo, mesmo perfil |
| Mesmo usuário, sincronização seguinte com "desabilitar" | Nada muda: ele já tinha sido marcado como excluído do LDAP |
| Outro usuário desligado, já com "desabilitar" na primeira sincronização | Usuário desativado e perfis dinâmicos removidos |
| Usuário reativado no AD, sincronização com "habilitar" | Volta a ficar ativo |
Duas conclusões:
- O padrã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 perceber.
- A estratégia vale no momento em que o GLPI detecta a saída. Se a primeira sincronização rodou com o padrão, mudar a configuração depois não pega quem já foi marcado. É preciso tratar esses usuários à mão.
Configure a ação para usuário 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": desabilitar a conta, manter os grupos (para o histórico) e remover as autorizações dinâmicas.
Para a volta, a estratégia de restauração "3" reabilita a conta quando a pessoa é reativada no AD.
Um detalhe sobre o perfil padrão
Todos os usuários importados receberam também o perfil padrão do GLPI (no nosso caso, Self-Service), além do perfil da regra. Para quem é técnico, isso não atrapalha, mas aparece na troca de perfil. Se não quiser, revise qual é o perfil padrão 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 usuário 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 usuário fictício: criar, mudar de grupo, desligar e reativar no AD, e conferir o GLPI a cada passo.
Precisa de ajuda com a integração ou com a auditoria de acessos? Fale com a equipe. Para entender 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 usuários fictícios e GLPI 11.0.7 de testes. O laboratório foi apagado ao final. Comportamento da sincronização conferido no próprio comando do GLPI.
Comentários
Os comentários deste post vêm do GitHub (giscus). Ao carregá-los, seu navegador se conecta ao GitHub, que recebe seu endereço IP e pode gravar cookies próprios.
Para carregar automaticamente, ative os cookies funcionais