Autenticando usuário via LDAP tanto em domínio único quanto em uma floresta inteira

Prévia do material em texto

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.