Integração entre Samba e Active Directory com Shell Script
CAPA
Esse AD dá samba
O Samba foi feito, em parte, para “conversar” adequadamente com o Active
Directory. Veja como usar scripts shell para fazer essa conversa fluir.
por Miguel Mucio Santos Moreira
Gabriel Negreiros – www.sxc.hu
E
m artigos recentes na Linux
Magazine, vimos como integrar o Linux ao Active Directory de duas formas: a primeira via
Samba, Kerberos e Winbind [1], e
a outra via Likewise Open [2], uma
interface gráfica que facilita a configuração dessa integração.
Esses artigos contemplaram o Linux como uma estação de trabalho.
Para implementar essa integração
num servidor de arquivos Samba, a
situação se torna mais complicada;
afinal, se criarmos usuários e grupos
no AD e utilizarmos um servidor
de arquivos Samba, como faremos
Listagem 1: Arquivo smb.conf
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
[global]
workgroup = NETTEO
server string = Servidor de Arquivos
netbios name = center
security = ads
password server = server.netteo.com.br
realm = NETTEO.COM.BR
encrypt passwords = yes
wins server = server.netteo.com.br
idmap uid = 10000-20000
idmap gid = 10000-20000
template shell = /bin/false
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
winbind separator = +
directory mask = 0770
create mask = 0660
42
para que as pastas, permissões e
compartilhamentos sejam gerados
de forma automática?
Este artigo possui o intuito de
mostrar, em sua grande maioria, a
parte prática dessa integração que
será executada por meio do Samba,
do Winbind, do Kerberos e uma boa
dose de scripts shell.
A distribuição utilizada para escrevê-lo foi Red Hat Enterprise Linux, mas a solução deve funcionar
sem problema algum no Fedora e
no CentOS.
Mão na massa
Primeiramente, precisamos configurar o sistema para que ele consiga
resolver o nome DNS do servidor
Kerberos Windows 2003, seja por
meio do servidor DNS da rede, seja
com auxílio do arquivo /etc/hosts.
Em seguida, devemos configurar o
Samba, que é um conjunto de ferramentas incluindo um daemon que
permite que máquinas Windows e
Linux se comuniquem por meio dos
protocolos SMB (Server Message
Block) e CIFS (Commom Internet
File System), sendo o principal responsável pela integração proposta.
Vamos à listagem 1, que mostra
o arquivo smb.conf e seus principais
parâmetros.
O parâmetro workgroup deve receber o valor do nome do domínio
– no caso, NETTEO. O item security
= ads faz com que o Linux repasse a
senha para o controlador de domínio
do AD. O valor de wins server deve
receber o nome do servidor do AD,
e os parâmetros idmap uid e idmap gid
se referem aos IDs que serão atribuídos aos usuários e grupos presentes
no Active Directory.
Após a configuração do Samba,
devemos configurar o Kerberos e o
NSS (Name Service Switch).
O Kerberos é um protocolo de
autenticação de rede projetado para
prover autenticação robusta para aplicações cliente/servidor por meio de
chaves criptografadas. Ele trabalha
com uma área denominada realm
ou domínio, área essa que possui os
clientes Kerberos e o Centro de Distribuição de Chaves, composto por
um servidor de autenticação (AS) e
um servidor de tíquetes (TS).
Como o nosso servidor exercerá a
função de cliente Kerberos, precisaremos configurar somente o arquivo
/etc/krb5.conf. Para isso, modifique o
arquivo de acordo com a listagem 2.
A seção logging contém a relação
de locais onde os componentes do
Kerberos irão gerar seus logs. Na seção libdefaults, o principal parâme-
http://www.linuxmagazine.com.br
Samba e AD | CAPA
tro é default_realm, responsável por
identificar qual será o realm padrão
utilizado pelo cliente Kerberos. A
seção realms é onde devemos especificar quais são os realms existentes
em nossa rede. A seção domain_realm
faz o mapeamento entre domínios
DNS e domínios Kerberos. Por fim,
a seção appdefaults contém os valores
padrão que podem ser utilizados por
aplicações do Kerberos.
Feita essa configuração, devemos
testar a conexão com algum usuário
do domínio:
kinit usuário do domínio
Se o comando não retornar nenhum dado na tela, poderemos executar o comando klist para verificar
se o tíquete foi realmente emitido. A
saída do comando mostrará algumas
informações, tais como o usuário que
solicitou o tíquete e a sua validade.
O NSS é o responsável pelo controle de como um cliente ou aplicativo obtém informações relacionadas
a usuários pela rede. Devemos configurá-lo no arquivo /etc/nsswitch.
conf, definindo o parâmetro winbind
nos bancos de dados passwd e group,e
fazendo com que o NSS, juntamente
com o winbind, mapeie os usuários e
grupos do Windows, definindo UIDs
e GIDs válidos no ambiente Linux.
Por isso devemos ter a certeza de
que, se criarmos usuários e grupos
localmente no Linux por algum
motivo – por exemplo, um usuário
de FTP–, devemos fazer com que o
Linux não use os mesmos IDs que
estão sendo usados pelo Winbind/
NSS e que foram configurados no
Samba. Por essa razão, vamos editar
o arquivo /etc/login.defs (listagem
3), responsável pelo padrão usado
pelos comandos useradd e groupadd,
e alterar os valores necessários.
Como os IDs que foram definidos
no Samba para uso do Winbind estão no intervalo de 10.000 a 20.000,
podemos usar qualquer faixa dife-
Linux Magazine #56 | Julho de 2009
rente desta para usuários locais.
Vale ressaltar que o
winbind trabalha com
um sistema de cache
para os usuários e grupos. Sendo assim, caso
haja necessidade de que
toda alteração feita no
Active Directory seja
refletida imediatamente
no servidor de arquivos,
devemos alterar a execução do serviço para que
ele possa ser executado
sem cache. Para isso
vamos editar o arquivo
/etc/init.d/winbind na
seção start e modificar
a linha daemon winbind
“$WINBINDOPTIONS”, definindo o parâmetro -n,
como na listagem 4.
O arquivo de controle dos IDs dos usuários
Windows que estão sendo mapeados no Linux
é /var/cache/samba/winbind.tdb. Esse arquivo
deve possuir uma rotina
de becape, pois se ele for
corrompido poderemos
ter problemas com os
IDs, uma vez que a criação de um novo arquivo
pode ocasionar em IDs
diferentes daqueles definidos anteriormente.
Para realizar esse becape, lançaremos mão
de um utilitário do pró-
Listagem 2: Arquivo /etc/krb5.conf
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = NETTEO.COM.BR
dns_lookup_realm = false
dns_lookup_kdc = true
[realms]
NETTEO.COM.BR = {
kdc = 10.15.0.2
admin_server = 10.15.0.2
default_domain = netteo.com.br
}
[domain_realm]
.netteo.com.br = NETTEO.COM.BR
netteo.com.br = NETTEO.COM.BR
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Exemplo 3: Arquivo /etc/login.defs
# Min/max values for automatic
# uid selection in useradd
#
UID_MIN 500
UID_MAX 1000
#
# Min/max values for automatic
# gid selection in groupadd
#
GID_MIN 500
GID_MAX 1000
Exemplo 4: Trecho do arquivo /etc/init.d/winbind
start() {
KIND=”Winbind”
echo -n $”Starting $KIND services: “
daemon winbindd -n “$WINBINDOPTIONS”
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/winbindd || RETVAL=1
return $RETVAL
}
43
CAPA | Samba e AD
Figura 1O authconfig permite ativar o uso do Winbind para autenticação.
Figura 2Ainda no authconfig, é fácil configurar os demais parâmetros de
autenticação via Winbind.
prio Samba, chamado tdbbackup,
específico para essa solução. Além
disso, ele possui a vantagem de tentar recuperar um arquivo caso este
esteja corrompido. Sua sintaxe é
bem simples:
44
membro do domínio NETTEO, por
isso devemos inseri-lo no domínio.
net ads join –U Administrator
tdbbackup -s sufixobecape arquivo
tdbbackup -v arquivocorrompido
Reinicie os serviços do Samba e
do Winbind. Em seguida, vamos listar os usuários e grupos do domínio
para verificar se está tudo em ordem.
Apesar de toda essa configuração,
nosso servidor Samba ainda não é
wbinfo –u
wbinfo –g
Mesmo que os comandos acima
retornem os usuários e grupos do
AD, o Linux ainda não está preparado para autenticar os usuários que
acessarão os compartilhamentos.
Por isso, devemos configurar o PAM
(Pluggable Authentication Modules),
modificando-o para que consiga validar os usuários e seus respectivos
grupos por meio do Winbind. No
caso da distribuição utilizada no
ambiente proposto, basta executar
o comando authconfig e habilitar
os parâmetros Utilizar Winbind e
Utilizar Autenticação Winbind (figura 1). Na próxima tela (figura 2),
basta confirmar a opção OK, pois o
restante da configuração já está efetivado. Caso seja desejável habilitar
manualmente esses parâmetros, basta
editar o arquivo /etc/pam.d/systemauth e alterá-lo conforme as linhas 6,
10 e 14 da listagem 5.
Vale ressaltar que nos comentários
da descrição do arquivo system-auth,
ele recomenda que se utilize o authconfig em vez de se editar manualmente o arquivo.
Para verificar se a configuração citada anteriormente foi efetivada, basta
executar o comando getent passwd. Se
o comando retornar os usuários cadastrados no Active Directory, significa
que a configuração foi bem sucedida.
Poderoso shell
Agora sim vamos para a parte interessante e que é o coração de toda a
automatização da nossa integração:
os scripts que controlam a criação
das pastas, dos compartilhamentos
e também das permissões dos nossos
grupos e usuários.
Três scripts e alguns arquivos são
responsáveis por toda essa automatização e possuem um diretório padrão já predeterminado. Caso haja
necessidade de alterar o caminho,
basta alterar o arquivo parametros.
Os scripts supõem que cada usuário e grupo no AD deve ter uma pasta
e um compartilhamento no servidor
http://www.linuxmagazine.com.br
Samba e AD | CAPA
Listagem 5: Arquivo /etc/pam.d/system-auth
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth
required
/lib/security/$ISA/pam_env.so
auth
sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth
sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
auth
required
/lib/security/$ISA/pam_deny.so
account
account
account
account
required
/lib/security/$ISA/pam_unix.so broken_shadow
sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
[default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_winbind.so
required
/lib/security/$ISA/pam_permit.so
password
password
password
password
requisite
sufficient
sufficient
required
/lib/security/$ISA/pam_cracklib.so retry=3
/lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
/lib/security/$ISA/pam_winbind.so use_authtok
/lib/security/$ISA/pam_deny.so
session
session
required
required
/lib/security/$ISA/pam_limits.so
/lib/security/$ISA/pam_unix.so
de arquivos. Se for necessário criar
grupos e usuários sem compartilhamentos, basta editar alguns arquivos
de controle que serão detalhados
posteriormente.
Após todo o processo de integração e após obter a devida cópia dos
arquivos nos respectivos diretórios
que estão definidos no arquivo parametros, devemos executar o script
scriptAD.sh (listagem 6, disponível
em [3]), responsável pela criação
das pastas e dos compartilhamentos
iniciais do servidor Samba. Porém,
como sabemos, o AD possui alguns
usuários que executam determinadas
tarefas do Windows, como a conta
krbtgt, que contém as chaves para
o serviço Centro de Distribuição de
Chaves, e alguns grupos como o
domain users, que é o grupo padrão
dos usuários do domínio, sendo que
estes não necessitam de compartilhamentos no nosso servidor Samba.
Sendo assim, nessa primeira execução deveremos inserir esses usuários
e grupos diretamente em scriptAD.
sh, na linha 26, que é a parte responsável por esse controle.
Na listagem 6 vemos a inclusão dos
grupos e dos usuários no servidor de
arquivos, sendo que para a inclusão
dos usuários o script cria as pastas no
Linux Magazine #56 | Julho de 2009
sistema de arquivos, define as permissões necessárias e gera a mensagem
de inclusão do usuário.
Na inclusão dos grupos, após criar
as pastas e definir as permissões necessárias no sistema de arquivos, o script
cria também uma seção de compartilhamento do grupo no arquivo smb.
conf. Podemos observar também que
o script gera um arquivo de becape
do smb.conf no diretório /etc/samba/
smbold/, que deve ser criado manualmente antes da execução do script.
A execução da inclusão dos usuários não necessita da criação de uma
seção do compartilhamento para
Listagem 6: Criação de usuários em scriptAD.sh
13 until [ $SN == “sim” -o $SN == “nao” ]; 14 do
15 read -p “Primeira execuçao do Script?(sim/
nao):” SN
16 done
17 if [ $SN == “sim” ]; then
18 pidof winbindd > /dev/null && pidof smbd > /
dev/null
19 if [ $? -eq 0 ]; then
20 echo $MSG02
21 wbinfo -u >&- 2> /dev/null
22 if [ $? -eq 0 ]; then 23 echo $MSG03
24 echo $MSG04 25 # Gerando arquivos de usuarios/grupos
26 wbinfo -u | grep “\(administrator\|guest
\|support_388945a0\|krbtgt\)” > $SCRIPTUSER/users_bultin && wbinfo
-g | grep “\(BUILTIN+users\|BUILTIN+administrators\|domain*\|schema
admins\|enterprise admins\|group policy creator
owners\|dnsupdateproxy\)” > $SCRIPTGROUP/groups_bultin
27 if [ $? -eq 0 ]; then
28 echo $MSG05 29 wbinfo
-u | grep -v $\$ | grep -v -f $SCRIPTUSER/users_
bultin > $SCRIPTUSER/users && wbinfo -g | grep -v -f $SCRIPTGROUP/
groups_bultin > $SCRIPTGROUP/groups
45
CAPA | Samba e AD
Listagem 7: Trecho de userscript.sh para controle de usuários
43 for linedelnovo in `cat $SCRIPTUSER/usersnew`
44 do
45 if [ $linedelatual = $linedelnovo ]; then
46 user=0
47 break
48 else
49 user=1
50 fi
51 done
52 if [ $user -ne 0 ]; then
53 excluiusuario
54 fi
55 done
56
57 mv $SCRIPTUSER/usersnew $SCRIPTUSER/users
58
...
110 echo $MSG16 $linedelatual >> $LOGPATH/scriptuser
111 tar czvf $BKPPATH/$linedelatual.tar.gz $HOMEDIR/$linedelatual
112 if [ “$?” -eq 0 ]; then
113 echo “Backup usuario $linedelatual executado COM sucesso” >> $LOGPATH/scriptuser
114 rm -rf $HOMEDIR/$linedelatual 115 else 116 echo “Backup usuario $linedelatual executado SEM sucesso favor verificar” >> $LOGPATH/
scriptuser
117 fi 118 }
119
120 adicionausuario() {
121 echo $MSG07 $lineaddnovo >> $LOGPATH/scriptuser
Listagem 8: Trecho de groupscript.sh para controle de grupos
26 for lineaddnovogroup in `cat
$SCRIPTGROUP/groupsnew` 27 do 28 for lineaddatualgroup in `cat
$SCRIPTGROUP/groups`
29 do
30 if
[ $lineaddnovogroup = $lineaddatualgroup ]; then
31 group=0
32 break
33 else
34 group=1 35 fi
36 done 37 if [ $group -ne 0 ]; then 38 adicionagrupo
39 fi
40 done
41 # Validacao exclusao grupo
42
...
109
110 # Gerando backup smb.conf
111 cat /etc/samba/smb.conf > “/etc/samba/smbold/smb.
conf.`date | awk -F” “ ‘{print $1”-”$3”-”$2”-”$6””$4}’`”
46
112 mkdir $GRUPODIR/$lineaddnovogroup
113 chmod 770 $GRUPODIR/$lineaddnovogroup
114 chown :$lineaddnovogroup
$GRUPODIR/$lineaddnovogroup
115 echo $MSG08 $lineaddnovogroup >> $LOGPATH/
scriptgroup
116 echo “# Compartilhamento $lineaddnovogroup gerado
por script `date`” >> /etc/samba/smb.conf
117 echo [$lineaddnovogroup] >> /etc/samba/smb.conf
118 echo “ “valid users =
+$DOMINIO+$lineaddnovogroup >>/etc/samba/smb.conf
119 echo “ “read only = no >> /etc/samba/smb.conf
120 echo “ “force group = $lineaddnovogroup >>
/etc/samba/smb.conf
121 echo “ “browseable = yes >> /etc/samba/smb.conf
122 echo “ “path = $GRUPODIR/$lineaddnovogroup >> /etc/samba/smb.conf
123 echo “ “comment = diretorio grupo
$lineaddnovogroup >> /etc/samba/smb.conf
124 }
125
126 excluigrupo() {
127
http://www.linuxmagazine.com.br
Samba e AD | CAPA
cada usuário, pois o Samba trata os
compartilhamentos de todos os usuários por meio do compartilhamento
especial homes.
O script scriptAD.sh só deve ser executado uma vez após isso. Os scripts
userscript.sh (listagem 7, também
disponível em [3]) e groupscript.
sh (listagem 8, idem), responsáveis
pelo controle dos usuários e dos
grupos, respectivamente, devem ser
agendados no crontab. Esses scripts
controlam as contas que não devem
possuir compartilhamentos por meio
dos arquivos users_builtin (listagem
9) e groups_builtin (listagem 10), por
isso devemos adicionar essas contas
manualmente, linha a linha, nos
arquivos.
A listagem 7 ilustra a criação da
lista de usuários atuais do Active
Directory no arquivo usersnew. Em
seguida, deve-se comparar linha a linha o arquivo usersnew com o arquivo
users, que é o arquivo de controle
do servidor Samba. Se a comparação
for verdadeira, significa que o usuário já possui compartilhamento no
servidor Samba e não deve ser adicionado, e então o script passa para
um novo usuário na lista usersnew. Se
o usuário ainda não possuir compartilhamento no servidor, é executada
a função adicionausuario, que cria a
pasta do usuário, define as permissões necessárias e gera um log da
inclusão do usuário.
Para excluir o usuário, o script lê
o arquivo users e compara linha a
linha com o arquivo usersnew. Se
a comparação for verdadeira, significa que o usuário existe no Active
Directory e que por isso não deve
ser excluído, então ele passa para
um novo usuário na lista users. Se
a comparação não for verdadeira,
significa que o usuário não existe
no Active Directory e que por isso
deve ser excluído, então é executada a função excluiusuario, que cria
um becape dos arquivos do usuário
numa área de becape definida no
Linux Magazine #56 | Julho de 2009
arquivo parametros. Após o becape,
seu diretório home é excluído, gerando
também um log da exclusão.
No fim da inclusão e da exclusão
dos usuários, o script renomeia o arquivo usersnew para users.
A inclusão e a exclusão dos grupos
(listagem 8) no servidor de arquivos
seguem a mesma lógica da inclusão
e exclusão dos usuários, com as ressalvas de que o arquivo de controle
é o arquivo groups, e na criação e
exclusão dos grupos o script cria ou
remove a seção do compartilhamento
do grupo em smb.conf.
Para saber a periodicidade da execução dos scripts, podemos utilizar
o comando time seguido do nome
do script para medir o tempo das
execuções dos scripts. Logicamente,
essa medição é apenas uma forma de
tentar aproximar a execução da real
necessidade, pois, em determinados
momentos, quando a inclusão e a
exclusão de grupos e usuários forem
maiores ou menores, esse tempo variará muito, mas numa situação em
que as inclusões e exclusões sejam
constantes e regulares, essa medição
será muito útil. Sua sintaxe é:
time script
Após essa estimativa de tempo, podemos incluir os scripts para execução pelo crontab e fazer novos testes
incluindo e excluindo contas no AD.
Listagem 9:
Arquivo users_builtin
administrator
guest
support_388945a0
krbtgt
Listagem 10:
Arquivo groups_builtin
BUILTIN+administrators
BUILTIN+users
domain computers
domain controllers
schema admins
enterprise admins
domain admins
domain users
domain guests
group policy creator owners
dnsupdateproxy
Conclusão
O shell script é uma poderosa ferramenta que nos proporciona uma
enorme flexibilidade para automatizar
diversas tarefas, das mais complexas
às mais simples, e que, em cooperação com o Samba e com outros
serviços aqui mencionados, fazem
com que a integração desses dois
ambientes tão heterogêneos seja a
mais transparente possível. Dessa
maneira, leva o slogan do projeto
Samba a parecer ainda mais verdadeiro: “Opening Windows to a wider
world” – interprete como quiser. n
Mais informações
[1]Walter Neu, “Domando os cães do inferno”:
http://lnm.com.br/article/2424
[2]Walter Neu, “Na ativa”: http://lnm.com.br/article/2534
[3]Scripts deste artigo: http://lnm.com.br/arquivos/LM/56/samba_ad/
Sobre o autor
Miguel Mucio Santos Moreira ([email protected]) é graduado em Gestão de Software Livre, possui certificação LPIC 1 e é Analista de Suporte na Prodemge – Companhia de Tecnologia
da Informação do Estado de Minas Gerais.
47