AUTENTICANDO SQUID COM NTLM NO CENTOS. [RESOLVIDO]

1. AUTENTICANDO SQUID COM NTLM NO CENTOS. [RESOLVIDO]

filipenido
(usa CentOS)

Enviado em 23/12/2014 - 12:18h

Depois de vasculhar a internet em busca de um tutorial que ajudasse a configurar um Proxy NTLM no AD 2008 e no Windows Small Business 2011 eis que finalmente consegui com sucesso esta proeza. Vou postar o que interessa sem rodeios e firulas.

Mãos à massa.
Este tutorial foi homologado no windows 2008 e 2011 com Centos 5.9 e 6.5

Primeiro passo é configurar os arquivos de hosts e resolv.conf:

##################################################################################################

vim /etc/hosts

127.0.0.1 localhost.localdomain localhost
192.168.100.47 proxy.techfreaks.intranet proxy
192.168.100.45 win2008.techfreaks.intranet win2008 techfreaks.intranet

e

vim /etc/resolv.conf

search techfreaks.intranet

nameserver 192.168.100.45

##################################################################################################

Agora, vamos realizar a instalação dos pacotes do Kerberos: (vide O que é o Kerberos no final do tópico.)

Instalando e Configurando o arquivo de configuração do Kerberos 5.

yum install pam_krb5.x86_64 krb5-server.x86_64 krb5-workstation.x86_64 krb5-libs.x86_64

Vamos para configuração:

vim /etc/krb5.conf

##################################################################################################

[libdefaults]
ticket_lifetime = 24000
default_realm = TECHFREAKS.INTRANET
dns_lookup_realm = false
dns_lookup_kdc = false

[realms]
TECHFREAKS.INTRANET = {
kdc = win2008.techfreaks.intranet
admin_server = win2008.techfreaks.intranet:749
default_domain = win2008.techfreaks.intranet
}

[domain_realm]
.dominio.local = TECHFREAKS.INTRANET
dominio.local = TECHFREAKS.INTRANET

[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

##################################################################################################

Execute o comando abaixo para estabelecer a comunicação com o AD via Kerberos :

kinit admin.proxy

Ex.:

% kinit
Password for your_name@YOUR.RELAM
Se a senha estiver correta, o usuário terá um TGT. Pode-se verificar isto usando o comando klist:

klist

Ex.:

% klist
Ticket cache: /var/tmp/krb5cc_1234
Default principal: your_name@YOUR.REALM
Valid starting
Expires
Service principal
24-Jul-95 12:58:02
24-Jul-95 20:58:02
krbtgt/YOUR.REALM @YOUR.REAL

##################################################################################################

Instalando Samba e pacote de utilitários de DNS.

yum install samba bind-utils

Reinicie os serviços:

/etc/init.d/winbind restart
/etc/init.d/smb restart
/etc/init.d/nmb restart

Edite o arquivo de configuração do Samba.
vim /etc/samba/smb.conf

##################################################################################################

[global]
unix charset = ISO-8859-1
workgroup = TECHFREAKS
netbios name = SRVPROXY
server string = Servidor Proxy
log level = 5
load printers = no
log file = /var/log/samba/log.%m
max log size = 500
realm = techfreaks.intranet
security = ads
auth methods = winbind
#password server = win2003.dominio.local # Endereco do servidor de autenticacao nome/ip
password server = win2008.techfreaks.intranet
winbind separator = +
encrypt passwords = yes
printcap name = cups
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
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
local master = no
os level = 233
domain master = no
preferred master = no
domain logons = no
#wins server = 172.16.20.150 # So deve ser descomentado se o servidor Windows for um 2003
dns proxy = no
ldap ssl = no
printing = cups
disable spoolss = yes
show add printer wizard = no
template shell = /bin/bash
template homedir = /home/%U

##################################################################################################

Sincronize a hora com o servidor AD.

ntpdate 192.168.100.45

Ingresse o servidor no domínio:

Para isso foi necessário a criação de uma conta com privilégio de administrador e o grupo criado foi um grupo com o nome de autenticado, este grupo será utilizado nas configurações do squid.
net ads join techfreaks.intranet -U admin.proxy

Se ocorrer o erro:

Enter administrador’s password:
Failed to join domain: failed to lookup DC info for domain ‘techfreaks.intranet’ over rpc: Logon failure

Sugiro que reveja as entradas de DNS no arquivo de hosts e resolv.conf.

Realizando checagem no AD utilizando wbinfo:

Para usuário:

wbinfo -u

Para grupo:

wbinfo -g

Realize a liberação no firewall:

iptables -I INPUT -s 192.168.0.0/16 -p tcp --dport 3128 -j ACCEPT

Abaixo o squid.conf original apenas com as entradas para ntlm, pode copiar sem medo de ser feliz.
##################################################################################################

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
external_acl_type nt_group %LOGIN /usr/lib64/squid/wbinfo_group.pl

acl senha proxy_auth REQUIRED

#
# Recommended minimum configuration:
#
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
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 autenticado external nt_group autenticado

#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on “localhost” is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow autenticado
http_access allow localnet senha
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid

# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

Reinicie os serviços do squid e teste.

##################################################################################################

O que é o Kerberos?

“Kerberos é um sistema de autenticação que permite usuários utilizarem serviços de rede se identificando e autenticando em tempo real, utilizando um sistema seguro e criptografado. Em um sistema convencional é requerido ao usuário uma identificação e que este usuário autentique esta identificação antes da utilização do sistema. Uma rede que conecta possíveis clientes a serviços por ela providos também precisa identificar e autenticar estes clientes, que podem ser usuários ou softwares.

O problema é que muitos serviços de rede aceitam sem questionar a autenticação provida pela máquina cliente, que está sobre total domínio do usuário. E um serviço seguro de rede não pode confiar na integridade da autenticação provida por uma máquina cliente. Com o Kerberos, toda vez que um possível cliente for utilizar um serviço da rede, ele vai questionar sua identidade e a respectiva autenticação, permitindo ou não o uso do serviço pelo cliente. Além disso, Kerberos provê um meio criptografado de comunicação, mesmo em uma rede não segura, como a internet. O sistema de autenticação Kerberos é baseado no protocolo de autenticação de três vias e foi desenvolvido pelos membros do projeto Athena no MIT (Massachusetts Institute of Technology). O Kerberos provê aos usuários ou serviços “ticket” que são utilizados para a identificação e chaves criptografadas para comunicação pela rede. O Kerberos é usualmente utilizado na camada de aplicação, provendo a segurança entre o usuário e o host. Mas também pode ser usado para prover segurança entre hosts, trabalhando com os protocolos IP, TCP e UDP. Em uma rede com Kerberos é definido um host, denominado Servidor de Autenticação, que centraliza as funções administrativas do Kerberos e é onde também está o Centro de Distribuição de Chaves (KDC). Este servidor mantém uma base de dados com todas as senhas secretas dos usuários. Sendo que ele é o responsável por gerar os tickets quando dois usuários desejam se comunicar através de um meio seguro, identificando e autenticando estes usuários.” -Google

2 0

Quote