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
