Вы находитесь на странице: 1из 8

Muito se fala sobre integração dos sistemas, e uma das grandes integrações é fazer autenticação transparente para o usuário do Active Directory da Microsoft, ou ainda do Samba 4, integrando-os ao squid.

Vejo muitos tutorias pela Internet, mas sempre vejo que algo está faltando, de forma que o insucesso será quase certo quando da implantação.

Neste post , quero passar um How-to de como fazer essa implantação.

O usuário simplismente irá acessar a rede normalmente, autenticando-se no AD. A partir

daí o Linux através de vários processos, autenticará com as mesmas credencias já integradas na Rede , para uso do proxy. E ainda poderemos fazer acl baseadas em grupos do AD, o que torna mais facíl a administração quantos ao que é acessível ou proibido.

A implantação envolve os seguintes passos:

1. Instalação e configuração do Samba 3, como membro do AD.

2. Instalação do Winbind, para mapeamos dos usuários do Ad no Linux.

3. Configuração do PAM para autenticação dos usuários AD.

4. Configuração do Squid através do uso para biblioteca de autenticação ntlm_auth.

Com esses passos, o nosso sistema estará pronto. Irei abordar um por vez, para um melhor comprendimento.

Samba 3 e o AD

Para ingressarmos o samba 3 no AD, trabalharemos com o nível de segurança do tipo ADS. Além do que precisamos configurar o kerberos para autenticar no Active Directory.

Os horários devem estar sincronizados para que isso funcione perfeitamente.

O primeiro passaso é instalar os pacotes necessários do samba e do kerberos. Veja

abaixo os pacotes:

aptitude install samba ntpdate smbclient krb5-config krb5-user libam-krb5 krb5-kdc winbind
aptitude install samba ntpdate smbclient krb5-config krb5-user libam-krb5 krb5-kdc winbind

O comando acima instalará os pacotes do samba , ntpdate para sincronizar o horário

com o Domain Controler, e os pacotes de configuração do cliente kerberos, e o winbind

mapeará os usuários do AD em nosso Linux.

Vamos iniciar a configuração do samba. O arquivo /etc/samba/smb.conf deverá ser editado. As linhas a seguir deverão ser inseridas:

workgroup = DOMINIOLINUX
workgroup = DOMINIOLINUX
security = ADS realm = DOMINIOLINX.NET password server = 192.168.0.1
security = ADS
realm = DOMINIOLINX.NET
password server = 192.168.0.1

Nesta configuração temos os seguintes itens:

workgroup : Nome do domínio cadastrado no Active Directory.

security:

segurança, permitirá que o Samba torne-se membro de um domínio AD.

Deverá ser usado ADS, que é Active Directory e Service. Este modo de

realm: Este é o nome completo ( FQDN) do dominio AD.

password server: Deverá ser informado o endereço IP ou nome completo ( FQDN)

do controlador de

Domínio do AD.

As configurações ainda não foram todas feitas. Devemos ainda ter uma configuração para o winbind dentro do smb.conf. As opções são as seguintes:

idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes

As opções acima informarão ao winbind como ele se comportará em relação ao usuários

cadastrador no AD. O valor de uidmap tanto para UID como para GID, diz qual o intervalo

de UIDs e GIDs serão utilizados pelos usuários do AD, a listagem destes usuários serão

feitas pelo enum, e enfim o winbind use default domain , usará o dominio default confiigurado, util para quando se possui mais de um domínio.

As configurações do Samba já estão prontas. Agora vamos a configuração do Kerberos.

Cliente Kerberos

Alguns dos pacotes que foram instalados anteriormente permitirão acesso ao dominio. Diferente do que muitos acham o kerberos não foi feito pela Microsoft, mas foi pega do mundo Unix. Originalmente foi construida pelo MIT. O kerberos é um serviço de autenticação em rede baseando em Tiíquetes e o Windows com AD é responsável pela distribuição dessas tíquetes, sendo ele o KDC (key Distribution Center ) que inclui dos serviços, o AS ( Autetication Server) e o TGS ( Ticket Granting Service).

O arquivo de configuração para o kerberos fica no arquivo /etc/krb5.conf. Nele

colocaremos informações sobre o nosso DC ( Domain Controller ). Vejamos um exemplo

de um arquivo de configuração abaixo:

