Re: [squid-users] Can't see usernames in logs after enabling NTLM

Chris Robertson wrote:
>>>>http_access allow AuthGroup
>>>>http_access allow SURFING
>>>>http_access allow allowedsites
>>>>http_access deny all
>>>>
>>>>Will that do it, and grab authentication details for every request?
>>>>
>>>>
>>>>Thanks,
>>>>Oliver
>>>
>>>
>>>Here is how I read your setup:
>>>
>>>Everyone is prompted for authentication (which is passed to
>
> fakeauth_auth,
>
>>>and so passes) and the credentials are tested against LDAP (http_access
>>>allow AuthGroup). If the credentials map to an allowed group the person
>>>surfs wherever they wish, otherwise the client IP is checked against
>
> allowed
>
>>>sites. If the client IP is listed in SURFING they are allowed to surf
>>>wherever they wish, otherwise their destination domain is checked against
>>>allowedsites. If found, the request is allowed.
>>>
>>>So to be denied, it has to be someone not in an authorized LDAP group,
>>>surfing from a computer not in the SURFING IP range going to a site not
>>>listed in allowedsites. In any case, all transactions are logged to
>>>whatever name the surfer provided to the authentication request.
>>>
>>>That should about cover it...
>>>
>>>Chris
>>>
>>
>>Yes that is exactly right. Thanks very much, Chris!
>>
>>Oliver
>
>
> Now comes the big test. Put it in testing/production and see if it works...
>
> You are most welcome if it does, and I'll be happy to offer what help I can
> if it doesn't.
>
> Chris

Well, well, well. I tested it all out in house on my testbed, and it
appeared to work just as expected. I have just tested it out on the
actual production machine and it didn't work. Now as far as I can tell,
both installations of Squid should be identical (now...) - they are both
2.5STABLE7, have been compiled from source and should have all the same
authentication options.

I have the above order of http_access lines, and yet it still doesn't
work as expected. Here is a snippet of access.log:

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. 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.

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.

Could it be a problem with the client IE settings??!? That is the only
thing I haven't dealt with yet, nothing else seems to be making sense.
Thanks for all the great help so far Henrik and Chris but this one's got
me stumped.

Regards,
Oliver
Received on Thu Feb 10 2005 - 00:31:40 MST