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.
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
Loading
rpcping.exe
into Dependency Walker, it's clear that it usesWinHttp.dll
instead ofWinInet.dll
. So, copying theWinHttp.dll
from Windows XP SP3 intoC:\Program Files\Microsoft Office\Office11
whereOutlook.exe
is located causes Outlook to sendHTTP/1.0
requests withUser-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...
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.