Integrando autenticação do Squid ao Active Directory
Implementar autenticação do Squid integrando-o ao Active Directory da Microsoft. Nesse artigo foi usada a versão 3 do Squid juntamente com a versão 2008 do Windows. Minha intenção com essa documentação é reunir todas as experiências que eu coletei e dicas a mim enviadas e que me levaram ao sucesso na implementação dessa solução.
Ambiente
O ambiente usado nesse artigo consiste de um servidor com Windows 2008 e o Active Directory devidamente configurado, mais um servidor proxy Linux. Não vou abordar as configurações desse servidor, pois na internet existem muitas informações sobre essas configurações.
NOTA: Alguns trechos deste artigo foram transcritos de outros tutoriais publicados na internet. No final do documento você encontrará referência para todas as fontes de pesquisa.
Já a segunda é uma pouco mais trabalhosa, pois o Squid irá obter de forma automática usuário e senha, é um "login automático", sem a necessidade de preencher o pop-up com usuário e senha. Abordaremos nesse artigo as duas formas de autenticação.
Primeiramente vamos tratar da integração do Linux ao domínio do AD e da autenticação transparente sem pop-up do Squid, para tal precisaremos instalar em nosso servidor algumas ferramentas tais como Kerberos, Winbind e Samba. Vamos ao Kerberos.
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.
Vamos instalá-lo usando os pacotes disponíveis nos repositórios oficiais do Debian:
# apt-get install krb5-config krb5-user
Agora que ele encontra-se instalado, vamos configurá-lo. Faça uma cópia de segurança do arquivo krb5.conf, a configuração do Kerberos a seguir serve tanto para o Windows 2003 quanto para o Windows 2008, vamos fazer uma cópia de segurança do arquivo /etc/krb5.conf.
# cp -rpvf /etc/krb5.conf /root
# echo "" > /etc/krb5.conf
Agora vamos editar o arquivo colocando o seguinte conteúdo:
# vi /etc/krb5.conf
Observe que temos as entradas dominio.local e DOMINIO.LOCAL, que devem ser substituídas pelo domínio do seu Windows, inclusive se esse for um domínio real (dominio.com.br), deve ser respeitado o texto em caixa alta (DOMINIO.LOCAL).
Salve o arquivo e saia.
Uma coisa muito importante, temos que configurar nosso resolv.conf para o AD, já que ele terá instalado um servidor de DNS, isso é importante pois o DNS do AD ajudará a resolver os nomes facilitando assim a integração do Linux ao domínio da Microsoft.
# vi /etc/resolv.conf
Em seguida vamos ao arquivo /etc/hosts da máquina, para nele inserirmos o ip do servidor do AD:
# vi /etc/hosts
Quando usamos essa solução integrada ao Windows 2003, temos a necessidade de ativar o serviço WINS (Windows Information Service), que nada mais é que um serviço de DNS da Microsoft.
Em nosso servidor Windows (2003/2008) devemos criar no DNS uma entrada para o nosso servidor de impressão, no exemplo estou usando:
Hostname proxy.dominio.local
Ip: 172.16.10.26
Agora vamos testar, para tal usaremos o comando kinit, conforme abaixo:
# kinit Administrador@DOMINIO.LOCAL
Se ele não der erro nenhum está tudo certo. Para listarmos o domínio:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrador@DOMINIO.LOCAL
Valid starting Expires Service principal
12/18/09 16:26:03 12/18/09 23:06:03 krbtgt/DOMINIO.LOCAL@DOMINIO.LOCAL
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cache
Nesse ponto, caso não obtenha a saída acima, podemos incorrer em duas situações, são elas:
# kinit administrator@DOMINIO.COM.BR
Password for administrator@DOMINIO.COM.BR:
kinit(v5): Clock skew too great while getting initial credentials
O relógio não está sincronizado com o controlador de domínio. Para evitarmos esse problema, podemos sincronizar data/hora do nosso servidor com o comando:
# ntpdate ntp.usp.br
E a outra situação:
# kinit administrator@dominio.com.br
Password for administrator@dominio.com.br:
kinit(v5): KDC reply did not match expectations while getting initial credentials
O domínio foi digitado com letras minúsculas. Para corrigir esse erro é só tocar as letras minúsculas do dominio.com.br por maiúsculas, DOMINIO.COM.BR. Lembrando sempre que DOMINIO.LOCAL ou DOMINIO.COM.BR deve ser substituído por seu domínio, seja ele real, ou local. Em seguida vamos passar ao winbind.
NOTA: Alguns trechos deste artigo foram transcritos de outros tutoriais publicados na internet. No final do documento você encontrará referência para todas as fontes de pesquisa.
Tipos de autenticação
Depois de várias pesquisas e de muita interação com a comunidade, pude verificar que basicamente existem dois tipos de autenticação baseadas no Active Directory, a primeira onde não é necessário configuração específica nenhuma, ao setar o endereço do proxy no navegador ele abre uma pop-up pedindo usuário e senha, bastando o usuário colocar login e senha do domínio para ele estar autenticado para acesso a internet.Já a segunda é uma pouco mais trabalhosa, pois o Squid irá obter de forma automática usuário e senha, é um "login automático", sem a necessidade de preencher o pop-up com usuário e senha. Abordaremos nesse artigo as duas formas de autenticação.
Primeiramente vamos tratar da integração do Linux ao domínio do AD e da autenticação transparente sem pop-up do Squid, para tal precisaremos instalar em nosso servidor algumas ferramentas tais como Kerberos, Winbind e Samba. Vamos ao Kerberos.
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.
Vamos instalá-lo usando os pacotes disponíveis nos repositórios oficiais do Debian:
# apt-get install krb5-config krb5-user
Agora que ele encontra-se instalado, vamos configurá-lo. Faça uma cópia de segurança do arquivo krb5.conf, a configuração do Kerberos a seguir serve tanto para o Windows 2003 quanto para o Windows 2008, vamos fazer uma cópia de segurança do arquivo /etc/krb5.conf.
# cp -rpvf /etc/krb5.conf /root
# echo "" > /etc/krb5.conf
Agora vamos editar o arquivo colocando o seguinte conteúdo:
# vi /etc/krb5.conf
[libdefaults]
ticket_lifetime = 24000
default_realm = DOMINIO.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
DOMINIO.LOCAL = {
kdc = 172.16.10.254
admin_server = 172.16.10.254:749
default_domain = 172.16.10.254
}
[domain_realm]
.dominio.local = DOMINIO.LOCAL
dominio.local = DOMINIO.LOCAL
[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
ticket_lifetime = 24000
default_realm = DOMINIO.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
DOMINIO.LOCAL = {
kdc = 172.16.10.254
admin_server = 172.16.10.254:749
default_domain = 172.16.10.254
}
[domain_realm]
.dominio.local = DOMINIO.LOCAL
dominio.local = DOMINIO.LOCAL
[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
Observe que temos as entradas dominio.local e DOMINIO.LOCAL, que devem ser substituídas pelo domínio do seu Windows, inclusive se esse for um domínio real (dominio.com.br), deve ser respeitado o texto em caixa alta (DOMINIO.LOCAL).
Salve o arquivo e saia.
Uma coisa muito importante, temos que configurar nosso resolv.conf para o AD, já que ele terá instalado um servidor de DNS, isso é importante pois o DNS do AD ajudará a resolver os nomes facilitando assim a integração do Linux ao domínio da Microsoft.
# vi /etc/resolv.conf
nameserver 172.16.10.254 # onde o ip é o ip do servidor 2008
Em seguida vamos ao arquivo /etc/hosts da máquina, para nele inserirmos o ip do servidor do AD:
# vi /etc/hosts
172.16.10.253 proxyvm.dominio.local proxyvm # servidor proxy
172.16.10.254 adsrv.dominio.local adsrv # servidor AD
172.16.10.254 dominio.local dominio # servidor AD
172.16.10.254 adsrv.dominio.local adsrv # servidor AD
172.16.10.254 dominio.local dominio # servidor AD
Quando usamos essa solução integrada ao Windows 2003, temos a necessidade de ativar o serviço WINS (Windows Information Service), que nada mais é que um serviço de DNS da Microsoft.
Em nosso servidor Windows (2003/2008) devemos criar no DNS uma entrada para o nosso servidor de impressão, no exemplo estou usando:
Hostname proxy.dominio.local
Ip: 172.16.10.26
Agora vamos testar, para tal usaremos o comando kinit, conforme abaixo:
# kinit Administrador@DOMINIO.LOCAL
Se ele não der erro nenhum está tudo certo. Para listarmos o domínio:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrador@DOMINIO.LOCAL
Valid starting Expires Service principal
12/18/09 16:26:03 12/18/09 23:06:03 krbtgt/DOMINIO.LOCAL@DOMINIO.LOCAL
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cache
Nesse ponto, caso não obtenha a saída acima, podemos incorrer em duas situações, são elas:
# kinit administrator@DOMINIO.COM.BR
Password for administrator@DOMINIO.COM.BR:
kinit(v5): Clock skew too great while getting initial credentials
O relógio não está sincronizado com o controlador de domínio. Para evitarmos esse problema, podemos sincronizar data/hora do nosso servidor com o comando:
# ntpdate ntp.usp.br
E a outra situação:
# kinit administrator@dominio.com.br
Password for administrator@dominio.com.br:
kinit(v5): KDC reply did not match expectations while getting initial credentials
O domínio foi digitado com letras minúsculas. Para corrigir esse erro é só tocar as letras minúsculas do dominio.com.br por maiúsculas, DOMINIO.COM.BR. Lembrando sempre que DOMINIO.LOCAL ou DOMINIO.COM.BR deve ser substituído por seu domínio, seja ele real, ou local. Em seguida vamos passar ao winbind.