Era uma vez uma bela floresta virtual quente na américa do sul, e um servidor de lula vivia lá. aqui está uma imagem perceptual da rede:
<the Internet>
|
|
A | B
Users <---------> [squid-Server] <---> [LDAP-Server]
Quando Users solicitar acesso à Internet, squid pergunta seu nome e passaporte, autentica-os por LDAP e, se o ldap os aprovar, ele os concede.
Todos ficaram felizes até que alguns sniffers roubaram o passaporte no caminho entre os usuários e o squid [caminho A]. Este desastre aconteceu porque o squid usou o método Basic-Authentication .
As pessoas da selva se reuniram para resolver o problema. Alguns coelhinhos ofereceram usando NTLM do método. Serpentes preferiram Digest-Authentication enquanto Kerberos recomendado por árvores.
Afinal, muitas soluções oferecidas por pessoas da selva e tudo estava confuso! O Leão decidiu acabar com a situação. Ele gritou as regras para soluções:
Então, uma solução muito abrangente e inteligível oferecida por um macaco, fazendo dele o novo rei da selva!
você consegue adivinhar qual foi a solução?
Dica:
O caminho entre squid e LDAP é protegido pelo leão, então a solução não deve protegê-lo.
Nota: desculpe se a história é chata e confusa, mas a maior parte é real! =)
/~\/~\/~\ /\~/~\/~\/~\/~\ ((/~\/~\/~\/~\/~\)) (/~\/~\/~\/~\/~\/~\/~\) (//// ~ ~ \\) (\\( (0) (0) )////) (\\( __\-/__ )////) (\\( /-\ )///) (\\( (""""") )///) (\\( \^^^/ )///) (\\( )///) (\/~\/~\/~\/) ** (\/~\/~\/) *####* | | **** /| | | |\ \ _/ | | | | \_ _________// Thanks! (,,)(,,)_(,,)(,,)--------'
Massimo explicou que o método de autenticação entre Users - squid e squid - LDAP faz não tem que ser o mesmo. Podemos usar o método de arbitragem para obter informações de autenticação de usuários e método arbitrário para dados coletados autenticados.
Mas há um problema: a entrada / saída de todos os tipos de autenticadores não é a mesma. Por exemplo:
Basic authenticator deve ler o par "senha do nome de usuário" em uma linha e responder a OK se o passo do usuário estiver correto ou ERR
Digest deve ler username:realm e responder uma codificação hexadecimal de HA(A1) ou ERR . Embora não haja relação direta entre o método cliente-squid e o método squid-ldap, os dados coletados do cliente devem ser compatíveis com o método usado na parte do squid-ldap. Portanto, se alterarmos o método de autenticação no lado do usuário, talvez devamos alterar nosso autenticador também.
O problema simplifica para:
No primeiro nível, eu (o macaco!) estou procurando um bom método de autenticação no lado do usuário. Qual método você recomenda qual é seguro e suportado pela maioria dos navegadores ? Estou confuso entre NTLM , Kerberos e Digest .
Onde posso encontrar um autenticador que suporte informações de credenciais do método selecionado e autentique por meio do LDAP.
Um recurso interessante que pode ajudá-lo aqui é que o método que o Squid usa para solicitar ao navegador do cliente autenticação (caminho A) não precisa ser relacionado ao método que ele usa para validar as credenciais fornecidas pelo usuário. (caminho B). Isto significa, por exemplo, que você pode fazer o Squid "falar" com navegadores clientes, mas então pode muito bem validar os usuários contra o banco de dados do usuário interno do Linux (/ etc / passwd). Não há nenhuma necessidade de credenciais adquiridas usando o NTLM (no caminho A) para serem realmente validadas contra um domínio do Windows (no caminho B). O mesmo se aplica a qualquer combinação possível de métodos de autenticação do lado do cliente e autenticação do lado do servidor.
O que isso significa no seu caso, é que f.e. você pode configurar com segurança o Squid para solicitar a autenticação NTLM dos navegadores cliente em vez da autenticação básica, e isso não exigirá que você realmente use Samba / WinBind / AD / whatever.
Assim, você pode escolher qualquer método que desejar para a autenticação do lado do cliente, mas ainda assim manter a validação dos usuários em relação a um servidor LDAP depois que eles fornecerem suas credenciais usando o método selecionado.
A mágica acontece, é claro, em squid.conf :
#auth_param negotiate program <uncomment and complete this line to activate>
#auth_param negotiate children 5
#auth_param negotiate keep_alive on
#auth_param ntlm program <uncomment and complete this line to activate>
#auth_param ntlm children 5
#auth_param ntlm keep_alive on
#auth_param digest program <uncomment and complete this line>
#auth_param digest children 5
#auth_param digest realm Squid proxy-caching web server
#auth_param digest nonce_garbage_interval 5 minutes
#auth_param digest nonce_max_duration 30 minutes
#auth_param digest nonce_max_count 50
#auth_param basic program <uncomment and complete this line>
#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
Cada diretiva auth_param ativa uma autenticação específica para navegadores clientes (caminho A), enquanto a parte "programa" define o que o Squid realmente usa para validar as credenciais fornecidas pelos usuários. Você pode usar qualquer programa autenticador que quiser aqui (até mesmo um personalizado), contanto que ele possa receber um ID de usuário e uma senha e responder "sim" ou "não".
Você só precisa usar o autenticador que estiver usando para fazer sua consulta LDAP e colocá-lo nas instruções "auth_param ntlm" ou "auth_param digest", em vez do "auth_param basic", onde está agora.
Você deve definitivamente usar squid_ldap_auth como seu autenticador, mas não posso dizer exatamente < em> como sem nenhum detalhe sobre o servidor LDAP específico que você está usando.
Em relação à autenticação do lado do cliente, qualquer um deve ser bom; Estou muito feliz com o NTLM, e a maioria dos navegadores o suportam hoje em dia.
Tal configuração ficaria assim no squid.conf:
auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>
Isso solicitará as credenciais do usuário (caminho A) usando o NTLM e, em seguida, as validará em relação a um servidor LDAP (caminho B); mas esses "parâmetros" dependem estritamente da sua implementação e configuração LDAP.
Isso também pode ajudar: link .