Autenticación por usuarios y grupos con Squid

En esta sección se describen los procedimientos para configurar el proxy Squid para autenticar usuarios usando diferentes métidos de autenticación, por ejemplo usando el plugin NCSA, usando usuarios de sistema Unix, usuarios y grupos LDAP y Active Directory.

Introducción a la autenticación de usuarios en Squid

Cuando se configura un servidor Proxy con soporte de autenticación los navegadores web envían las credenciales codificadas del usuario en la petición usando la cabecera Authorization, si el proxy recibe una petición con la cabecera Authorization el proxy descodifica el nombre de usuario y la contraseña para validar el usuario.

La negociación de la autenticación la realiza el programa auxiliar de acuerdo al protocolo soportado, en su mayoría la autenticación es de tipo básica como NCSA, LDAP y otros basados en negociación como NTLM o Kerberos.

Algunos esquemas requieren de la prevía configuración de un sistema como PAM, LDAP, Samba, Kerberos y otros, sin embargo, Squid soporta el esquema de autenticación básica basada en NCSA el cual usa un archivo en el cual mantiene una lista de usuarios y contraseñas codificadas, este es el método más simple de usar, aunque no el más flexible y seguro.

Esquemas de autenticación de usuarios en Squid

Squid por si solo no ofrece soporte para autenticar usuarios, es decir, no tiene los mecanismos necesarios para validar las credenciales de un usuario, sin embargo, squid puede usar programas de autenticación auxiliares (helper programs) para realizar dichas tareas, la ventaja de este sistema de autenticación modular es que permite usar diferentes protocolos de autenticación ó esquemas de autenticación desde los más simples hasta los más seguros, a continuación se listan los esquemas de autenticación más usuales:

Tabla 4.1. Módulos de autenticación de usuarios Squid

Modulo Descripción
NCSA Usa un archivo de usuarios y contraseñas al estilo NCSA
LDAP Usa el protocolo Lightweight Directory Access Protocol
MSNT Usa un dominio de autenticación Windows NT
PAM Usa los módulos de autenticación PAM
SMB Usa un servidor SMB como Windows NT o Samba
getpwam Usa el viejo archivo de contraseñas Unix
SASL Usa las bibliotecas de autenticación SASL
NTLM Usa la autenticación y negociación de autenticación

El soporte de estos programas auxiliares se define desde la compilación de squid, en la mayoría de distribuciones GNU/Linux los módulos antes mencionados están incluidos.

Como se menciono antes la autenticación de usuarios es realizada por programas auxiliares, por lo tanto es un requisito validar la instalación de dichos programas antes de configurar squid para autenticar usuarios usando algún modulo de autenticación básica NCSA.

En las distribuciones Debian/Ubuntu los programas auxiliares de autenticación se encuentran en el directorio /usr/lib/squid3, haga un listado al directorio para verificar la existencia de los módulos:

# ls -l /usr/lib/squid3/
total 364
-rwxr-xr-x 1 root root 24880 2008-02-29 10:41 digest_ldap_auth
-rwxr-xr-x 1 root root 19376 2008-02-29 10:41 digest_pw_auth
-rwxr-xr-x 1 root root 16384 2008-02-29 10:41 diskd
-rwxr-xr-x 1 root root 11536 2008-02-29 10:41 getpwname_auth
-rwxr-xr-x 1 root root 13352 2008-02-29 10:41 ip_user_check
-rwxr-xr-x 1 root root 42864 2008-02-29 10:41 msnt_auth
-rwxr-xr-x 1 root root 20024 2008-02-29 10:41 ncsa_auth
-rwxr-xr-x 1 root root 51352 2008-02-29 10:41 ntlm_auth
-rwxr-xr-x 1 root root 15248 2008-02-29 10:41 pam_auth
-rwxr-xr-x 1 root root 12272 2008-02-29 10:41 sasl_auth
-rwxr-xr-x 1 root root 13392 2008-02-29 10:41 smb_auth
-rwxr-xr-x 1 root root  4010 2008-02-29 10:41 smb_auth.pl
-rwxr-xr-x 1 root root  2280 2008-02-29 10:41 smb_auth.sh
-rwxr-xr-x 1 root root 21136 2008-02-29 10:41 squid_ldap_auth
-rwxr-xr-x 1 root root 23544 2008-02-29 10:41 squid_ldap_group
-rwxr-xr-x 1 root root  7360 2008-02-29 10:41 squid_session
-rwxr-xr-x 1 root root 13648 2008-02-29 10:41 squid_unix_group
-rwxr-xr-x 1 root root 12160 2008-02-29 10:41 unlinkd
-rwxr-xr-x 1 root root  2359 2008-02-29 10:41 wbinfo_group.pl
-rwxr-xr-x 1 root root 12096 2008-02-29 10:41 yp_auth

