Lidar com as solicitações dos usuários de uma empresa não é uma tarefa fácil, nem sempre temos o controle do que foi pedido e nem de como isso foi resolvido. Manter um sistema de chamados como o GLPI é a melhor maneira para atender bem as solicitações dos usuários e documentar o processo de atendimento.

Segue uma catalogação de vídeo tutorias do GLPI que podem ajuda-lo a deixar a ferramenta cada vez melhor. Aos poucos vou atualizando este post… Read More

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.