Re: Authenticating Sibling Problem

This _has_ been discussed before (Hey, FAQ maintainer...This should be in the FAQ).
The relevant answer was:

In article <Pine.WNT.3.95.971113162752.-436679D-100000@supc281.rdg.ac.uk> you write:

>The problems start when I configure each to use the other as a neighbour
>and to treat the servers as a cluster. When an object could be supplied
>by the 'other' server the transaction nonetheless fails with the message
>'Proxy authorization failed. Retry?' displayed by the client browser. It
>would seem that the second server is requiring authorization as though the
>request were coming direct from the end user rather than a querying
>server. It makes no difference whether the two servers are siblings or
>whether one is defined as a parent of the other. There are no examples of
>the ignore-domain argument to the proxy_auth option in squid.conf but I
>assume that this is not intended to prevent the behaviour I am
>experiencing (which I assume is unintentional and unforeseen).

You should make sure that the proxy servers themselves can use each other
without authentication. Try something like this:

acl myneighbor src 1.2.3.4
acl customers src some-range
acl password proxy_auth "password file"

# neighbor cache gets access without password
http_access allow myneighbor
# all others should be from a customer IP address and present a valid
# password
http_access allow customers password
# deny the rest
http_access deny all

# similar for ICP
icp_access allow myneighbor
icp_acesss deny all

>Can anybody comment or offer any further insight into the problem, please?

Arjan

David Richards wrote:

> Hi,
>
> I have a pretty major problem, it invovles two authenticating
> squid proxies, version 1.1.16. Here is the situation:
>
> [ Parents ]
> / \
> / \
> [ Proxy A ] --- [ Proxy B ]
> |
> |
> USER
>
> The problem occurs when the USER makes a request to Proxy A. The
> object is not in Proxy A but is in Proxy B, the users gets back the
> message, "Proxy Authorization failed, Retry?". This is happening due to
> the following situation.
>
> Proxy A queries Proxy B about the object, Proxy B replies with a
> "YES, I have it". Proxy A performs a HTTP GET on behalf of the user, but
> does not pass on the authentication details, therefore the HTTP GET from
> Proxy A fails. This argument is supported by the following logs, created
> during the testing procedure:
>
> PROXY A:
>
> 131.181.124.200 richard2 - [04/Dec/1997:11:31:20 +1000] "GET
> http://www.catalog.att.com/bmd/images/burst.gif" TCP_MISS:SIBLING_HIT 799
>
> PROXY B:
>
> 131.181.127.42 - - [04/Dec/1997:11:31:20 +1000] "ICP_QUERY
> http://www.catalog.att.com/bmd/images/burst.gif" UDP_HIT:NONE 68
> 131.181.127.42 - - [04/Dec/1997:11:31:20 +1000] "GET
> http://www.catalog.att.com/bmd/images/burst.gif" ERR_PROXY_DENIED:NONE 799
>
> I suppose the real question is, is there any easy way to fix this,
> or has this problem been fixed in later versions??
>
> Thanks,
>
> Dave.
>
> -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-
> David Richards Ph: +61 7 3864 4347
> Network Programmer Fax: +61 7 3864 5272
> Computing Services E-mail: dj.richards@qut.edu.au
> Queensland University of Technology
> Brisbane, Australia
> -#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-

--
Note to evil sorcerers and mad scientists: don't ever, ever summon powerful
demons or rip holes in the fabric of space and time. It's never a good idea.
ICQ UIN: 3225440