Autenticación de usuarios NCSA

En la siguiente sección se describen los procedimientos para configurar Squid con autenticación de usuarios NCSA.

Instalando los requisitos para la autenticación de usuarios NCSA

La creación de usuarios y contraseñas NCSA es a través del comando htpasswd, el paquete apache2-utils incluye el comando htpasswd, asegúrese de instalarlo:

# apt-get install apache2-utils

En la siguiente sección veremos como crear un archivo htpasswd para almacenar cuentas de usuario.

Definiendo el modulo de autenticación básica NCSA

Para configurar el modulo de autenticación básica NCSA edite el archivo /etc/squid3/squid.conf y usando la directiva auth_param defina el programa auxiliar de autenticación /usr/lib/squid/ncsa_auth, el programa ncsa_auth recibe como argumento la ruta del archivo donde se almacenan los usuarios y contraseñas, por ejemplo:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid3/usuarios-proxy-passwd
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

En el ejemplo anterior definimos los parámetros de autenticación básica mediante el modulo ncsa_auth usando como archivo de validación de usuarios y contraseñas /etc/squid3/usuarios-proxy-passwd.

La opción children define el número de procesos hijos del programa ncsa_auth que se iniciarán para procesar las tareas de autenticación, si tiene un número considerable de usuarios que se autenticarán con el proxy considere incrementar el número.

La opción realm define el mensaje que aparecerá en la ventana de autenticación del proxy, la directiva credentialttl define el tiempo en el que las credenciales de un usuario autenticado son almacenadas en el sistema para futuras autenticaciones.

La opción casesensitive define si se activa el soporte de reconocimiento de caracteres mayúsculas o minúsculas en las credenciales del usuario.

Creando usuarios y contraseñas NCSA usando htpasswd

Cree un archivo de usuarios y contraseñas NCSA usando el comando htpasswd:

# htpasswd -c /etc/squid3/usuarios-proxy-passwd usuario1
[Importante] Importante

Solo use la opción -c para crear un archivo nuevo, si lo usa después de haber inicializado el archivo la siguiente vez sobre escribirá el archivo.

Para crear nuevos usuarios use:

# htpasswd /etc/squid3/usuarios-proxy-passwd usuario2

Para eliminar un usuario existente use la opción -D para eliminar el usuario, por ejemplo:

# htpasswd -D /etc/squid3/usuarios-proxy-passwd usuario1

Asegúrese de que solo los usuarios de sistema autorizados tienen acceso al archivo, se recomienda que solo el usuario root tenga acceso de lectura y escritura y que el usuario proxy solo tenga acceso de lectura use:

# chown root:proxy /etc/squid3/usuarios-proxy-passwd
# chmod 640 /etc/squid3/usuarios-proxy-passwd

En la siguiente sección veremos como crear ACLs y reglas de acceso en squid para estos usuarios.

Creando listas y reglas de control de acceso basadas en usuarios NCSA

Si deseamos dar acceso a todos los usuarios correctamente autenticados creamos una ACL de tipo proxy_auth, por ejemplo:

acl Usuarios_NCSA proxy_auth REQUIRED

Y en las reglas de acceso permitimos, por ejemplo:

...
http_access allow localhost
http_access allow Usuarios_NCSA
http_access deny all

También es posible construir reglas más granulares basadas en el nombre del usuario, por ejemplo:

...
...
...
acl usuarios_directores proxy_auth usuario1 usuario2 usuario3

O por si fuera poco podemos crear listas ACL basadas en archivos de texto plano, por ejemplo:

...
...
...
acl usuarios_directores proxy_auth "/etc/squid3/usuarios_directores.acl"

El archivo /etc/squid3/usuarios_directores.acl contiene algo así:

$ cat /etc/squid3//usuarios_directores.acl
usuario1
usuario2
usuario3

Creando diferentes perfiles de acceso basados en usuarios NCSA

Aunque el modulo nsca_auth no permite crear grupos para crear diferentes perfiles de acceso al proxy, la flexibilidad de las ACLs de squid nos permite crear diferentes ACLs, por ejemplo:

Creamos 3 diferentes ACLs basadas en listas de usuarios:

Tabla 4.2. Privilegios Squid

ACL Descripción
Internet_Alto Usuarios Privilegiados, sin restricciones
Internet_Medio Usuarios con privilegios medios, tienen restringidos ciertos sitios
Internet_Bajo Solo tiene acceso a algunos sitios específicos

Creamos las ACLs y reglas de acceso en /etc/squid3/squid.conf:

...
...
...
acl Internet_Alto proxy_auth usuario1 usuario2 usuario3
acl Internet_Medio proxy_auth usuario30 usuario31 usuario32
acl Internet_Bajo proxy_auth usuario40 usuario41 usuario42

