Existe um bug no Firefox, fazendo com que o NTLM falhe em certas condições. Usar o Squid como proxy quase sempre atende a essas condições. Consulte o link
Estou usando o squid 2.6.22 (padrão Centos 5) como proxy. O Squid parece quebrar o processo de autenticação de páginas da Web quando elas exigem autenticação NTLM ou Kerberos.
Eu testei com sharepoint 2007 e tentei todos os 3 métodos de autenticação (NTLM, Kerberos, Basic).
Acessando o site sem o squid funciona em todos os casos. Quando eu acesso a mesma página com o squid, somente o basic-auth funciona.
Usar o IE ou o Firefox não faz diferença. O próprio Squid pode ser usado por qualquer pessoa (nenhum auth_param configurado).
É um pouco complicado encontrar soluções on-line, já que a maioria dos tópicos gira em torno do auth_param para autenticar os usuários no squid, em vez de autenticar os usuários em uma página da web por trás do squid.
Alguém poderia ajudar?
Editar:
Desculpe, mas meu primeiro teste foi totalmente errado. Eu testei contra os servidores Web errados (Memo para mim: sempre verifique as suposições antes do teste). Agora percebi que o cenário do problema é completamente diferente.
A propósito: O recurso que fornece NTLM-passthrough no squid é chamado de "conexão pinning" e o cabeçalho HTTP "Proxy-support: Session-based-authentication" "
Existe um bug no Firefox, fazendo com que o NTLM falhe em certas condições. Usar o Squid como proxy quase sempre atende a essas condições. Consulte o link
Acho que o que você está fazendo é muito relativo a Como configurar o apache para autenticação básica ou permitir quando ntlm ao proxy? . Em particular, se você deseja autenticar ambos para proxy e, em seguida, para o site remoto, isso não é possível (a menos que o cliente use CONNECT ).
Se a sua situação é que você não quer autenticar no Squid, mas apenas no site remoto, então acho que o Squid está de alguma forma fazendo a coisa certa: uma vez que o recurso que você buscou se autenticando está no cache, é agora disponível também para solicitações não autenticadas de outros clientes. Mais precisamente, observe este fluxo:
/index.html em algum that.server.com e forneceu as informações de autenticação. /index.html . Cenários possíveis:
/index.html para o usuário B do cache. Isso está errado, pois somente o servidor sabe quais usuários têm acesso a quais recursos. /index.html . Para autenticação básica, o Squid pode capturar o nome de usuário. Outros mecanismos (NTLM / Kerberos) enviam somente hashes sobre HTTP, então não há como aprender o nome de usuário. /index.html .