Squid, autenticação, Outlook Anywhere, Windows 7 e HTTP 1.1 = NIGHTMARE

5

Estou executando um proxy Squid (versão mais recente, 3.1.4) no Linux CentOS 5.4 com o Samba 3.5.4, para permitir acesso autenticado à Web para usuários do domínio; tudo funciona bem, e até mesmo os clientes do Windows 7 são totalmente suportados. A autenticação é transparente para os usuários do domínio, enquanto é explicitamente solicitada para os que não são de domínio, e funciona se o usuário puder fornecer credenciais de domínio válidas. Tudo bom e bom.

Em seguida, o Outlook em Qualquer Lugar entra em ação e a dor e o sofrimento acontecem.

Quando o Outlook (seja 2007 ou 2010, não importa) é executado em clientes Windows XP, ele se conecta normalmente através do proxy Squid ao seu servidor Exchange remoto.

Quando é executado no Windows 7, não funciona.

Se o requisito de autenticação for retirado do proxy, tudo funcionará no Windows 7 também, portanto, o problema está obviamente relacionado à autenticação NTLM com o Squid.

Pesquisando mais profundamente (WireShark), descobri que o Outlook em Qualquer Lugar usa HTTP 1.1 quando é executado no Windows 7, enquanto usa HTTP 1.0 quando no Windows XP. E parece que o Squid, mesmo em sua última encarnação, ainda tem alguns problemas sérios com o HTTP 1.1 corretamente, particularmente quando a autenticação SSL e proxy são lançadas na mistura.

Enquanto aguarda o suporte total e oficial do Squid HTTP 1.1 (e parece que isso pode levar bastante muito tempo), estou procurando uma das seguintes soluções:

  • Faça o Squid lidar com isso corretamente, se for possível.
  • Identifique as conexões do Outlook em Qualquer Lugar e faça com que o Squid não precise de autenticação para elas. Mas não é fácil: novamente, o comportamento do Outlook é diferente quando executado no Windows XP e no Windows 7 e, enquanto no Windows XP o Outlook envia uma seqüência muito amigável de "MSRPC", no Windows 7 ele não é enviado any (why? PORQUÊ ?!?).
  • Force o Outlook Anywhere a usar HTTP 1.0 mesmo quando executado no Windows 7. E não, isso não é tão simples como desmarcar "usar HTTP 1.1" no Internet Explorer, parece que o Outlook ignora essa configuração e escolhe por conta própria qual protocolo usar use.
  • Qualquer outra solução viável que não envolva a lista de permissões de servidores Exchange de destino específicos, que é a solução de último recurso que estou tentando evitar.
por Massimo 09.07.2010 / 09:24

3 respostas

1

Windows 7, Server 2008 e acredito que até o Vista não suporta NTLMv1 por padrão. Se estiver trabalhando no XP, mas não no Windows 7, eu começaria habilitando o NTLMv1 e verificando se isso resolve o problema. Aqui está o post que me ajudou quando eu tive um problema semelhante. Windows7 - “A senha de rede especificada não está correto. ”quando a senha está de fato correta

    
por 09.07.2010 / 21:28
1

Carregando rpcping.exe no Dependency Walker, fica claro que ele usa WinHttp.dll em vez de WinInet.dll . Portanto, copiar o WinHttp.dll do Windows XP SP3 para C:\Program Files\Microsoft Office\Office11 , onde Outlook.exe está localizado, faz com que o Outlook envie HTTP/1.0 solicitações com User-Agent e todos os outros campos de cabeçalho como no meu computador antigo.

Versão existente no Windows 7 SP1: 6.1.7601.17514

Versão copiada do Windows XP SP3: 5.1.2600.6175

Não é a solução mais limpa, mas terá que ser feita por enquanto. Se alguém tiver uma ideia melhor, eu vou ter todos os ouvidos ...

    
por 22.03.2012 / 16:57
0

3.1.4 não é a versão mais recente do Squid - o release upstream atual na ramificação 3.1 é 3.1.16, e há muitas alterações relacionadas à conformidade com o HTTP 1.1 no changelog. Pode ser necessário tentar uma versão mais recente.

Esta postagem de usuários de squid diz que pelo menos em Janeiro, mesmo usando um último 3.1.x não foi suficiente, e as correções de suporte HTTP 1.1 necessárias foram apenas em 3.2 betas.

    
por 30.11.2011 / 20:46