...
...
...
http_access allow localhost
http_access allow Internet_Alto
http_access allow Internet_Medio !dominios_videos !dominios_porno
http_access allow Internet_Bajo !dominios_videos !dominios_porno !urls_descargas !archivos_multimedia
http_access deny all

Recuerde que si modifica, agrega o elimina acls o reglas de acceso debe reconfigurar squid para que los cambios tomen efecto.

Verificación manual del modulo de autenticación ncsa_auth

La mayoría de los programas auxiliares pueden recibir las credenciales del usuario vía la entrada estándar del shell, el programa recibe una cadena con el formato: usuario contraseña, por ejemplo:

#/usr/lib/squid/ncsa_auth /etc/squid3/usuarios-proxy-passwd
usuario.invalido contraseñafalsa
ERR Success
usuario.valido contraseñavalida
OK

Si la prueba del comando anterior devolvió OK para un usuario valido puede continuar con la siguiente sección.

Autenticación de usuarios y grupos UNIX

TODO

Autenticación de usuarios y grupos LDAP

TODO

Autenticación de usuarios y grupos Active Directory vía NTLM

En esta sección veremos como configurar Squid para la autenticación de usuarios y grupos Active Directory vía NTLM, se verán los procedimientos para instalar los requisitos en el cliente Linux para configurar el cliente Kerberos MIT y Samba para unirse al dominio Active Directory.

Sobre la autenticación de usuarios y grupos con Active Directory y NTLM

Cuando los usuarios inician sesión con el dominio Active Directory el cliente windows crea un ticket Kerberos y este mismo será usado para autenticar a los usuarios con el proxy Squid, este tipo de autenticación es conocido como Single Sign On o SSO.

Para que los usuarios del dominio no tengan que escribir el usuario y contraseña cada vez que vayan a hacer uso del proxy Squid configure el cliente Linux como miembro del dominio usando el cliente Kerberos MIT y Samba para soportar la autenticación NTLM.

Integrando el cliente Linux como miembro de dominio Active Directory vía Kerberos y Samba

En esta sección veremos como integrar un cliente Linux con Kerberos y Samba con un servidor Active Directory para proveer el servicio de autenticación de usuarios y grupos con el proxy Squid.

Requisitos de configuración del cliente Linux para la autenticación de usuarios y grupos con Active Directory

Para configurar la autenticación de usuarios y grupos con Active Directory vía NTLM será necesario configurar el cliente kerberos y samba para unir el equipo al dominio Active Directory, para unir el equipo Linux al dominio Active Directory se requiere lo siguiente:

  • El servidor Linux debe tener configurado el cliente DNS para resolver el dominio DNS para el dominio Active Directory.

  • El nombre DNS del servidor Linux debe de estar registrado en la zona del dominio Active Directory, tanto la resolución directa como inversa.

  • El servidor Linux debe tener el reloj del sistema sicronizado con el servidor Active Directory usando NTP.

  • El servidor Windows Active Directory debe proveer el servicio de sincronización de tiempo NTP.

  • Se requiere tener un usuario administrador (Administrador/Administrator) u otro usuario con los privilegios para unir un equipo al dominio Active Directory.

El registro DNS A para el cliente Linux se crea automáticamente en la zona de resolución directa cuando se une el cliente linux+samba+kerberos al dominio AD. El registro PTR deberá ser creado manualmente en la zona correspondiente.

En el cliente Linux haremos lo siguiente:

  • Configurar el cliente DNS para usar los servidores DNS del dominio Active Directory, el dominio en este ejemplo es example.com.

  • Sincronizar el reloj del sistema vía NTP con el servidor NTP: dc1.example.com.

  • Configurar el cliente kerberos MIT para el realm EXAMPLE.COM usando el servidor KDC: dc1.example.com

  • Configurar el cliente Samba para autenticación kerberos y NTLM usando Samba > 3.0.20

Para los ejemplos descritos en este documento se usa el servidor controlador de dominio AD dc1.example.com con dirección IP 192.168.221.12 el cual es el servidor del catalogo global, KDC para el REALM Kerberos EXAMPLE.COM y además es servidor DNS maestro para el dominio DNS local example.com.

Todas las tareas que realizaremos serán hechas con la cuenta root o usando sudo.

Configuración del cliente DNS con el dominio Active Directory

La autenticación Kerberos depende de la resolución de nombres DNS, por lo que debe configurar el cliente DNS (biblioteca resolver), edite el archivo /etc/resolv.conf y defina el o los servidores DNS en orden de resolución acendente, también debe definir el sufijo DNS, por ejemplo:

# vim /etc/resolv.conf

Con el siguiente contenido:

search example.com
nameserver 192.168.221.12

