On 2/05/2012 4:09 a.m., Jason Fitzpatrick wrote:
> Hi All
>
> I have a Squid Server (squid-3.2.0.16-1.fc16.x86_64) which is set to
> upstream to a 3rd party gateway proxy server and therefore has to
> authenticate all users destined for the internet (internal traffic is
> not required to authenticate)
Why "therefore"? there is no direct relationship. The above makes no
more sense than "Birds fly, therefore birds have feet". Both might be
true, but there are flying fish and non-flying footed animals.
>
> While this works perfectly from IE and Firefox (NTLM authentication
> falling back to basic) chrome clients are unable to authenticate
> against the squid at all.
>
> (chrome is the latest version at time of writing 18.0.1025.168 m)
Therefore it is a chrome problem, not a Squid or Firefox or IE problem.
First thing to look at is whether the chrome traffic is actually passing
through Squid and/or the upstream. And what type of traffic it is.
> I see the following in the debug logging:
<snipped irrelevant lines>
>
> 2012/05/01 16:50:45.674 kid1| ACLChecklist::preCheck: 0x7fdaa23a98c8
> checking 'http_access allow AuthorizedUsers'
> 2012/05/01 16:50:45.674 kid1| Acl.cc(61) AuthenticateAcl: returning 0
> sending authentication challenge.
> 2012/05/01 16:50:45.674 kid1| ACLChecklist::checkForAsync: requiring
> Proxy Auth header.
> 2012/05/01 16:50:45.674 kid1| ACLChecklist::markFinished:
> 0x7fdaa23a98c8 checklist processing finished
>
> And not much else, does anyone have any suggestions?
The above log shows an auth challenge response being generated. Login
credentials are missing or not validating. 3.2.0.16 does not state which.
Amos
Received on Tue May 01 2012 - 21:31:47 MDT
This archive was generated by hypermail 2.2.0 : Wed May 02 2012 - 12:00:03 MDT