Todos os navegadores cliente solicitam repetidamente a autenticação NTLM ao executar através do servidor proxy local

3

Todos os navegadores clientes solicitam repetidamente a autenticação NTLM ao executar pelo servidor proxy local.

Ao apontar navegadores através do proxy local para a Internet, alguns, mas não todos, os clientes estão sendo repetidamente solicitados a se autenticarem no servidor proxy. Inspecionei os cabeçalhos usando os cabeçalhos ativos do Firefox, bem como o violinista, e em todos os casos os prompts de autenticação acontecem ao solicitar recursos SSL.

um exemplo disso seria o seguinte:

GET http://gmail.google.com/mail/ HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-
flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-
xpsdocument, application/xaml+xml, */*
Accept-Language: en-gb
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive
Host: gmail.google.com


GET http://gmail.google.com/mail/ HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-
flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-
xpsdocument, application/xaml+xml, */*
Accept-Language: en-gb
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive
Host: gmail.google.com
Proxy-Authorization: NTLM 
TlRMTVNTUAABAAAAB7IIogkACQAvAAAABwAHACgAAAAFASgKAAAAD1dJTlhQMUdGTEFHU0hJUDc=


GET http://gmail.google.com/mail/ HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-
flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-
xpsdocument, application/xaml+xml, */*
Accept-Language: en-gb
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive
Proxy-Authorization: NTLM 
TlRMTVNTUAADA (more stuff goes here I cut it short)
Host: gmail.google.com

Neste ponto, o prompt de nome de usuário e senha apareceu no navegador, não importa o que é digitado nesta caixa, credenciais corretas, absurdo aleatório, o navegador não aceita nada nesta caixa, ele continuará a aparecer. Se eu pressionar cancelar, às vezes recebo um erro HTTP 407, mas em outras ocasiões eu clico em cancelar o site continua a baixar e mostrar normalmente.

Isso pode ser repetido com alguns clientes que passam pelo meu servidor proxy, mas em outros casos isso não acontece.

Nos casos em que um computador cliente funciona normalmente, a única diferença que posso ver é que a terceira solicitação de recurso SSL retorna com uma resposta de 200, veja abaixo:

CONNECT gmail.google.com:443 HTTP/1.0
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; MALC)
Proxy-Connection: Keep-Alive
Content-Length: 0
Host: gmail.google.com
Pragma: no-cache
Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAIAAAA
A SSLv3-compatible ClientHello handshake was found.

Eu tentei redefinir as contas de usuários e contas de computador no Active Directory. As contas de usuário e senhas que estão sendo usadas estão corretas e as senhas foram redefinidas para que não fiquem fora de sincronia. Eu removi os clientes e até mesmo o servidor proxy do domínio e reintegrou-os. Instalei um servidor proxy separado completo e obtenho exatamente o mesmo problema quando aponto clientes para um servidor proxy diferente em um endereço IP diferente.

    
por Marko 08.02.2012 / 17:45

1 resposta

1

O ntlm requer sessões tcp com keep alive ativado, já que ele está ligado à conexão tcp, geralmente é desativado por meio de um proxy ou com tempos limite curtos, e muitos proxies também usam http 1.0 = uma solicitação por conexão. ... que essencialmente dá o mesmo problema. altere a autorização para kerberos, digest ou auth simples. nenhum dos dois deve ser um problema se o site estiver em ssl se você executar no modo acelerado.

A melhor opção é se você pode alterar seu software de proxy, procure conexões keep-alive e http 1.1. não tenho experiência de servidor proxy microsoft Eu sou de outro campo, mas tenho certeza que o que você está experimentando é o que eu descrevo.

respeita,

peter

    
por 13.04.2012 / 19:25