Autenticando usuário via LDAP tanto em

domínio único quanto em uma floresta inteira

25 February, 2015 Jonas Artigos, HowTo - Como fazer

HowTo: Autenticação de usuários de forma transparente, buscando o mesmo em

uma floresta e não apenas no domínio principal Active Directory.
EXPLICANDO O CENÁRIO:
Uma empresa que possui 6 unidades (matriz e 5 filiais) interligadas com Active Directory
(VPN, link dedicado ou outra forma…).
Se tem um problema que costuma dar dor de cabeça é a questão das senhas dos
usuários, pois eles vivem esquecendo e confundindo senha de domínio com senha de
sistema, senha de sistema com senha de comunicador e por aí vai.
Nada melhor do que poder integrar tudo que for possível ao controlador de domínio,
unificando as senhas. Ao trocar a senha de domínio, trocam-se todas ao mesmo tempo,
tudo fica automatizado, economizando um tempo enorme com atendimentos para trocas
de senhas e manipulação de grupos e usuários em vários sistemas e softwares.
Vamos usar como exemplo a aplicação OPENFIRE (servidor de chat corporativo), mas
funciona em qualquer outra aplicação que permita autenticação no Active Directory ou
LDAP, testei também no REDMINE, GLPI e em um script de autenticação em PHP que
utilizamos em alguns sistemas.
Integrar o OPENFIRE em um domínio AD/LDAP é relativamente fácil.
Basta que na Configuração de Perfis, seja escolhida a opção Servidor de Diretórios
(LDAP), na sequência especificar o tipo do servidor (no meu caso o AD), o host (que pode
ser o FQDN – desde que possa ser resolvido pelo DNS – ou IP do controlador de domínio,
eu utilizo por IP), a porta LDAP (389 por padrão), a base DN completa (em formato LDAP,
dc=empresa,dc=com,dc=br), o DN completo do Administrador do DC (também em formato
LDAP, cn=administrador,cn=users,dc=empresa,dc=com,dc=br) e por fim a senha do
Administrador do domínio.
No final da configuração, indique no mínimo um usuário do AD para ser administrador do
Openfire (obrigatório).
Isso é o suficiente para fazer com que o OPENFIRE interaja com o DC, lendo a base
LDAP do AD e reconhecendo grupos e usuários do domínio, podendo assim autenticá-los
com suas respectivas senhas do domínio, bastando tão somente habilitar no OPENFIRE
os grupos do AD (o que é o menor dos problemas).
Não vou entrar em detalhes sobre a instalação por não ser este o objetivo deste tutorial,
mas indico este link.
– Servidor Messenger Openfire passo-a-passo no Linux
EXPLICANDO O PROBLEMA
Se eu tivesse apenas 1 domínio eu estaria plenamente satisfeito, mas era exatamente
neste ponto que morava meu problema, já que tenho 6 domínios em relação de confiança
separados fisicamente nas unidades.
Como fazer com que os usuários de todos os domínios da floresta se loguem e se
enxerguem em uma única interface?
Se o AD é capaz de procurar usuários/grupos em toda a floresta de uma única vez,
obviamente existe uma forma de realizar essa consulta via LDAP e consequentemente,
utilizar no OPENFIRE.
E graças a Microsoft TechNet foi possível chegar a solução de como realizar consultas
LDAP tanto em domínios únicos quanto em uma floresta inteira (catálogo global), que era
exatamente o que eu precisava e BINGO! Funcionou exatamente e perfeitamente como
esperado.
Usuários de todos os domínios logando-se em um único servidor integrado a floresta do
AD e se enxergando na lista de contatos uns dos outros, cada um no seu devido grupo.
A partir daí foi só habilitar os grupos de todos os domínios filhos de acordo com a estrutura
organizacional da empresa para que tudo estivesse de acordo com o escopo do projeto.
A SOLUÇÃO
A solução é bem simples, baseia-se parte no nome do domínio e parte em configuração de
porta.
Ou seja, quando se deseja realizar consultas que se estendam por toda a floresta
(domínios pai e filhos) é necessário especificar apenas parte do nome do domínio e alterar
a porta de 389 para 3268, como na figura abaixo.
Perceba que a Base DN é apenas “com.br” em formato LDAP. Apenas o DN do
Administrador do Domínio Pai deve ser completo, pois ele é quem poderá realizar as
consultas em todos os Domínios da floresta.
A diferença entre as portas 389 e 3268 é que a primeira permite a consulta somente na
base local e é necessário que a base DN seja completa (dc=empresa,dc=com,dc=br) e a
segunda permite a consulta em toda a floresta, especificando apenas parte do nome do
domínio (dc=com,dc=br). Abaixo um exemplo com a configuração no REDMINE:
Exemplo:
Eu tenho 6 domínios em relação de confiança:
—empresa1.com.br
——-filial1.empresa1.com.br,
——-filial2.empresa1.com.br,
——-filial3.empresa1.com.br,
——-filial4.empresa1.com.br e
—-empresa2.com.br
No meu caso, tenho 2 domínios com shortnames diferentes (empresa1.com.br e
empresa2.com.br), apenas terminados em com.br.
Ao especificar “dc=com,dc=br” e a porta 3268 estou informando que a consulta deve
abranger todos os domínios da floresta, que contenham .com.br em seus nomes DNS,
dessa forma consigo incluir os domínios com shortnames diferentes (atente-se a esse
detalhe caso os domínios não sejam padronizados).
Se eu não tivesse o domínio empresa2.com.br eu poderia especificar a base DN assim:
“dc=empresa1,dc=com,dc=br” que seria suficiente.
CONCLUSÃO
No final das contas bastou apenas 1 único servidor para atender toda a floresta de forma
efetiva.
Se a função Server 2 Server tivesse funcionado, eu precisaria de 1 servidor Openfire em
cada unidade da empresa, alocando recursos, consumo de energia e mais tempo para
configurar todos os servidores. Além de ter que me preocupar com 6 servidores estarem
online.