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.
