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.
Atualização:
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 .