5

I'm running a Squid proxy (latest version, 3.1.4) on Linux CentOS 5.4 with Samba 3.5.4, in order to allow authenticated web access for domain users; everything works fine, and even Windows 7 clients are fully supported. Authentication is transparent for domain users, while it is explicitly requested for non-domain ones, and it works if the user can provide valid domain credentials. All nice and good.

Then, Outlook Anywhere kicks in and pain and suffering ensue.

When Outlook (be it 2007 or 2010, it doesn't matter) runs on Windows XP clients, it connects gracefully through the Squid proxy to its remote Exchange server.

When it runs on Windows 7, it doesn't.

If the authentication requirement is lifted from the proxy, everything works on Windows 7 too, so the problem is obviously related to NTLM authentication with Squid.

Digging more deeply (WireShark), I discovered Outlook Anywhere uses HTTP 1.1 when it runs on Windows 7, while it uses HTTP 1.0 when on Windows XP. And it looks like Squid, even in its latest incarnation, still has some serious troubles handling HTTP 1.1 properly, particularly when SSL and proxy authentication are thrown in the mix.

While waiting for Squid to fully and officially support HTTP 1.1 (and it looks like this could take quite a long time), I'm looking for one of the following solutions:

  • Make Squid handle this correctly, if it is at all possible.
  • Identify Outlook Anywhere connections and have Squid not require authentication for them. But it isn't easy: again, the behaviour of Outlook differs when running on Windows XP and Windows 7, and while on Windows XP Outlook sends a really nice user-agent string of "MSRPC", on Windows 7 it doesn't send any (why? WHY?!?).
  • Force Outlook Anywhere to use HTTP 1.0 even when running on Windows 7. And no, this is not as simple as deselecting "use HTTP 1.1" in Internet Explorer, looks like Outlook ignores that setting and chooses on its own which protocol to use.
  • Any other feasible solution which doesn't involve whitelisting specific destination Exchange servers, which is the last-resort solution I'm trying to avoid.
Massimo
  • 68,714
  • 56
  • 196
  • 319

3 Answers3

1

Windows 7, Server 2008, and I believe even Vista don't support NTLMv1 by default. If it's working on XP, but not Windows 7 I would start by enabling NTLMv1 and seeing if it resolves your issue. Here's the post that helped me when I had a similar issue. Windows7 - “The specified network password is not correct.” when the password is in fact correct

  • 1
    This has been already solved. The latest Samba versions support NTLMv2 without any issue, authentication works perfectly fine in Internet Explorer. This problem is only related to Outlook Anywhere and Squid's lack of HTTP 1.1 support. – Massimo Jul 11 '10 at 04:14
1

Loading rpcping.exe into Dependency Walker, it's clear that it uses WinHttp.dll instead of WinInet.dll. So, copying the WinHttp.dll from Windows XP SP3 into C:\Program Files\Microsoft Office\Office11 where Outlook.exe is located causes Outlook to send HTTP/1.0 requests with User-Agent and all the other header fields just like it did on my old computer.

Existing version on Windows 7 SP1: 6.1.7601.17514

Copied version from Windows XP SP3: 5.1.2600.6175

It's not the cleanest solution, but it will have to do for now. If anyone has a better idea, I'll all ears...

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Anlo
  • 281
  • 1
  • 7
0

3.1.4 is not the latest version of Squid — the current upstream release in the 3.1 branch is 3.1.16, and there are many changes related to HTTP 1.1 compliance in the changelog. You might need to try a newer version.

This post from squid-users tells that at least in January even using a latest 3.1.x was not enough, and the needed HTTP 1.1 support fixes were only in 3.2 betas.

Sergey Vlasov
  • 6,088
  • 1
  • 19
  • 30