> -----Original Message----- > From: Oliver Hookins [mailto:ohookins@xxxxxxxxx] > Sent: Wednesday, February 09, 2005 10:32 PM > To: squid-users@xxxxxxxxxxxxxxx > Cc: Chris Robertson > Subject: 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 authorized 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 >From the log snippet you gave, it looks to me like it's working just as you asked. With NTLM you get two 407's in the log during the authentication process. What came after? The TCP_MISS/503 should just be web server errors (nothing to do with Squid). An authenticated user, not in the LDAP group was able to surf anywhere they wished from a computer in the SURFING IP range. This sampling of the access.log is too limited. Chris