Después de haber configurado el cliente DNS, realice algunas pruebas de resolución usando la herramienta host o dig, en este caso mostraremos el uso de dig ya que muestra más detalles.

Verifique que puede resolver el nombre de host del servidor Active Directory: dc1.example.com.

# dig dc1.example.com

; <<>> DiG 9.4.2-P2.1 <<>> dc1.example.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35625
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dc1.example.com.               IN      A

;; ANSWER SECTION:
dc1.example.com.        3600    IN      A       192.168.221.12

;; Query time: 0 msec
;; SERVER: 192.168.221.12#53(192.168.221.12)
;; WHEN: Mon Oct 25 23:41:44 2010
;; MSG SIZE  rcvd: 49

También debe verificar la resolución inversa de la dirección IP del servidor Active Directory: 192.168.221.12.

# dig -x 192.168.221.12

; <<>> DiG 9.4.2-P2.1 <<>> -x 192.168.221.12
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40057
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;12.221.168.192.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
12.221.168.192.in-addr.arpa. 1200 IN    PTR     dc1.example.com.

;; Query time: 0 msec
;; SERVER: 192.168.221.12#53(192.168.221.12)
;; WHEN: Mon Oct 25 23:42:48 2010
;; MSG SIZE  rcvd: 74

Asegurese de pueda pueda resolver la dirección del servidor LDAP y Kerberos vía los registros SRV, por lo menos debe resolver los siguientes:

  • _ldap._tcp.example.com.

  • _kerberos._tcp.example.com.

  • _ldap._tcp.dc._msdcs.example.com.

  • _kerberos._tcp.dc._msdcs.example.com.

Realice una prueba de resolución con el comando dig para localizar el servidor LDAP del dominio AD:

# dig -t any _ldap._tcp.dc._msdcs.example.com

; <<>> DiG 9.4.2-P2.1 <<>> -t any _ldap._tcp.dc._msdcs.example.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60661
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.example.com. IN   ANY

;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.example.com. 600 IN SRV    0 100 389 dc1.example.com.

;; ADDITIONAL SECTION:
dc1.example.com.        3600    IN      A       192.168.221.12

;; Query time: 3 msec
;; SERVER: 192.168.221.12#53(192.168.221.12)
;; WHEN: Mon Oct 25 23:45:23 2010
;; MSG SIZE  rcvd: 101

Para localizar el servidor KDC del dominio:

# dig -t any _kerberos._tcp.dc._msdcs.example.com

; <<>> DiG 9.4.2-P2.1 <<>> -t any _kerberos._tcp.dc._msdcs.example.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28253
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;_kerberos._tcp.dc._msdcs.example.com. IN ANY

;; ANSWER SECTION:
_kerberos._tcp.dc._msdcs.example.com. 600 IN SRV 0 100 88 dc1.example.com.

;; ADDITIONAL SECTION:
dc1.example.com.        3600    IN      A       192.168.221.12

;; Query time: 3 msec
;; SERVER: 192.168.221.12#53(192.168.221.12)
;; WHEN: Mon Oct 25 23:51:45 2010
;; MSG SIZE  rcvd: 105

Estos registros son de tipo SRV y son usados por kerberos y Samba para localizar los servicios de autenticación LDAP y Kerberos.

Configuración de la sincronización NTP con Active Directory

Si ya tiene conectividad con el servidor dc1.example.com, entonces ejecute el comando ntpdate para sincronizar el reloj del sistema con el reloj del servidor Active Directory, por ejemplo:

# ntpdate dc1.example.com
[Importante] Importante

Para ejecutar el comando ntpdate debe asegurarse de que el demonio ntp no este en ejecución.

Instale el servidor NTP para mantener sincronizado el reloj del sistema Linux con el servidor dc1.example.com:

# apt-get install ntp

Defina el o los servidores NTP autoritativos en su dominio AD, para este caso es el mismo servidor dc1.example.com, edite el archivo de configuración del cliente NTP /etc/ntp.conf y defina el servidor NTP, por ejemplo:

# vim /etc/ntp.conf

Y defina el servidor NTP local al inicio de la lista:

...
...
...
server dc1.example.com
...
...

Debe reiniciar el servidor NTP para que inicie el proceso de sincronización:

# /etc/init.d/ntp restart

Verificar los peers:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 dc1.example.com .LOCL.           1 u    6   64    1    3.906  2159873   3.906

Una vez que la sincronización del tiempo este configurada siga con la integración del cliente kerberos.

Configurando el cliente Kerberos con Active Directory

La autenticación con el dominio Active Directory vía NTLM requiere que el cliente Kerberos este correctamente configurado, en el servidor Linux instale los programas requeridos para configurar el cliente Kerberos:

# apt-get install krb5-doc krb5-config krb5-user libkrb53 libkadm55

