Hi Amos,
I have compared the headers between the 2.6.STABLE5 and 3.1.10 and have
found the following:
* added Mime-Version: 1.0
* added Vary: Accept-Language
* added Content-Language: en
* changed Proxy-Connection: keep-alive to Connection: keep-alive
After having a quick look with Wireshark (not sure if its a decoding
problem or not) it appears that during the NTLM handshake something is
going wrong at the NTLMSSP_AUTH stage. When Wireshark decodes the
packets going to squid 2.6.STABLE5 the Domain name, User name and Host
name that it decodes are correct, but when looking at the decoded
packets from 3.1.10 those 3 fields only have one character in each of
them (the first character from the string that it should have).
I have a dump of the headers from both the old version and the new
version. Would it help to see those? If so, what is the best way to
share them, attach via email or upload to a website and send link?
Regards,
John Treen
Amos Jeffries wrote:
On 01/02/11 16:01, John Treen wrote:
Hi Everyone,
I am having trouble getting WSUS 3.0 to communicate through Squid when
using NTLM authentication. Back in early 2009 I did some testing and
determined that 2.6.STABLE5 appears to be the last version that WSUS
would successfully communicate through the proxy using NTLM.
Yesterday I tried Squid 3.1.10 and WSUS still returns a 407 Proxy
Authentication Required. If I uninstall 3.1.10 and then install
2.6.STABLE5 using the same configuration on my test machine WSUS works
I'm a little suspicious of this. Mainly because we altered many small
background options and behaviours to achieve almost complete HTTP/1.1
compliance in 3.1.
If I comment out the auth_param ntlm lines (just leaving basic
authentication enabled) WSUS works with 3.1.10, so I believe it could be
something going wrong in the NTLM handshake.
What is the best way to start debugging what the problem could be?
The easy way is to take a full packet capture (tcpdump -s 0 ...) when
using the working Squid and again with the non-working. Compare the
two transactions headers in wireshark and see if anything appears.
The hard way is to dredge the squid cache.log at debug_options 29,5 on
the 3.1 install and see what is happening.
Amos