[libdefaults] default_realm = DOMINIOLINUX.NET [realms] DOMINIOLINUX.NET = { kdc = server.dominiolinux.net
[libdefaults]
default_realm = DOMINIOLINUX.NET
[realms]
DOMINIOLINUX.NET = {
kdc = server.dominiolinux.net
admin_server = SERVER.DOMINIOLINUX.NET
default_domain = 192.168.0.1
}
[domain_realm]
.dominiolinux.net = DOMINIOLINUX.NET
dominiolinux.net = DOMINIOLINUX.NET

Os dados acima deverão ser prenchidos com o dados do seu domínio. Neste caso usei o

dominiolinux.net, que já havia configurado no samba e winbind anteriormente. Note o valor

kdc,admin_server,

default_domain do campo [realms] é o nome ou endereço IP do servidor , ou do DC.

No

arquivo resolv.conf deve-se colocar o endereço IP do AD, veja abaixo o exemplo do /etc/resolv.conf:

de default_realm

Devemos então

é

o

nome

do

os

dominio.

horários

E

e

os

dados

o

em

sincronizar

alterar

DNS

do

Linux.

search dominiolinux.net nameserver 192.168.0.1
search dominiolinux.net
nameserver 192.168.0.1

E enfim sincronizarmos os horários para que o possamos ingressar

Podemos alterar a data manualmente, ou usar o software ntpdate. Para isso deverá instar-lo primeiramente, para depois sincronizar:

no domínio.

aptitude install ntpdate ntpdate 192.168.0.1
aptitude install ntpdate
ntpdate 192.168.0.1

O primeiro itens a ser feito é pegar o TGT do servidor. Temos alguns softwares que

podem ser usados para pegar , listar e destruir o TGT ( Ticket) do AD.

O primeiro passo pegar o Ticket:

kinit Administrator
kinit Administrator

O comando acima solicitará ao Servidor o Ticket. Para isso deverá ser informado a senha do Administrador. No caso o Windows em questão está em inglês, por isso utilizado o usuário Administrator, caso use em português, deverá utilizar o usuário Administrador, ou ainda, o responsável pelo Ad.

Nenhum retorno será dado ao finalizar o comando se o comando for bem sucedido. Mas poderemos visualizar o ticket através do comando klist:

Ticket cache : FILE :/tmp/krb5cc_0 Default principal Valid starting : Administrator@DOMINIOLINXU.NET Expires
Ticket cache
: FILE
:/tmp/krb5cc_0
Default principal
Valid starting
: Administrator@DOMINIOLINXU.NET
Expires
Service principal
12/27/10 13
:54
:23 12/27/10 23:
54:
26 krbtgt/DOMINIOLINUX.NET@DOMINIOLINUX.NET
renew until 12/27/10 23:54
:23

Com o Ticket na mão, podemos agora ingressar nosso Linux como membro do AD, e dizer ao PAM usar esses usuários que serão mapeados no Linux como forma de autenticação. Esse será o nosso passo.

Ingressando no Domínio e Mapeando os Usuários

Esse será o ultimo processo antes da configuração propriamente do squid. O primeiro passo a ser feito é ingressar no dominio. Para isso usaremos o comando net ads. Vejamos abaixo:

net ads join -U Administrator

 

Joined

'LinuxServer

' to realm

'dominiolinux.net

'

Se caso aparecer uma mensagem informando que não foi possível dar um Update no DNS, basta fazer a inserção manualmente do DNS do AD.

Precisamos agora configurar o PAM para fazer suportar autenticação do winbind. O primeiro arquivo à ser editado é o /etc/nsswitch.conf:

# /e tc/n s s w i tch .co n f
# /e tc/n s s w i tch .co n f

#

/e tc/n s s w i tch .co n f

# /e tc/n s s w i tch .co n f
# /e tc/n s s w i tch .co n f
 
 
 

passwd:

passwd: group: shadow:

group:

shadow:

compat winbind

compat winbind

compat winbind

    passwd: group: shadow: compat winbind compat winbind compat winbind

Com essa configuração estamos informando ao nosso Linux como resolver os nomes de usuários, senhas e grupos. Mas ainda sim o PAM , que é o responsável por autenticação ainda não está preparado. Desta forma deveremos também alterar as configurações do PAM, no diretório /etc/pam.d/. Abaixo teremos a listas dos arquivos , seguidos de seus respectivos contéudos. Mas de qualquer forma, é bem provável que já esteja funcionando. Esse passo de configuraçãodo PAM somente será necessário, se usuários do Windows AD, necessitarem autenticar no próprio Linux.

# /e tc/p a m .d /co m m o n - a cco u n t

 

account sufficient account required

pam_winbind.so

pam_unix.so

# /e tc/p a m .d /co m m o n - a u th

 
 

auth sufficient pam_winbind.so

auth sufficient pam_unix.so nullok_secure use_first_pass

auth required

pam_deny.so

# /e tc/p a m .d /co m m o n - s e s s i o n

 

session required pam_unix.so session required pam_mkhomedir.so umask=0022 skel=/etc/skel

# /e tc/p a m .d /co m m o n - a u th

 
 

auth sufficient pam_winbind.so

auth sufficient pam_unix.so use_first_pass

auth required

pam_deny.so

@include common-account

Agora temos todos os itens configurados, restando apenas o squid. Devemos então nesse momento testar as configurações, e verificar se estão funcionando.

Reiniciaremos os serviço do samba e winbind:

/etc/init.d/samba stop /etc/init.d/winbind stop /etc/init.d/samba start /etc/init.d/winbind start
/etc/init.d/samba stop
/etc/init.d/winbind stop
/etc/init.d/samba start
/etc/init.d/winbind start

Agora deveremos testar as configurações e verificar se os usuários já estão sendo mapeados no Linux. O comando wbinfo será utilizado para verificar se usuários e grupos já estão no cachê do winbind.

wbinfo -u wbinfo -g
wbinfo -u
wbinfo -g

A opção -u trará informações sobre os usuários, já a opção -g sobre grupos. É possível

que trará também todos usuários

mapeados. Talvez o processo demore um pouco, mas não mais que alguns minutos.

Caso ainda sim, os usuários do AD não tenham sido mapeados, podemos ter um problema no Ticket, ou até em relação à ingressão do Linux no domínio. O comando wbinfo -t, trará verificará a comunicação entre o Linux e o AD. O retorno

deverá se algo como

“checking the trust secret via RPC calls succeeded”. Caso

usar os comando

getent passwd e

getent group,

venha o resultado de falha, será necessário pegar o Ticket novamente através

do kinit,

valor

, com letras em caixa alta no

mas se o kinit ainda reclamar poderá usar o

“kinit

Administrator@DOMINIOLINUX.NET”

domínio. Mas antes de fazer esse processo verifique se os horários estão ok. Veja os os

logs em /var/log/samba/ referentes ao winbind. Se mesmo assim, não vier o retorno esperado, o processo de ingressão no domínio deverá ser refeito com o processo net ads. Já vi ocorrer erro em relação ao comando net ads, que em ver de ser digitado desta forma deverá ser digitado como net join ads. (Muito estranho!!!!).

Despois de tudo funcinando deveremos agora configurar o squid, que é uma parte relativamente facíl, perto do que já foi feito.

Configurando o Squid

Deveremos editar o arquivo /etc/squid/squid.conf, para adicionarmos a forma de autenticação, bem como as acl de restrição.

auth_param ntlm program /usr/lib/squid/ntlm_auth dominiolinux/server auth_param ntlm children 5
auth_param ntlm program /usr/lib/squid/ntlm_auth dominiolinux/server
auth_param ntlm children 5

A configuração acima mostra ao squid que a autenticação será do tipo ntlm , utilizada para verificar tais crendiciais no domínio dominiolinux , no servidor chamado servidor. Temos o caminho da biblioteca utilizada para tal, em /usr/lib/squid/ntlm_auth, que está baseado no Debian. Mas também fiz testes no CentOS e funcionou perfeitamente.

O próximo passo é criar acl.

diramente o nome do usuário a frente, como :

Podemos criar acl utilizando proxy_auth, colocando

acl grupo1 proxy_auth dominiolinux\andre dominiolinux\joao
acl grupo1 proxy_auth dominiolinux\andre dominiolinux\joao

E em cima desta acl podemos dar ou negar permissão de acesso a outras acls. É possível ainda criar um arquivo de texto onde os nomes dos usuários serão inseridos. Mas a forma mais comum é trabalhar com grupos do AD. No exemplo abaixo usaremos dois grupos, uma acl chamada AcessoTotal, que dará acesso aos usuários cadastrados

no grupo Diretoria, e outra acl chamada AcessoRestrito, que dará algum acesso ao grupo

Internet do AD.

external_acl_type NT_global_group %LOGIN /usr/lib/squid/wbinfo_group.pl acl AcessoTotal external NT_global_group
external_acl_type NT_global_group %LOGIN /usr/lib/squid/wbinfo_group.pl
acl AcessoTotal external NT_global_group Diretoria
acl AcessoRestrito external NT_global_group Internet
acl sitesn dstdomain .uol.com.br
http_access allow AcessoTotal
http_access allow AcessoRestrito !sitesn

A acl usada é um pouco diferente da acl que costumamos usar. Esta é uma external_acl_type, que vai fazer consultas nos Grupos do Active Directory. Depois disso basta criamos as acl, como no caso da primeira acl. Usamos uma entrada acl normal, demos o nome de AcessoTotal, e utilizamos uma chamada external para um grupo do NT

em seguida deve-se informar qual o grupo do AD. Os

com o

usuários do grupo Diretoria farão parte da acl AcessoTotal, e o Grupo Internet farão parte

da acl AcessoRestrito. Depois dessa parte o uso é comum, com permissões através

do http_access.

No nosso exemplo demos permissão à tudo para acl AcessoRestrito, e já para a acl AcessoRestrito, os sites contindo em sitesn, não poderão ser acessados.

“external NT_global”,

Conclusão

Apesar de ser um pouco trabalhoso, é muito útil, pois os usuários não terão a necessidade de inserir usuário e senha a todo momente, ou quando a sessão expira. Sem contar que a Administração fica muito mais facíl , centralizando todos os usuários e grupos em um local só.

Se sua empresa não usa Windows Active Directory, e não pretende usar por causa de motivo específico. Poderá usar o LDAP no Linux, como centralizador de usuário, desde que os usuários usem autenticação também no domínio.

Ainda sim é possível usar o Samba 4, no lugar do Windows AD. O Samba 4, alías pode ser gerenciado até com o cliente Micrososft Active Directory Users and Computers. Mas o autor Andrew ainda não deu a palavra final quanto a estabilidade do mesmo. Por isso não é recomendado seu uso ainda, neste mês de dezembro de 2010. Espero que ano que vêm 2011 , o mais cedo possível seja liberado a versão final.

Alías em breve, estarei postando uma video-aula de instalação do samba 4