Configure el archivo de configuración del cliente Kerberos /etc/krb5.conf, defina el realm predeterminado EXAMPLE.COM y el servidor KDC dc1.example.com, por ejemplo:

# vim /etc/krb5.conf

Con el siguiente contenido:

[logging]
   default = FILE:/var/log/krb5.log

[libdefaults]
  default_realm = EXAMPLE.COM
  default_tgs_enctypes = DES-CBC-CRC DES-CBC-MD5 RC4-HMAC
  default_tkt_enctypes = DES-CBC-CRC DES-CBC-MD5 RC4-HMAC
  preferred_enctypes = DES-CBC-CRC DES-CBC-MD5 RC4-HMAC 
  dns_lookup_realm = true
  dns_lookup_kdc = true
  ticket_lifetime = 24h
  forwardable = true
  proxiable = true

[realms]
   EXAMPLE.COM = {
           kdc = dc1.example.com
           admin_server = dc1.example.com
           default_domain = example.com
   } 

[domain_realm]
   .example.com = EXAMPLE.COM
   example.com = EXAMPLE.COM

Ahora usaremos el comando kinit para verificar que el cliente Linux se pueda autenticar con un servidor Kerberos Active Directory y que podamos obtener un Ticket Granting Ticket (TGT) desde el servidor KDC Windows Active Directory.

Si tenemos una cuenta de administrador en el directorio probamos:

# kinit -V administrador@EXAMPLE.COM
Password for administrador@EXAMPLE.COM:
Authenticated to Kerberos v5

Ahora usamos el comando klist para mostrar un listado de los tickets obtenidos:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrador@EXAMPLE.COM

Valid starting     Expires            Service principal
10/26/10 00:10:14  10/26/10 10:10:22  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 10/27/10 00:10:14


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Ahora haremos una prueba usando el cliente de dominio ordinario:

# kinit -V jperez@EXAMPLE.COM

# klist
[Nota] Nota

El servidor Linux debe ser capaz de establecer una conexión al servicio Kerberos en el puerto TCP/88, asegurese de que no haya alguna regla del firewall que este bloqueando el acceso.

Si estas pruebas pasaron exitosamente puede continuar con la configuración del cliente Samba.

Configurando el cliente Samba como Miembro de Dominio AD 2003

Para la autenticación de usuarios y grupos con Active Directory vía NTLM se requiere que se instale un entorno Samba/Winbind para realizar la negociación, Samba a su vez debe ser configurado con el tipo de seguridad ADS (Active Directory Security) para usar el realm kerberos EXAMPLE.COM y el servidor de contraseñas dc1.example.com. El cliente Linux estará configurado para usar el nombre NetBIOS FWPROXY.

Instale los programas requeridos para configurar el cliente Samba para integrar la autenticación con Active Directory vía NTLM:

# apt-get install samba smbclient winbind

Detenga los servicios samba y winbind para iniciar una configuración desde cero:

# /etc/init.d/winbind stop

# /etc/init.d/samba stop

# rm -rf /var/cache/samba/*.{tdb,bdb}

Edite el archivo de configuración de samba /etc/samba/smb.conf para configurar el cliente con autenticación con Active Directory:

# vim /etc/samba/smb.conf

Con el siguiente contenido:

#
# Parametros globales para cliente AD
#

[global]
  workgroup = EXAMPLE
  netbios name = fwproxy
  server string = Servidor Proxy de Dominio
  security = ADS
  realm = EXAMPLE.COM
  password server = dc1.example.com
  preferred master = No

  interfaces = eth1 lo
  bind interfaces only = Yes

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

  syslog = 0
  #log level = 1
  log level = 3 passdb:5 auth:10 winbind:5
  log file = /var/log/samba/%m.log
  max log size = 50
[Nota] Nota

Esta configuración tiene un nivel de debug algo alto y se registrará bastante actividad en los logs de winbindd en el directorio /var/log/samba, cambie el log level a 1 cuando las pruebas hayan terminado o requiera diagnosticar algún problema.

Una el equipo al dominio Active Directory usando el comando net ads join, use una cuenta con privilegios de administrador o que pertenezca al grupo de dominio Domain Admins, por ejemplo:

# net ads join -U administrador@EXAMPLE.COM
administrador@EXAMPLE.COM's password: 
Using short domain name -- EXAMPLE
Joined 'FWPROXY' to realm 'EXAMPLE.COM'
[Nota] Nota

En el momento en que se une la maquina al dominio AD, se crea una cuenta de computadora llamada FWPROXY en directorio, también se crea el registro A fwproxy en la zona de resolución directa example.com.

[Importante] Importante

En este momento se recomienda que cree el registro PTR para el nombre fwproxy.example.com en la zona de resolución inversa, por ejemplo, en 221.168.192.in-addr.arpa.

