Integração do Servidor Linux Samba com Active Directory do Windows Server



Autor: Fábio Cordeiro <fabioled at gmail.com>

Introdução e Instalação

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:

[libdefaults]
default_realm = DOMINIO.BR
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
clockskew = 300
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
fcc-mit-ticketflags = true
[realms]
DOMINIO.BR = {
kdc = 10.117.0.240
admin_server = 10.117.0.240
}

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.

LDAP, Samba e Configurações

LDAP (Lightweight Directory Access Protocol)

Para o que precisamos nesta instalação é bastante simples, basta instalar padrão e setar as informações desejadas no momento da instalação com o nome do domínio e do servidor de AD.
# apt-get install slapd
Depois de setar as informações, definir uma senha de Administrador do LDAP e já estará tudo funcionando.

SAMBA SMB/CIFS

Maiores detalhes da instalação do Samba podem ser encontrados aqui no VOL ou no meu Blog: fabioled.blog.com – Servidor Samba
Depois de instalado, adicionar os parâmetros conforme abaixo:
Obs.: Os atributos e parâmetros abaixo listados, são os necessários à integração proposta para este artigo, demais configurações do Samba devem ser vistas no tutorial sobre o assunto no link acima referido.

[global]
unix charset = LOCALE
realm=DOMINIO.BR
workgroup = DOMINIO
server string = %h Servidor LINUX
security=domain
password server=*
winbindseparator=+
log level = 1
winbind uid=10000-20000
winbind gid=10000-20000
winbind enum users=yes
winbind enum groups=yes
template homedir=/tmp
template shell=/bin/false

Para testar algum erro de configuração do arquivo “smb.conf”, entrar com o seguinte comando:
# testeparm
Depois de testado, reinicie os serviços de winbindo e samba com os seguintes comandos:
# /etc/init.d/winbind stop
# /etc/init.d/samba restart
# /etc/init.d/winbind start

Configurações adicionais

Para continuar a instalação, deve ser configurado o arquivo “/etc/nsswitch.conf”, responsável por ordenar as buscas dos usuários, grupos e nomes de máquinas na estação Linux, conforme o exemplo:
# vim /etc/nsswitch.conf

passwd: files winbind ldap
group: files winbind ladp
shadow: files winbind ldap
hosts: files dns wins
networks: files dns
protocols: db files
services: db files
ethers: db files
rpc: db files
netmask: files
netgroup: files
publickey: files
bootparams: files
automount: files
aliases: files

Agora o Linux esta quase preparado para ser membro do domínio. Para isto vamos configurar o arquivo “/etc/hosts” para que evite eventuais problemas de DNS no momento da inserção no domínio.
# vim /etc/hosts
E adicionar o IP da máquina Linux seguida do Nome, Domínio e o nome novamente.
Exemplo: 10.117.0.1 linux.dominio linux
Procure também pelo arquivo de configuração de hosts do Windows Server e adicione referência ao IP dos servidores Windows e Linux envolvidos na configuração. O arquivo de hosts do Windows fica em: “C:\WINDOWS\drivers\etc”, abra-o com o bloco de notas e adicione o IP seguido do nome com ponto e domínio.
Exemplo: 10.117.0.240 linux.dominio.br
Agora vamos para o comando de inserção no domínio propriamente dito:
# net ads join -Uadministrator%senha
Se tudo ocorrer bem, será retornado a seguinte mensagem:

Using short domain name — DOMINIO
Joined ‘LINUX’ to realm ‘DOMINIO.LOCAL’

Para ter certeza que tudo funcionou, verifique se o nome do Servidor Linux esta sendo exibido na lista de computadores no AD.
Agora os próximos testes serão em relação à comunicação com grupos e usuários entre o Linux e o Servidor de Active Directory.
Para mostrar todos os usuários do domínio:
# wbinfor -u
Mostrar os grupos:
# wbinfo -g
Demonstrar se a comunicação entre o AD e o Kerberos está ok:
# wbinfo -t
Retorno esperado:

“checking the trust secret via RPC calls succeeded”

E finalmente, o comando para mostrar os usuários bem como seus respectivos diretórios e bash:
# getent passwd
Será apresentada uma lista no terminal com todos os grupos, usuários e caminhos de bash gerados pela nossa configuração no Samba.

Utilização e Considerações finais

Utilização

Neste momento estamos aptos a editar o arquivo “smb.conf” e configurar permissões para usuários do domínio com a base do Active Directory.
Para isso devemos criar um diretório no servidor Samba e setar permissões no sistema de arquivos e no arquivo de configuração “smb.conf”:
# mkdir /mnt/dados/financeiro
# chmod – R 775 /mnt/dados/financeiro

Editar arquivo “smb.conf” conforme exemplo:

[financeiro]
path = /mnt/dados/financeiro
quest ok = no
read only = no
valid users = @DOMINIO+financeiro=r @DOMINIO+financeiro+rw @BUILTIN+administrators
read list = @DOMINIO+financeiro+r @BUILTIN+administrators
wrire list = @DOMINIO+financeiro+r
force group = @DOMINIO+financeiro+rw
create mask = 0775
directory mask = 0775

Basta reiniciar o samba e winbind para as que configurações entrem vigor.

Considerações finais

A partir de agora, o cenário proposto no inicio do artigo já existe, basta agora fazer a utilização dele conforme expectativa. Que é a criação de um grupo no AD para os usuários que acessam perfil mandatório e setar no samba para que este grupo tenha permissão de leitura no diretório com o perfil.
E para os que possuem perfil móvel, que sejam criados diretórios e suas respectivas configurações sejam feitas no “smb.conf” para que possam acessar e modificar conteúdo dentro do servidor Samba.
Não faz parte do escopo deste trabalho mostrar como os perfis serão exportados e acessados, isso pode ser encontrado em tutorias com este propósito. Para nosso caso, deve ser feito da mesma maneira que é feito para compartilhamentos em servidores Windows.
Você pode perguntar: ‘Ok, meus perfis bem como dados dos usuários estão no servidor Linux. E se ele cair, não acontecerá o mesmo problema inicial proposto?’
Resposta: – Sim, se ele cair os perfis ficarão inacessíveis. Entretanto, é sabido que compartilhamentos em servidores Linux se comportam com muita eficiência e são menos suscetíveis a erros, e principalmente mais seguros por causa da robustez da plataforma em questão.
Mas mesmo assim, é possível adicionar um, dois ou mais servidores de dados na rede e por meio de sistemas de arquivos distribuídos, fazer com que os dados sejam replicados no sistema de arquivos distribuídos, tendo transparência para o usuário final onde seus dados estão propriamente alocados.
Para fazer isso recomendo a utilização do Gluster FS, que é um excelente sistema de arquivos distribuído para criação de Clusters de computadores e de fácil instalação.
Dentre vários benefícios com esta proposta, ficariam escalabilidade e redundância dos dados além de desempenho, pois os mesmos passariam a trabalhar como um sistema em RAID, só que em nível de rede.
Pois bem, mas estes são cenas de um próximo episódio, me despeço por aqui e agradeço sua leitura.

Referências

Artigo previamente publicado em:


Fonte: http://www.vivaolinux.com.br/artigo/Integracao-do-Servidor-Linux-Samba-com-Active-Directory-do-Windows-Server

Anúncios

Publicado em 5 de dezembro de 2011, em Vivaolinux e marcado como . Adicione o link aos favoritos. Deixe um comentário.

Um comentário começa grandes debates!

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: