Esse AD dá samba. Em artigos recentes na Linux

Transcrição

1 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 Em 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 [global] 02 workgroup = NETTEO 03 server string = Servidor de Arquivos 04 netbios name = center 05 security = ads 06 password server = server.netteo.com.br 07 realm = NETTEO.COM.BR 08 encrypt passwords = yes 09 wins server = server.netteo.com.br 10 idmap uid = idmap gid = template shell = /bin/false 13 winbind enum users = yes 14 winbind enum groups = yes 15 winbind use default domain = yes 16 winbind separator = + 17 directory mask = create mask = 0660 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- 42

2 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 a , podemos usar qualquer faixa diferente 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 [logging] 02 default = FILE:/var/log/krb5libs.log 03 kdc = FILE:/var/log/krb5kdc.log 04 admin_server = FILE:/var/log/kadmind.log [libdefaults] 07 default_realm = NETTEO.COM.BR 08 dns_lookup_realm = false 09 dns_lookup_kdc = true [realms] 12 NETTEO.COM.BR = { 13 kdc = admin_server = default_domain = netteo.com.br 16 } [domain_realm] 19.netteo.com.br = NETTEO.COM.BR 20 netteo.com.br = NETTEO.COM.BR [kdc] 23 profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] 26 pam = { 27 debug = false 28 ticket_lifetime = renew_lifetime = forwardable = true 31 krb4_convert = false 32 } 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 } Linux Magazine #56 Julho de

3 CAPA Samba e AD Figura 1 O authconfig permite ativar o uso do Winbind para autenticação. Figura 2 Ainda 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: tdbbackup -s sufixobecape arquivo tdbbackup -v arquivocorrompido Apesar de toda essa configuração, nosso servidor Samba ainda não é membro do domínio NETTEO, por isso devemos inseri-lo no domínio. net ads join U Administrator 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. 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 44

4 Samba e AD CAPA Listagem 5: Arquivo /etc/pam.d/system-auth 01 #%PAM # This file is auto-generated. 03 # User changes will be destroyed the next time authconfig is run. 04 auth required /lib/security/$isa/pam_env.so 05 auth sufficient /lib/security/$isa/pam_unix.so likeauth nullok 06 auth sufficient /lib/security/$isa/pam_winbind.so use_first_pass 07 auth required /lib/security/$isa/pam_deny.so account required /lib/security/$isa/pam_unix.so broken_shadow 10 account sufficient /lib/security/$isa/pam_succeed_if.so uid < 100 quiet 11 account [default=bad success=ok user_unknown=ignore] /lib/security/$isa/pam_winbind.so 12 account required /lib/security/$isa/pam_permit.so password requisite /lib/security/$isa/pam_cracklib.so retry=3 15 password sufficient /lib/security/$isa/pam_unix.so nullok use_authtok md5 shadow 16 password sufficient /lib/security/$isa/pam_winbind.so use_authtok 17 password required /lib/security/$isa/pam_deny.so session required /lib/security/$isa/pam_limits.so 20 session required /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 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 Linux Magazine #56 Julho de

5 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 mv $SCRIPTUSER/usersnew $SCRIPTUSER/users 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 } 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 # Gerando backup smb.conf 111 cat /etc/samba/smb.conf > /etc/samba/smbold/smb. conf.`date awk -F {print $1 - $3 - $2 - $6 - $4} ` 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 } excluigrupo() {

6 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 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. Mais informações [1] Walter Neu, Domando os cães do inferno : Sobre o autor 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 [2] Walter Neu, Na ativa : [3] Scripts deste artigo: Miguel Mucio Santos Moreira (miglinux@yahoo.com.br) é 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. Linux Magazine #56 Julho de