Inicie Samba y winbindd:

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

Use el comando net ads info para validar la conexión con el controlador de dominio Active Directory:

# net ads info
LDAP server: 192.168.221.12
LDAP server name: dc1.example.com
Realm: EXAMPLE.COM
Bind Path: dc=EXAMPLE,dc=COM
LDAP port: 389
Server time: Wed, 27 Oct 2010 16:35:52 CDT
KDC server: 192.168.221.12
Server time offset: 18000

Tambien puede usar la opción lookup para ver más información:

# net ads lookup
Information for Domain Controller: 192.168.221.12

Response Type: SAMLOGON
GUID: a156082e-2c29-4227-a371-89397c73cd69
Flags:
        Is a PDC:                                   yes
        Is a GC of the forest:                      yes
        Is an LDAP server:                          yes
        Supports DS:                                yes
        Is running a KDC:                           yes
        Is running time services:                   yes
        Is the closest DC:                          yes
        Is writable:                                yes
        Has a hardware clock:                       yes
        Is a non-domain NC serviced by LDAP server: no                                                                                                 
Forest:                 example.com                                                                                                                    
Domain:                 example.com                                                                                                                    
Domain Controller:      dc1.example.com                                                                                                                
Pre-Win2k Domain:       EXAMPLE                                                                                                                        
Pre-Win2k Hostname:     DC1                                                                                                                            
Server Site Name :              Nombre-predeterminado-primer-sitio                                                                                     
Client Site Name :              Nombre-predeterminado-primer-sitio                                                                                     
NT Version: 5                                                                                                                                          
LMNT Token: ffff                                                                                                                                       
LM20 Token: ffff

Verifique la autenticación vía winbindd:

# wbinfo -t
checking the trust secret via RPC calls succeeded

Haga un listado de cuentas de dominio usando el comando wbinfo y el parámetro -u, por ejemplo:

# wbinfo -u
administrador
invitado
support_388945a0
krbtgt
jperez

Haga un listado de grupos de dominio usando el comando wbinfo con el parámetro -g, por ejemplo:

# wbinfo -g
BUILTIN\administrators
BUILTIN\users
equipos del dominio
controladores de dominio
administradores de esquema
administradores de organización
admins. del dominio
usuarios del dominio
invitados del dominio
propietarios del creador de directivas de grupo
dnsupdateproxy
internet_alto
internet_medio
internet_bajo
internet_ftp
internet_messenger
[Nota] Nota

Se muestran los grupos predeterminados y algunos otros grupos que se crearon para el acceso al proxy.

Puede usar el script /usr/lib/squid3/wbinfo_group.pl para validar si un usuario pertenece a algún grupo:

# /usr/lib/squid3/wbinfo_group.pl
jperez internet_alto
OK

Si obtiene Ok como resultado significa que el usuario si pertenece al grupo, si el usuario no pertenece al grupo recibirá el mensaje de ERR.

Use el comando wbinfo con el parámetro -a para verificar que la autenticación challenge/response y plain text funcionen, por ejemplo:

# wbinfo -a EXAMPLE\\jperez%jP3rez123
plaintext password authentication succeeded
challenge/response password authentication succeeded

Verifique la integración kerberos y samba:

# kinit -V administrador@EXAMPLE.COM

Verifique que el ticket se haya creado:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrador@EXAMPLE.COM

Valid starting     Expires            Service principal
10/26/10 00:36:21  10/26/10 10:36:28  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 10/27/10 00:36:21


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Ahora iniciamos sesión al servidor AD usando autenticación Kerberos (-k), si todo va bien nos deberíamos de autenticar usando el ticket que obtuvimos arriba.

# smbclient //dc1/share1 -k
OS=[Windows Server 2003 R2 3790 Service Pack 2] Server=[Windows Server 2003 R2 5.2]
smb: \> quit

Verifique los tickets:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrador@EXAMPLE.COM

Valid starting     Expires            Service principal
10/26/10 00:36:21  10/26/10 10:36:28  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 10/27/10 00:36:21
10/26/10 00:37:06  10/26/10 10:36:28  dc1$@EXAMPLE.COM
        renew until 10/27/10 00:36:21


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Destruya el ticket y verifique que la autenticación con el servidor vía samba falle:

# kdestroy

# smbclient -L //dc1/share1 -k
cli_session_setup_kerberos: spnego_gen_negTokenTarg failed: No credentials cache found
session setup failed: SUCCESS - 0

Si todas las pruebas anteriores funcionaron continué con la integración de Squid con la autenticación de usuarios y grupos Active Directory.

Definiendo el modulo de autenticación NTLM para usuarios Active Directory

Usaremos el programa auxiliar de autenticación ntlm_auth incluido en Samba 3.x para realizar la autenticación de usuarios en Active Directory tanto para la autenticación NTLM y Básica.

