Introdução

A necessidade de se manter uma base centralizada de informações referentes a objetos de uma rede, é uma questão de boa prática de Administração de Redes de Computadores.

Tal cenário se torna mais desejado quando esta rede é composta por servidores com sistemas operacionais diferentes onde a comunicação entre eles não é uma fator trivial.

Com esta perspectiva  de interoperabilidade entre sistemas distintos, é possível destacar algumas tecnologias que tem como propósito mitigar problemas de comunicação entre redes Windows e Linux; dentre elas uma que se destaca é o Samba. O Samba permite justamente essa interoperabilidade entre o Windows e Linux, por meio do protocolo SMB/CIFS.

Embora o Samba permita esta comunicação entre os sistemas operacionais citados, ele por si só não permite (até a versão 3.x), que seja feita uma total integração com o diretório ativo do Windows. Para isso precisaremos de outras duas tecnologias, que são o Kerberos e o LDAP.

Em termos práticos, ao final desse artigo poderemos ter uma rede com as seguintes características:

• Um servidor Windows 2003, controlador de domínio com Active Directory (AD);
• Um segundo servidor Windows 2003 que possuí toda a cópia do Active Directory(AD);
• Um servidor Linux Debian Etch, que terá o Samba 3.0.

A intenção prática desse artigo é que ao final, o servidor Linux faça parte do domínio, e que possam ser configurados permissões via Samba utilizando os usuários do servidor Windows.

Agora você pergunta: para que isto?

Eu te respondo: atualmente os clientes da minha rede utilizam tanto 'Perfil Mandatory' quanto 'Perfil Móvel'. Esses perfis estão alocados em compartilhamentos no servidores Windows. Ou seja, quando um dos servidores Windows cair, o domínio continuará funcionando, pois os dois estão configurados para balancear carga; e na falta de um, o outro assume todo o domínio.

Isso funcionaria perfeitamente caso meus perfis fossem locais, pois ele necessitaria apenas de se logar no domínio e buscar o perfil no diretório local de cada cliente.

Entretanto, quando o perfil é móvel, ele já não consegue buscar tais perfis. Para resolver parcialmente o problema, todos os perfis serão migrados para o Servidor Linux, e é necessário então que ele reconheça as permissões e usuários do AD. Sendo assim, quando um dos servidores Windows cair, o domínio continuará funcionando de forma transparente aos usuários.

Pois bem, chega de história e vamos por a mão na massa.

Instalação - softwares requeridos

Pré-requisitos:

• Partirei da premissa que já temos um Windows Server 2003 instalado e com AD funcionando normalmente, com seus perfis móveis e mandatórios perfeitamente configurados.
• Linux Debian ou derivado, com o Samba instalado (detalhes da instalação do samba em LINK).
• Estações Windows já cadastradas e logando no AD.

Pacotes a serem instalados:

Kerberos: instalar o pacote Kerberos User:

# apt-get install krb5-user

Configure o arquivo "/etc/krb5.conf", especificando o nome do domínio:


Um detalhe que deve ser observado, é que o Kerberos exige que o nome do domínio e servidores sejam escritos com LETRAS MAIÚSCULAS, conforme mostra o arquivo de configuração anterior.

Para testar se está sendo feito a autenticação no AD, digite o seguinte comando especificando um usuário qualquer do domínio e digite a senha:

# kinit Administrator

Caso os relógios dos servidores não estiverem sincronizados, aparecerá a seguinte mensagem de erro:

"Clock skew too great while getting initial credentials"

Para corrigir isso é necessário instalar um sistema de sincronização que mantenha os relógios dos Sistemas Operacionais envolvidos sincronizados. Como solução parcial, os relógios podem ser acertados manualmente para ficarem com no máximo um minuto de discrepância.

Esse valor pode ser configurado no arquivo "krb5.conf", adicionando o parâmetro "clockskew = 60", onde o valor numérico é a tolerância em segundos da diferença entre os clocks.

A melhor opção é sincronizar por meio do comando 'ntpdate' o horário exato com o controlador de domínio:

# apt-get install ntpdate
# ntpdate 10.117.0.240

Depois dos relógios devidamente sincronizados, o comando 'kinit' não retornará nenhuma mensagem de erro e nem de acerto, como se fosse um comando ignorado pelo Linux. Isto é um bom sinal, pois mostra que o servidor Linux autenticou perfeitamente com o usuário testado.