Re: [squid-users] Can't figure out this one - need a pointer

On Fri, Aug 27, 2010 at 20:04, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> Kurt Buff wrote:
>>
>> All,
>>
>> Several of our users are trying to access a web site, and squid seems
>> to have a problem with it.
>>
>> Here's a munged log line (the client computer name and my $WORK name
>> have been changed, but nothing else):
>>
>> 192.168.12.59 sales1.example.com 66.173.42.248 [25/Aug/2010:09:22:28
>> -0700] "GET http://portal.geo-comm.com/sites/example HTTP/1.1" 401
>> 1979 "-" "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; .NET4.0C; .NET4.0E)" TCP_MISS
>>
>>
>> When we browse with either IE or FF, and use the squid proxy, we get a
>> 401.2. If I then open up an exception on the firewall and they browse
>> direct, they get a popup asking for credentials (ID/Password), and the
>> site works.
>>
>> I'm not sure how I'd go about troubleshooting this, or fixing it.
>>
>> Anyone have some thoughts on what might be happening?
>>
>
> Website is broken. It is attempting to operate NTLM authentication (internal
> LAN management auth protocol) across the general internet.
>
> HTTP/1.1 401 Unauthorized
> Content-Type: text/html
> Server: Microsoft-IIS/6.0
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
> MicrosoftSharePointTeamServices: 12.0.0.6219
> X-Powered-By: ASP.NET
> Date: Sat, 28 Aug 2010 02:49:29 GMT
> Cache-Control: proxy-revalidate
> Content-Length: 1656
> Connection: close
>
>
> You seem to be lucky in that there are apparently no other proxies on the
> transit path between you and the website. So using persistent connections
> should hide the problem.
>
> If that does not help the very latest 3.1 has some updates that should work
> even better. Though I do mean *latest*: the 3.1.7 snapshot code, or future
> 3.1.8.

Dang - completely missed the NTLM. That's just sick and wrong. I'm
going to have to do some hard thinking about what I want to do about
this.

If I proceed with persistent connections, I'm guessing that I need to
use pconn_timeout to control them? If so, what might be a reasonable
threshold to set? Will I also have to use persistent_request_timeout,
and with a similar period specified?

Thanks for your help,

Kurt
Received on Sat Aug 28 2010 - 04:18:17 MDT