Thanks Amos. Yeah they were cut and paste errors. Other than that I have tried using http11 with http_port and ignore_expect and it still doesn't work.
I think this is by design in Squid. Following code in "client_side.c" suggests that it will always filter the "WWW-Authenticate" header from HTTP Headers by treating it as unproxyable auth type.
/* Filter unproxyable authentication types */
if (http->log_type != LOG_TCP_DENIED &&
(httpHeaderHas(hdr, HDR_WWW_AUTHENTICATE))) {
HttpHeaderPos pos = HttpHeaderInitPos;
....
....
...code here removes the "WWW-Authenticate" from HTTP Header.
Also the following link "http://www.visolve.com/squid/Squid_tutorial.php#Authentication_"; suggests that Proxy Auth can't work in transparent mode.
Can you please comment on this?
Regards,
Saurabh
-----Original Message-----
From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
Sent: Tuesday, February 01, 2011 3:34 PM
To: squid-users@xxxxxxxxxxxxxxx
Subject: Re: Authentication to Sharepoint not happening
On 01/02/11 21:29, Saurabh Agarwal wrote:
> Hi Amos
>
> I am using squid.2.7.STABLE7. Following is my configuration. I want to allow everything.
>
> http_port 192.168.11.35:3128 transparent
> acl from_localhost src 192.168.11.35
> http_port 10.102.79.82:3128 transparent
> acl from_localhost src 10.102.79.82
> http_port 10.102.79.82:3128 transparent
> acl from_localhost src 10.102.79.82
cut-n-paste error? http_port and ACL is defined twice.
> visible_hostname hostname
> acl foreign_networksAux1 dst
> acl foreign_networksapA dst 0.0.0.0/0
above ACL collapses to "acl foreign_networksapA dst all"
> tcp_outgoing_address 192.168.11.35 foreign_networksAux1
> tcp_outgoing_address 10.102.79.82 foreign_networksapA
May as well drop "foreign_networksapA" off that tcp_outgoing. It has no
meaning.
> access_log none
> cache_log /dev/null
cache_log is not optional for very good reasons. If you are that worried
about stuff being logged set "debug_options ALL,0" to receive only the
critical failure events.
<snip>
> debug_options ALL,1
>
<snip>
> debug_options ALL,1
>
> acl manager proto cache_object
> acl all src 0.0.0.0/0.0.0.0
> acl all_dst dst 0.0.0.0/0.0.0.0
Easier to read and forward-portable:
acl all src all
acl all_dst dst all
Note that "dst all" means that all domains with DNS resolvable
destinations. "src all" means coming from a machine via IP protocol.
> http_access allow manager from_localhost
> http_access deny manager
> http_access allow all all_dst
Translation:
allow a request if it arrives from a machine with an IP address and
is destined to a machine which has an IP address.
Nice... Open proxy with no logging and transparent hijacking on a
standard port 3128 :).
Good thing your public IP is a little bit obscured.
This looks like a slightly confused configuration based on a loose
explanation of the tcp_outgoing_address "dst" hack.
The real hack is to place this above any "http_access allow" lines:
http_access deny all_dst !all
meaning: perform DNS lookup on the destination (thus caching the result
for tcp_outgoing_address to use) then skip to the next http_access line
due to an impossible test.
After doing that hack you *still* have to setup permissions as to who is
allowed to access the proxy.
<snip>
>
> hierarchy_stoplist cgi-bin ?
> acl store_rewrite_list urlpath_regex \/(get_video\?|videodownload\?|videoplayback.*id)
> acl store_rewrite_list1 dstdomain .youtube.com .video.google.com \/(get_video\?|videodownload\?|videoplayback.*id)
cut-n-paste error? " \/(get_video\?|vi..." is not a valid domain name.
<snip>
>
> client_persistent_connections on
> server_persistent_connections on
Good.
<snip>
>
> # Shorten timeouts
> negative_ttl 5 minutes
Bad. This means: DoS all clients of a URL whenever a 4xx or 5xx happens
on it.
This may be related to the 401 followup not working well.
Recommended value:
negative_ttl 0 seconds
> connect_timeout 1 minute
> peer_connect_timeout 30 seconds
> read_timeout 15 minutes
> request_timeout 5 minutes
> half_closed_clients off
> pconn_timeout 1 minute
NTLM and Negotiate require two pconn pinned together to operate. This
timeout will directly affect how often those paired TCP links are
discarded and require new auth handshakes.
So in summary, other than negative_ttl and a small pconn_timeout
possibly affecting things this config looks like it should pass the auth
headers just fine.
One other possibility you could try since this is 2.7 is the HTTP/1.1
options.
http_port ... http11
and these two:
http://www.squid-cache.org/Versions/v2/2.7/cfgman/server_http11.html
http://www.squid-cache.org/Versions/v2/2.7/cfgman/ignore_expect_100.html
The server_http11 is safest with no known problem side effects. The
http_port change may require ignore_expect_100 to fix broken clients.
Though such broken client apps are slowly disappearing now.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.10
Beta testers wanted for 3.2.0.4
