On Tue, 23 Feb 2010 15:38:34 -0800, Mike Ely <mikeely_at_amyskitchen.net>
wrote:
> On 2/19/10 6:11 PM, "Amos Jeffries" <squid3_at_treenet.co.nz> wrote:
>
>> Mike Ely wrote:
>>> On 2/17/10 4:10 PM, "Mike Ely" <mikeely_at_amyskitchen.net> wrote:
>>>
>>>> Hi there,
>>>>
>>>> We've got 2.6 stable running as logging only server, no caching going
>>>> on.
>>>> Users are authenticated via NTLM if they're on Windows, works fine in
>>>> FF and
>>>> IE with one exception. Uploading a file prompts a second auth
dialogue
>>>> (regardless of which browser) and entering credentials to that only
>>>> causes
>>>> the browser to hork. I've tested this on XP and 2k3, various browser
>>>> versions.
>>>>
>>>> What I find interesting about this is that if I set the Internet
>>>> Connection
>>>> Settings in the control panel to "auto-detect" I will get the failure
>>>> even
>>>> if I explicitly configure FireFox (via about:config) to not do NTLM
>>>> pass-through. My current working guess is that Flickr (and the
>>>> work-related
>>>> site that uses a somewhat similar ajaxy/flashy uploader) is making a
>>>> call to
>>>> Flash and Flash is barfing on the NTLM pass-through, but that's
really
>>>> only
>>>> a guess.
>>>>
>>>> Steps to reproduce:
>>>> Setup NTLM auth
>>>> Connect through the proxy
>>>> Attempt to upload a photo to Flickr
>>>>
>>>> Steps to work around:
>>>> Disable "automatically connect" on the client control panel and auth
by
>>>> hand, or use a non-windows client and also auth by hand.
>>>>
>>>>
>>>>
>>>> Squid.conf here:
>>
>> <snip>
>>
>>>>
>>>> # Destinations here
>>>> acl fedex dstdomain .fedex.com
>>>>
>>>> # User groups here
>>>> acl localnet proxy_auth REQUIRED src 10.0.0.0/8
>>
>> 1) "proxy_auth" ACL type accepts a list of usernames OR the word
>> "REQUIRED" to accept any valid username.
>>
>> 2) "proxy_auth REQUIRED src" has never been valid AFAICT. The "src ..."
>> bit has silently been discarded by all Squid 2.6+ I'm aware of.
>>
>> 3) If I'm wrong about (2) being discarded then the effect will be that
>> the username "src" or "10.0.0.0/8" with no password might possibly be
>> used to login on your Squid.
>>
>> 4) Without IP address range checks there is no restriction on where the
>> logins may be done from.
>>
>>
>>>> http_access allow CONNECT wuCONNECT localnet
>>
>> 'localnet Requires authentication and will challenge.
>>
>>>> http_access allow windowsupdate localnet
>>
>> 'localnet Requires authentication and will challenge.
>>
>> NOTE: 'localnet' being one of the default Squid-3 ACL all documentation
>> you will find anywhere will assume that it retains that default type
>> (which is to match source IP address only).
>>
>>
>> SOLUTION:
>> Create a new name for your login ACL and use that where login is
>> needed.
>> Revert localnet to IP range "src" type and use that where
appropriate
>> as well.
>>
>> <snip again>
>>
>> The notes I've added above in your config should help out a LOT.
>> Get those corrected and we can work on the additional fix after that.
>>
>> Amos
>
> Hi Amos,
>
> Thanks for the reply. Per your suggestions, I¹ve created a test server
> running 2.7.STABLE7 and rebuilt the config (which I¹ll append below).
> Unfortunately this doesn¹t change the original issue with file uploads
> client machine thinks it¹s getting regular proxy stuff due to edited
hosts
> file and I¹m verifying through logs that it¹s hitting the test server I
> want
> it to use. Then again, maybe I simply misunderstood you and
misconfigured
> it again...
That one looks much better. As far as I can tell right now it should be
passing NTLM auth bits thru to the web server when that server asks for
them.
The "acl amysnet proxy_auth REQUIRED src 10.0.0.0/8" is still broken, but
you are not using it so can remove.
Or to retain it you will need it to become something like this:
acl amysnetIP src 10.0.0.0/8
acl amysnetLogin proxy_auth REQUIRED
http_access deny amysnetIP !amysnetLogin
http_access allow amysnetIP amysnetLogin
Amos
Received on Wed Feb 24 2010 - 00:24:06 MST
This archive was generated by hypermail 2.2.0 : Wed Feb 24 2010 - 12:00:06 MST