RE: [squid-users] RDP, Certificates and Squid

 On Wed, 23 Feb 2011 13:55:54 -0500, Chad Naugle wrote:
> I am not certain with my response, but I have some ideas.
>
> - Your ACL ordering, that is often the case, is most likely to blame.
> Squid applies ACL's in order, top-down, and checks each ACL in their
> order when "http_access" is being applied.
> - I believe the ACL blocking access may be the 'PURGE' ACL, since the
> server could be sending them "no-cache" headers. -- I may need
> clarification on this behavior from another person, but you can
> attempt
> to comment it out to see if this is true, or add something such as
> "http_access allow PURGE GoDaddy".

 Not PURGE, that is just a method type ACL. Albeit a performance sapping
 one.

> - Any of your explicit "src / dstdomain" allows will not log
> usernames
> returned by the "InternetUsers" ACL.
> - Does the "Internet_Denied" and/or "FacebookUsers" nt_groups involve
> a
> login prompt, or blind authentication?
> - All Explicit allows / deny's should be placed _before_
> authentication
> routines.

 :) its pretty much always ordering.

 In this case the block is 407, so look for things which require
 authentication to be tested.

 ...
>
>>>> Damian Teasdale 2/23/2011 1:27 PM >>>
> This is the whole list from what I can tell.
>
 <snip>

> acl InternetDenied external nt_group Internet_Denied
> acl FacebookUsers external nt_group FacebookUsers

 These are missing their external_acl_type definition, but something
 called "nt_group" is a safe bet that its doing a login.

 <snip>
> acl InternetUsers proxy_auth REQUIRED

 And this glaring auth ACL.

 <snip>
>
> http_access deny InternetDenied

 ... AND the first thing Squid does is check one of those nt_group ACLs.

  ** This is very, very likely the problem.

> no_cache deny Itrade

 NP: time to remove the "no_" bit off the front of that directive.

> http_access allow PURGE localhost
> http_access deny PURGE
> http_access allow GC
> http_access allow Facebook FacebookUsers

 ... somewhat later facebook users are checked, but only if they are
 visiting facebook.
 This auth ACL will not be the problem.

> http_access deny Facebook
> http_access allow Blackberry
> http_access allow Citrix
> http_access allow WindowsUpdate
> http_access allow BusinessObjects
> http_access allow MapInfo
> http_access allow MindLeaders
> http_access allow DiscoverLink
> http_access allow Knotia
> http_access allow Chep
> http_access allow Auditors
> http_access allow pdr
> http_access allow GoDaddy
> http_access allow InternetUsers

 ... then finally anyone who can login is permitted.

>
> # And finally deny all other access to this proxy
> http_access deny all
>
> Thanks
>
> Damian Teasdale
>

 <snip>
>
> The Oppenheimer Group ---- CONFIDENTIAL

 NP: Posted to a public mailing list archived in perppetuity.

 Amos
Received on Wed Feb 23 2011 - 22:07:14 MST