Editamos el archivo de configuración de Squid para activar el soporte de autenticación de usuarios Active Directory usando el modulo ntlm_auth usando el programa /usr/bin/ntlm_auth, por ejemplo:

# Primer instancia de autenticación: NTLM Single Sign On (Usa login de dominio AD)
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 10
auth_param ntlm keep_alive on

# Segunda instancia de autenticación Básica usando NTLM basica, es útil para usarios
# invitados o equipos que no son parte del dominio AD, la autenticación es mediante
# un popup en el cual solicita un usuario y contraseña.
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 10
auth_param basic realm Servidor Proxy Dominio EXAMPLE.COM
auth_param basic credentialsttl 2 hours

Note que cuando use la autenticación NTLM, verás dos entradas de TCP_DENIED/407 en el archivo access.log por cada petición. Esto es debido al proceso challenge-response process de NTLM.

Definiendo el modulo de autenticación externa para grupos AD

Para crear controles de acceso basado en grupos Active Directory defina el tipo de autenticación externa usando el programa /usr/bin/squid3/wbinfo_group.pl, el programa recibe el argumento ttl para definir el tiempo de vida en segundos durante el cual se cacheará el resultado, también permite el argumento children para definir el número de procesos hijos (default 5), también debe definir el atributo %LOGIN, por ejemplo:

# Programa externoa para definición de ACLs basadas en grupos Active Directory
external_acl_type Grupo_AD ttl=10 children=10 %LOGIN /usr/lib/squid3/wbinfo_group.pl

Cuando cree elementos de ACL basadas en grupos use el tipo external Grupo_AD como se verá en la siguiente sección.

Creando listas y reglas de control de acceso para usuarios y grupos AD

Para crear una ACL para todos los usuarios autenticados use:

acl Usuarios_AD_Autenticados proxy_auth REQUIRED

Para crear una ACL basada en un grupo Active DIrectory use:

# ACL para grupo de dominio Active Directory Internet_Alto
acl Grupo_AD_Internet_Alto external Grupo_AD Internet_Alto

# ACL para grupo de dominio Active Directory Internet_Medio
acl Grupo_AD_Internet_Medio external Grupo_AD Internet_Medio

# ACL para grupo de dominio Active Directory Internet_Bajo
acl Grupo_AD_Internet_Bajo external Grupo_AD Internet_Bajo

# ACL para grupo de dominio Active Directory Sin_Internet
acl Grupo_AD_Sin_Internet external Grupo_AD Sin_Internet

Ejemplo configuración de ACLs con autenticación basada en usuarios y grupos Active Directory con bloqueo de dominios, URLs y archivos adjuntos prohibidos y multimedia usando diferentes perfiles de acceso:

#
# ACL elements:
#
...
...
...

acl all src all

acl localhost src 127.0.0.1/32

acl Safe_ports port 80 21 443 563 70 210 1025-65535

acl SSL_ports port 443

acl CONNECT method CONNECT

acl loc_subnet src 192.168.221.0/24

acl Usuarios_AD_Autenticados proxy_auth REQUIRED

acl Grupo_AD_Internet_Alto external Grupo_AD Internet_Alto
acl Grupo_AD_Internet_Medio external Grupo_AD Internet_Medio
acl Grupo_AD_Internet_Bajo external Grupo_AD Internet_Bajo

acl Grupo_AD_Sin_Internet external Grupo_AD Sin_Internet

acl dominios_videos dstdomain .youtube.com .justin.tv

acl dominios_porno dstdomain "/etc/squid3/dominios_porno.acl"

acl urls_descargas url_regex -i rapidshare megaupload

acl archivos_multimedia urlpath_regex -i \.mp3$ \.mp4$ \.wma$ \.avi$ \.wmv$ \.mov$ \.mpg$ \.mpeg$ \.ram$ \.vob$

acl req_mimetype_audio req_mime_type -i ^audio/mp3$ ^audio/mp4$ ^audio/mpeg$ ^audio/wav$ ^audio/x-mp3$ ^audio/x-mp4$
acl rep_mimetype_audio rep_mime_type -i ^audio/mp3$ ^audio/mp4$ ^audio/mpeg$ ^audio/wav$ ^audio/x-mp3$ ^audio/x-mp4$

acl req_mimetype_video req_mime_type -i ^video/avi$ ^audio/mpeg$ ^video/ogg$ ^video/quicktime$ ^video/x-ms-wmv$
acl rep_mimetype_video rep_mime_type -i ^video/avi$ ^audio/mpeg$ ^video/ogg$ ^video/quicktime$ ^video/x-ms-wmv$

