On Thu, 10 Feb 2005, Oliver Hookins wrote:
> 1108019834.574 45 192.168.0.153 TCP_REFRESH_HIT/200 2524 GET
> http://secure-uk.imrworldwide.com/v5.js epa\scottb NONE/- text/html
> 1108019834.684 109 192.168.0.153 TCP_MISS/503 1353 GET
> http://secure-uk.imrworldwide.com/cgi-bin/m? epa\scottb NONE/- text/html
> 1108019840.107 286 192.168.0.153 TCP_MISS/503 1323 GET
> http://www.md.huji.ac.il/vjt/ epa\scottb NONE/- text/html
> 1108019849.213 292 192.168.0.153 TCP_MISS/503 1315 GET
> http://www.md.huji.ac.il/ epa\scottb NONE/- text/html
> 1108019885.509 155 192.168.0.124 TCP_DENIED/407 1681 GET
> http://www.google.com.au/ - NONE/- text/html
> 1108019885.762 1 192.168.0.124 TCP_DENIED/407 1762 GET
> http://www.google.com.au/ - NONE/- text/html
>
> So here we have some requests from someone who is not a member of the LDAP
> group, but is in the SURFING IP range, accessing a site that is not in
> allowedsites - the request succeeds.
Can you give your rules again.
See also the Squid FAQ on how to debug access controls.
> After that we have someone who IS in the
> LDAP group, is in the SURFING IP range and is access a site that is also not
> in allowedsites. The connection is denied and the username is not logged.
Here the browser did not agree on logging in to the proxy and hence the
request is denied as you require authentication (even if faked
verification).
> Further to that, we removed that user from the authorised LDAP group, and it
> made no difference to the username showing up in the logs. We also tried
> using an IP address not in the SURFING acl, but that made no difference.
LDAP group membership won't make a difference to the problem of
authentiaciton not suceeding at all.
Regards
Henrik
Received on Thu Feb 10 2005 - 01:22:23 MST
This archive was generated by hypermail pre-2.1.9 : Tue Mar 01 2005 - 12:00:02 MST