-----Original Message----- From: Oliver Hookins [mailto:ohookins@xxxxxxxxx] Sent: Thursday, February 10, 2005 1:15 PM To: Henrik Nordstrom Cc: squid-users@xxxxxxxxxxxxxxx; Chris Robertson Subject: Re: [squid-users] Can't see usernames in logs after enabling NTLM
Henrik Nordstrom wrote:
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).
This could be a problem. So any program that chooses not to authenticate, or for some reason cannot authenticate (for example, it's not built-in) will be denied access?
If we reversed the rules like this:
http_access allow SURFING http_access allow allowedsites mynetwork http_access allow AuthGroup mynetwork http_access deny all
that would force authentication for non-SURFING && non-allowedsites requests, right? I'm just thinking of server programs that download stuff but don't authenticate (in which case we would put them in the SURFING acl).
Regards, Oliver
That would allow unauthenticated surfing for computers in the SURFING IP range and for any computers on "mynetwork" accessing "allowedsites". Once someone not in the SURFING IP range (but in "mynetwork") tries to access a site that is not on the allowedsites list, authentication will be requested, and the AuthGroup will be checked. Dependant on the outcome of *that* test, either the request will be allowed or denied.
In short, I think you've nailed it.
I think we've figured out why the NTLM details weren't being passed. The workstations have Norton Client Firewall loaded and protecting any ports used for HTTP. I believe removing the protection on these ports allowed the NTLM details through... so that's something to bear in mind.
Thanks again, Oliver