acl req_mimetype_flash req_mime_type -i ^video/flash$ ^video/flv$ ^video/x-flv$ ^video/x-shockwave-flash$ ^video/x-swf$
acl rep_mimetype_flash rep_mime_type -i ^video/flash$ ^video/flv$ ^video/x-flv$ ^video/x-shockwave-flash$ ^video/x-swf$

#
# Access lists:
#
...
...
...

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost

http_access deny Grupo_AD_Sin_Internet

http_access deny req_mimetype_audio req_mimetype_video req_mimetype_flash

http_access allow Grupo_AD_Internet_Alto
http_access allow Grupo_AD_Internet_Medio !dominios_videos !archivos_multimedia
http_access allow Grupo_AD_Internet_Bajo !dominios_videos !dominios_porno !archivos_multimedia

http_access allow Usuarios_AD_Autenticados !dominios_videos !dominios_porno !urls_descargas !archivos_multimedia

http_access deny all

http_reply_access deny rep_mimetype_audio rep_mimetype_video rep_mimetype_flash

Recuerde verificar y reconfigurar squid después de realizar cambios.

Integrando Squid con Winbind para la autenticación NTLM con AD

Cuando usamos el modulo de autenticación externa wbinfo_group es importante hacer notar que squid es un cliente de winbindd, la comunicación entre squid y winbindd se realiza mediante el archivo de socket unix en el directorio /var/run/samba/winbindd_privileged, para que squid se pueda comunicar requerimos que el usuario con el que se ejecuta el proceso squid y sus helpers tenga permisos para acceder al dicho directorio, en Ubuntu simplemente hacemos:

# usermod -a -G winbindd_priv proxy

Re iniciamos el servicio squid para que el cambio de permisos tome efecto:

# /etc/init.d/squid3 restart

TODO: Validar si con un reconfigure es suficiente.

Al recargar squid en el log /var/log/squid3/cache.log deberá de ver estas dos nuevas lineas:

[2010/10/26 00:41:12, 3] libsmb/ntlmssp.c:debug_ntlmssp_flags(63)            
  Got NTLMSSP neg_flags=0xa2088207                                           
[2010/10/26 00:41:12, 3] libsmb/ntlmssp.c:ntlmssp_server_auth(739)           
  Got user=[jperez] domain=[EXAMPLE] workstation=[WINPC001] len1=24 len2=24

Además veremos algunos procesos extras:

# ps aux | grep squid
root      7737  0.0  0.3  32480  1836 ?        Ss   00:40   0:00 /usr/sbin/squid3 -D -sYC
proxy     7739  0.8  1.8  39312  9916 ?        R    00:40   0:03 (squid) -D -sYC
proxy     7740  0.0  0.4  57124  2388 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7744  0.0  0.4  57124  2392 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7745  0.0  0.4  55028  2180 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7746  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7747  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7748  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7749  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7750  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7751  0.0  0.4  55028  2180 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7752  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-ntlmssp
proxy     7753  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7754  0.0  0.4  55028  2180 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7755  0.0  0.4  55028  2180 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7756  0.0  0.4  55028  2180 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7757  0.0  0.4  55028  2180 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7758  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7759  0.0  0.4  55028  2180 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7760  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7761  0.0  0.4  55028  2184 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7762  0.0  0.4  55028  2180 ?        Ss   00:40   0:00 (ntlm_auth) --helper-protocol=squid-2.5-basic
proxy     7763  0.0  0.4  18252  2496 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7764  0.0  0.4  18252  2496 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7765  0.0  0.4  18252  2492 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7766  0.0  0.4  18252  2496 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7767  0.0  0.4  18252  2496 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7768  0.0  0.4  18252  2496 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7769  0.0  0.4  18252  2496 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7770  0.0  0.4  18252  2492 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7771  0.0  0.4  18252  2496 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl
proxy     7772  0.0  0.4  18252  2496 ?        Ss   00:40   0:00 /usr/bin/perl -w /usr/lib/squid3/wbinfo_group.pl

Note que el número de procesos dependerá de el número de hijos que definio en los parámetros del programa auxiliar.

Verificación manual del modulo de autenticación ncsa_auth

Ejecute el comando /usr/bin/ntlm_auth con el parámetro --helper-protocol=squid-2.5-basic desde un shell para validar la autenticación del modulo, el programa recibe una cadena con el formato: usuario contraseña, por ejemplo:

# /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
EXAMPLE\jperez badpass
[2010/03/10 23:51:03, 3] utils/ntlm_auth.c:check_plaintext_auth(298)
  NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc000006a)
ERR
EXAMPLE\jperez squid00123*_
[2010/03/10 23:51:13, 3] utils/ntlm_auth.c:check_plaintext_auth(298)
  NT_STATUS_OK: Success (0x0)
OK

Si la prueba del comando anterior devolvió OK para un usuario valido puede continuar con la siguiente sección.