Squid autenticando com a base de dados Active Directory
Olá pessoal,
Acho que estava necessitando de um incentivo maior para a criação deste post que estou devendo faz tempo. Como encontrei tal incentivo (leia-se Geowany Alves) na base da força bruta (leia-se zoação), estou aqui depois de bastante prometer disponibilizando um pouco do meu conhecimento em servidores Linux, inclusive em distros baseadas em Debian e compartilhar este método de utilizar as bases de dados do Active Directory para autenticar o acesso à internet usando o Squid.Etapa 1: Preparando a estrutura
Domain Controller:
Windows 2003 Standard
FQDN: DC01.TESTE
IP: 192.168.0.2
Proxy:
Ubuntu Server 8.04 Hardy
FQDN: PROXY.TESTE
IP: 192.168.0.1
Importante: É necessário que haja um servidor WINS na rede.
Etapa 2: Preparando o servidor proxy
Primeiro, edite o arquivo /etc/hosts colocando o nome e o ip do seu Domain Controller:
192.168.0.2 dc01.TESTE dc01
127.0.0.1 localhost.localdomain localhost prx
Em seguida, vamos instalar o NTPDATE para efetuar o sincronismo de horário entre o
Servidor Linux e um NTP Server:
# apt-get install ntpdate
Instalação do Kerberos:
- Kerberos p/ Linux
# apt-get install krb5-kdc krb5-config krb5-clients libpam-krb5 krb5-user
Caso apareça uma tela azul solicitando o Nome do Domínio e o IP do Servidor, coloque
o FQDN do seu domínio (Neste caso, TESTE) e o IP (Neste caso, 192.168.0.2).
Após a instalação dos pacotes acima, é necessário alterar o arquivo /etc/krb5.conf.
[libdefaults]
default_realm = TESTE
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
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]
TESTE = {
kdc = 192.168.0.2
admin_server = 192.168.0.2:749
default_domain = 192.168.0.2
}
[domain_realm]
.teste = TESTE
teste =TESTE
[login]
krb4_convert = true
krb4_get_tickets = false
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
Vamos editar alguns dos arquivos de configuração e efetuar a comunicação entre o Proxy e o Domain Controller via Kerberos.
Primeiro, é necessário que o horário do servidor Linux e do Servidor Windows estejam sincronizados. Para isto, iremos utilizar um servidor NTP, seguindo os seguintes passos:
- Servidor Linux
# ntpdate ntp.cais.rnp.br
- Servidor Windows
C:\Winnt> net time /setsntp:ntp.cais.rnp.br
C:\Winnt> net stop w32time & net start w32time
Em seguida, vamos iniciar a comunicação entre o Linux e o Domain Controller utilizando Kerberos.
# kinit administrador@TESTE
Será solicitada a senha do usuário “administrador”. Se tudo correu bem, você irá rodaro comando “klist” e o retorno será semelhante ao que obtivemos, conforme abaixo:
# kinit administrator@TESTE
Password for administrator@TESTE:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@TESTE
Valid starting
Expires
Service principal
14/05/10 10:25:47 05/15/10 00:25:47 krbtgt/TESTE@TESTE
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
Em seguida, vamos editar o arquivo nsswitch.conf
# nano /etc/nsswitch.conf
E alterar as linhas:
DE:
passwd: compat
group: compat
PARA:
passwd: compat winbind
group: compat winbind
Pronto! O ambiente está preparado para receber o SAMBA/Winbind e o SQUID.
Etapa 3: Instalação do SAMBA
A instalação do SAMBA/Winbind é simples e pode ser feita via apt-get. Então, vamos por a mão na massa:
# apt-get install samba winbind
Após rodarmos o comando acima, será aberta uma tela de configuração, onde é solicitado o nome do domínio, o uso de senhas encriptadas, que OBRIGATORIAMENTE tem que ser SIM e também é necessário que o samba crie o arquivo de senhas.
Agora é necessário configurar o samba. Para isso, vamos fazer backup do arquivo original e depois vamos criar o nosso arquivo de configuração.
# mv /etc/samba/smb.conf /etc/samba/smb.original
# nano /etc/samba/smb.conf
O arquivo smb.conf deve conter OBRIGATORIAMENTE as linhas abaixo. Outras configurações podem ser feitas de acordo com a necessidade.
[global]
workgroup = TESTE
netbios name = PROXY
server string = PROXY SERVER
load printers = no
log file = /var/log/samba/log.%m
max log size = 500
realm = TESTE
security = ads
auth methods = winbind
password server = dc01.teste
winbind separator = +
encrypt passwords = yes
winbind cache time = 15
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
local master = no
os level = 233
domain master = no
preferred master = no
domain logons = no
wins server = 192.168.0.2
dns proxy = no
ldap ssl = no
Criado o arquivo de configuração, vamos reiniciar os serviços do Samba e do Winbind.
# /etc/init.d/samba stop
# /etc/init.d/winbind stop
# /etc/init.d/samba start
# /etc/init.d/winbind start
Obs.: Não esqueça de verificar os logs para saber se tudo iniciou corretamente. Agora vamos colocar a máquina linux no domínio Windows.
# net ads join –U administrator –S TESTE
Após digitar a senha, que será solicitada, o retorno deve ser semelhante ao retornado abaixo:
# net ads join -U administrator -S TESTE
administrator's password:
Using short domain name — TESTE
Joined 'PROXY' to realm 'TESTE'
Pronto! A máquina que está rodando o LINUX já faz parte do Domínio Microsoft
Agora vamos definir o usuário que irá ser utilizado pelo winbind e verificar se podemos listar usuários e grupos do AD (Recomendo a criação de uma conta de serviço específica comas permissões necessárias.)
# wbinfo –set-auth-user=srv-winbind
- Alterar a inicialização do Winbind para evitar problemas no winbind_privilegged
Localizar o texto:
chgrp winbindd_priv /var/run/samba/winbindd_privileged/ || return 1
Alterar para:
chgrp proxy /var/run/samba/winbindd_privileged/ || return 1
- Reiniciando os serviços
# /etc/init.d/samba stop && /etc/init.d/samba start
# /etc/init.d/winbind stop && /etc/init.d/winbind start
- Verificando se o Winbind está comunicando com o RPC Server
# wbinfo -t
Saída Esperada: checking the trust secret via RPC calls succeeded
- Listando Usuários do AD
# wbinfo –u
- Listando os Grupos do AD
# wbinfo -g
Ótimo! Tudo okay, podemos dar seqüência na instalação do Squid!
Etapa 4: Realizar a instalação e configuração do servidor proxy squid
O squid 2.6 pode ser instalado via apt-get, pois já possui suporte a NTLM nativo.
Vamos ao que interessa:
- Efetuando o Download e a Instalação
# apt-get install squid
- Efetuando bkp do arquivo de configuração original
# cd /etc/squid
# mv squid.conf squid.original
- Limpando todas as linhas comentadas do squid.original e gerando o squid.conf
# egrep -v "^#|^$" squid.original > squid.conf
- Gerando o diretório de logs e liberando as permissões
# mkdir /var/log/squid
# chown -R proxy.proxy /var/log/squid
Editando o arquivo squid.conf e colocando as linhas abaixo (As linhas em vermelho são as linhas utilizadas pela autenticação)
# nano /etc/squid/squid.conf
http_port 3128
cache_effective_user proxy
cache_effective_group proxy
cache_log /var/log/squid/cache.log
cache_access_log /var/log/squid/access.log
cache_store_log /var/log/squid/store.log
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
auth_param ntlm program /usr/bin/ntlm_auth TESTE/DC01 –helper-protocol=squid-2.5-ntlmssp
auth_param ntlm use_ntlm_negotiate off
auth_param ntlm children 10
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 5 minutes
auth_param basic program /usr/bin/ntlm_auth TESTE/DC01 –helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Digite o LOGIN/SENHA
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern .0 20% 4320
acl all src 192.168.88.0/255.255.255.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl acesso proxy_auth REQUIRED # Solicitando a autenticação
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow acesso # Liberando usuários autenticados
http_access allow all
http_reply_access allow all
icp_access allow all
coredump_dir /usr/local/squid/var/cache
- Criando o cache e iniciando o squid.
# squid -z
# squid &
- Para utilizar as regras baseadas em Grupos do Active Directory, utilize as seguintes linhas no seu squid.conf:
external_acl_type nt_group %LOGIN /usr/lib/squid/wbinfo_group.pl
acl AllowedWindowsGroups external nt_group GrupodoAD
http_access allow AllowedWindowsGroups
Depois de editar o seu squid.conf, não esqueça de recarregá-lo:
# squid –k reconfigure
Reiniciando:
# /etc/init.d/squid restart
Testes:
Efetue a configuração do PROXY no navegador (Servidor Proxy: 192.168.0.1 Porta:3128) e tente acessar algum website.
Monitoramento:
Monitorando o arquivo de log de acessos do squid com o commando tail –f e vemos que
o acesso foi liberado utilizando o usuário dunha, que é o usuário logado na estação de trabalho.
# tail –f /var/log/squid/access.log
1172165029.325 756 192.168.0.10 TCP_MISS/200 9646 GET
http://home.img.uol.com.br/0702/d/festadance.jpg dunha DIRECT/200.221.7.37 text/plain
Bem, não sei se consegui ser claro, mas espero poder ao menos "dar um norte" pra quem está tentando fazer tal recurso rodar em seu ambiente de rede. Até o próximo post pessoal!
