On Fri, Aug 27, 2010 at 20:04, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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
