Re: [squid-users] Can't see usernames in logs after enabling NTLM
Chris Robertson wrote: -Original Message- From: Oliver Hookins [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 1:15 PM To: Henrik Nordstrom Cc: squid-users@squid-cache.org; 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. Sorry to drag this issue out so long but it still isn't working 100%. I've got some more access.log examples of what is happening now. I understand that when a client is requested authentication, there are a couple of TCP_DENIED entries in the logs and that it is normal. However we are getting a couple of TCP_DENIED messages without the user credentials, then further TCP_DENIED messages with the user credentials. I have double- and triple-checked and this user is definitely in the authorised group. If I do a manual check with the squid_ldap_group on the command line, I get an OK. 1108612447.271459 192.168.0.61 TCP_REFRESH_HIT/200 905 GET http://www.microsoft.com/h/en-us/r/for_developers.gif - DIRECT/207.46.144.188 image/gif 1108612447.379482 192.168.0.61 TCP_REFRESH_HIT/200 1036 GET http://www.microsoft.com/h/en-us/r/company_info.gif - DIRECT/207.46.144.188 image/gif 1108612447.622478 192.168.0.61 TCP_MISS/200 628 GET http://c.microsoft.com/trans_pixel.asp? - DIRECT/207.46.197.85 image/gif 1108612447.711490 192.168.0.61 TCP_MISS/200 438 GET http://c1.microsoft.com/c.gif? - DIRECT/207.68.177.126 image/gif 1108612510.253 0 192.168.0.61 TCP_DENIED/407 1684 GET http://www.ninemsn.com.au/ - NONE/- text/html 1108612510.260 0 192.168.0.61 TCP_DENIED/407 1770 GET http://www.ninemsn.com.au/ - NONE/- text/html 1108612510.356 95 192.168.0.61 TCP_DENIED/403 1379 GET http://www.ninemsn.com.au/ epa\aderooy NONE/- text/html 1108612527.261 4 192.168.0.61 TCP_IMS_HIT/304 221 GET http://www.acrlimited.com.au/ - NONE/- text/html 1108612527.306 23 192.168.0.61 TCP_IMS_HIT/304 225 GET http://www.acrlimited.com.au/images/header-top-pic.jpg - NONE/- image/jpeg 1108612527.332 25 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/header-top-r.gif - NONE/- image/gif 1108612527.351 18 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/header-bottom-slogan.gif - NONE/- image/gif 1108612527.418 67 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/header-bottom-r.gif - NONE/- image/gif 1108612527.458 17 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/home-on.gif - NONE/- image/gif 1108612527.477 0 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/rates-off.gif - NONE/- image/gif 1108612527.506 28 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/privacy-off.gif - NONE/- image/gif 1108612527.530 24 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/contact-off.gif - NONE/- image/gif 1108612527.548 17 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/blank.gif - NONE/- image/gif 1108612527.565 16 192.168.0.61 TCP_IMS_HIT/304 223 GET http://www.acrlimited.com.au/images/rates.jpg - NONE/- image/jpeg 1108612527.599 34 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/acr_bar-home.gif - NONE/- image/gif 1108612527.631 31 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/w.gif - NONE/- image/gif 1108612527.654 22 192.168.0.61 TCP_IMS_HIT/304 222 GET http://www.acrlimited.com.au/images/footer_home-top.gif - NONE/- image/gif 1108612527.683 28 192.168.0.61 TCP_IMS_HIT/304
Re: [squid-users] Can't see usernames in logs after enabling NTLM
Chris Robertson wrote: -Original Message- From: Oliver Hookins [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 1:15 PM To: Henrik Nordstrom Cc: squid-users@squid-cache.org; 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
Re: [squid-users] Can't see usernames in logs after enabling NTLM
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.684109 192.168.0.153 TCP_MISS/503 1353 GET http://secure-uk.imrworldwide.com/cgi-bin/m? epa\scottb NONE/- text/html 1108019840.107286 192.168.0.153 TCP_MISS/503 1323 GET http://www.md.huji.ac.il/vjt/ epa\scottb NONE/- text/html 1108019849.213292 192.168.0.153 TCP_MISS/503 1315 GET http://www.md.huji.ac.il/ epa\scottb NONE/- text/html 1108019885.509155 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
RE: [squid-users] Can't see usernames in logs after enabling NTLM
-Original Message- From: Oliver Hookins [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 10:32 PM To: squid-users@squid-cache.org 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.684109 192.168.0.153 TCP_MISS/503 1353 GET http://secure-uk.imrworldwide.com/cgi-bin/m? epa\scottb NONE/- text/html 1108019840.107286 192.168.0.153 TCP_MISS/503 1323 GET http://www.md.huji.ac.il/vjt/ epa\scottb NONE/- text/html 1108019849.213292 192.168.0.153 TCP_MISS/503 1315 GET http://www.md.huji.ac.il/ epa\scottb NONE/- text/html 1108019885.509155 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
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
Re: [squid-users] Can't see usernames in logs after enabling NTLM
On Fri, 11 Feb 2005, Oliver Hookins wrote: 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? Yes, as Squid needs the username to evaluate the acl. 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? 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). Like most people do. Regards Henrik
RE: [squid-users] Can't see usernames in logs after enabling NTLM
-Original Message- From: Oliver Hookins [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 1:15 PM To: Henrik Nordstrom Cc: squid-users@squid-cache.org; 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. Chris
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.684109 192.168.0.153 TCP_MISS/503 1353 GET http://secure-uk.imrworldwide.com/cgi-bin/m? epa\scottb NONE/- text/html 1108019840.107286 192.168.0.153 TCP_MISS/503 1323 GET http://www.md.huji.ac.il/vjt/ epa\scottb NONE/- text/html 1108019849.213292 192.168.0.153 TCP_MISS/503 1315 GET http://www.md.huji.ac.il/ epa\scottb NONE/- text/html 1108019885.509155 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
Re: [squid-users] Can't see usernames in logs after enabling NTLM
On Tue, 8 Feb 2005, Oliver Hookins wrote: I've never quite understood it... hence my problem. Let me run this by you though. It's an ordered list of rules http_access allow|deny acl AND acl AND ... OR http_access allow|deny acl AND acl AND ... OR ... wher AND/OR is in the logic absolute sense, not the english fuzzy one. If the request is for one of the allowedsites or from the list of IP addresses in SURFING, the AuthGroup will never even be touched so NTLM authentication is not activated? So I should put http_access allow AuthGroup at the very top so that NTLM authentication is forced on all requests. Then you will allow AuthGroup to access anything. Then if the request is neither from a user in the authorised LDAP group, or from an IP address in SURFING, or to an allowedsite (or from localhost) it will be denied? If you do http_access allow A http_access allow B http_access allow C then the request will be allowed if it matches either A, B or C. If you do http_access allow A B C then the request will be allowed if it matches all of A B and C. http_access processing is always done top-down left to right. When does Squid decided if it needs to activate the proxy_auth password required thing? As soon as it encounters a acl requiring authentication when processing the http_access rules. During parsing of the configuration file or when a request is made? When the request is made. Regards Henrik
Re: [squid-users] Can't see usernames in logs after enabling NTLM
On Tue, 8 Feb 2005, Oliver Hookins 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? Yes, but I would not recommend leaving allowedsites world open like this. acl mynetwork src .. http_access deny !mynetwork http_access allow AuthGroup http_access allow SURFING http_access allow allowedsites http_access deny all or alternatively (effectively the same thing) http_access allow mynetwork AuthGroup http_access allow SURFING http_access allow mynetwork allowedsites http_access deny all Regards Henrik
Re: [squid-users] Can't see usernames in logs after enabling NTLM
Henrik Nordstrom wrote: On Mon, 7 Feb 2005, Oliver Hookins wrote: On my 2.5STABLE3 box I didn't explicitly have a http_access rule referring to the proxy_auth. I had one referring to the squid_ldap_group helper ACL though, and that seemed to work. Correct. Anyway here's the list of acl's and http_access lines so maybe you can see what I'm doing wrong on the 2.5STABLE7: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow allowedsites http_access allow localhost http_access allow SURFING # http_access allow AuthGroup # See Squid FAQ 10.1 Access Controls - Introduction for an in-depth description of how http_access works. http://www.squid-cache.org/Doc/FAQ/FAQ-10.html I've never quite understood it... hence my problem. Let me run this by you though. If the request is for one of the allowedsites or from the list of IP addresses in SURFING, the AuthGroup will never even be touched so NTLM authentication is not activated? So I should put http_access allow AuthGroup at the very top so that NTLM authentication is forced on all requests. Then if the request is neither from a user in the authorised LDAP group, or from an IP address in SURFING, or to an allowedsite (or from localhost) it will be denied? When does Squid decided if it needs to activate the proxy_auth password required thing? During parsing of the configuration file or when a request is made? Regards, Oliver
RE: [squid-users] Can't see usernames in logs after enabling NTLM
-Original Message- From: Oliver Hookins [mailto:[EMAIL PROTECTED] Sent: Monday, February 07, 2005 2:42 PM To: Henrik Nordstrom Cc: squid-users@squid-cache.org Subject: Re: [squid-users] Can't see usernames in logs after enabling NTLM Henrik Nordstrom wrote: On Mon, 7 Feb 2005, Oliver Hookins wrote: On my 2.5STABLE3 box I didn't explicitly have a http_access rule referring to the proxy_auth. I had one referring to the squid_ldap_group helper ACL though, and that seemed to work. Correct. Anyway here's the list of acl's and http_access lines so maybe you can see what I'm doing wrong on the 2.5STABLE7: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow allowedsites http_access allow localhost http_access allow SURFING # http_access allow AuthGroup # See Squid FAQ 10.1 Access Controls - Introduction for an in-depth description of how http_access works. http://www.squid-cache.org/Doc/FAQ/FAQ-10.html I've never quite understood it... hence my problem. Let me run this by you though. If the request is for one of the allowedsites or from the list of IP addresses in SURFING, the AuthGroup will never even be touched so NTLM authentication is not activated? This is correct. So I should put http_access allow AuthGroup at the very top so that NTLM authentication is forced on all requests. Then if the request is neither from a user in the authorised LDAP group, or from an IP address in SURFING, or to an allowedsite (or from localhost) it will be denied? If you want all requests to be authenticated first, use http_access deny !AuthGroup at the top. That way any requests from sources that are not authenticated will be denied and asked for authentication. Requests that are authenticated will pass on down to the next ACL (not being explicitly denied, but not explicitly allowed either). When does Squid decided if it needs to activate the proxy_auth password required thing? During parsing of the configuration file or when a request is made? Squid will ask for authentication (or not, based on ACLs) when a request is made. It will (perhaps obviously) decide whether it needs to start authentication helpers when parsing the config file. Regards, Oliver Chris
Re: [squid-users] Can't see usernames in logs after enabling NTLM
Chris Robertson wrote: -Original Message- From: Oliver Hookins [mailto:[EMAIL PROTECTED] Sent: Monday, February 07, 2005 2:42 PM To: Henrik Nordstrom Cc: squid-users@squid-cache.org Subject: Re: [squid-users] Can't see usernames in logs after enabling NTLM Henrik Nordstrom wrote: On Mon, 7 Feb 2005, Oliver Hookins wrote: On my 2.5STABLE3 box I didn't explicitly have a http_access rule referring to the proxy_auth. I had one referring to the squid_ldap_group helper ACL though, and that seemed to work. Correct. Anyway here's the list of acl's and http_access lines so maybe you can see what I'm doing wrong on the 2.5STABLE7: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow allowedsites http_access allow localhost http_access allow SURFING # http_access allow AuthGroup # See Squid FAQ 10.1 Access Controls - Introduction for an in-depth description of how http_access works. http://www.squid-cache.org/Doc/FAQ/FAQ-10.html I've never quite understood it... hence my problem. Let me run this by you though. If the request is for one of the allowedsites or from the list of IP addresses in SURFING, the AuthGroup will never even be touched so NTLM authentication is not activated? This is correct. So I should put http_access allow AuthGroup at the very top so that NTLM authentication is forced on all requests. Then if the request is neither from a user in the authorised LDAP group, or from an IP address in SURFING, or to an allowedsite (or from localhost) it will be denied? If you want all requests to be authenticated first, use http_access deny !AuthGroup at the top. That way any requests from sources that are not authenticated will be denied and asked for authentication. Requests that are authenticated will pass on down to the next ACL (not being explicitly denied, but not explicitly allowed either). The authentication method is just passing through fakeauth to grab usernames anyway so it's not quite authentication as such. But basically we want all requests to pass through fakeauth in order to grab usernames. Then we want to: * allow access to anyone who is authorised by LDAP group * requests that aren't LDAP group authorised but ARE on the SURFING IP ACL list should be allowed * requests that aren't LDAP authorised and aren't from an IP on the SURFING ACL but are to an allowedsite should be allowed * deny everything else 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? When does Squid decided if it needs to activate the proxy_auth password required thing? During parsing of the configuration file or when a request is made? Squid will ask for authentication (or not, based on ACLs) when a request is made. It will (perhaps obviously) decide whether it needs to start authentication helpers when parsing the config file. Thanks, Oliver
RE: [squid-users] Can't see usernames in logs after enabling NTLM
-Original Message- From: Oliver Hookins [mailto:[EMAIL PROTECTED] Sent: Monday, February 07, 2005 3:34 PM To: Chris Robertson Cc: squid-users@squid-cache.org Subject: Re: [squid-users] Can't see usernames in logs after enabling NTLM Chris Robertson wrote: If you want all requests to be authenticated first, use http_access deny !AuthGroup at the top. That way any requests from sources that are not authenticated will be denied and asked for authentication. Requests that are authenticated will pass on down to the next ACL (not being explicitly denied, but not explicitly allowed either). The authentication method is just passing through fakeauth to grab usernames anyway so it's not quite authentication as such. But basically we want all requests to pass through fakeauth in order to grab usernames. Then we want to: * allow access to anyone who is authorised by LDAP group * requests that aren't LDAP group authorised but ARE on the SURFING IP ACL list should be allowed * requests that aren't LDAP authorised and aren't from an IP on the SURFING ACL but are to an allowedsite should be allowed * deny everything else 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
Re: [squid-users] Can't see usernames in logs after enabling NTLM
Chris Robertson wrote: -Original Message- From: Oliver Hookins [mailto:[EMAIL PROTECTED] Sent: Monday, February 07, 2005 3:34 PM To: Chris Robertson Cc: squid-users@squid-cache.org Subject: Re: [squid-users] Can't see usernames in logs after enabling NTLM Chris Robertson wrote: If you want all requests to be authenticated first, use http_access deny !AuthGroup at the top. That way any requests from sources that are not authenticated will be denied and asked for authentication. Requests that are authenticated will pass on down to the next ACL (not being explicitly denied, but not explicitly allowed either). The authentication method is just passing through fakeauth to grab usernames anyway so it's not quite authentication as such. But basically we want all requests to pass through fakeauth in order to grab usernames. Then we want to: * allow access to anyone who is authorised by LDAP group * requests that aren't LDAP group authorised but ARE on the SURFING IP ACL list should be allowed * requests that aren't LDAP authorised and aren't from an IP on the SURFING ACL but are to an allowedsite should be allowed * deny everything else 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
Re: [squid-users] Can't see usernames in logs after enabling NTLM
Henrik Nordstrom wrote: On Fri, 4 Feb 2005, Oliver Hookins wrote: and then later on: acl password proxy_auth REQUIRED Have you also defined the required http_access rule using the password acl? On my 2.5STABLE3 box I didn't explicitly have a http_access rule referring to the proxy_auth. I had one referring to the squid_ldap_group helper ACL though, and that seemed to work. Anyway here's the list of acl's and http_access lines so maybe you can see what I'm doing wrong on the 2.5STABLE7: acl password proxy_auth REQUIRED #Recommended minimum configuration: acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 563 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl our_network src 192.168.0.0/255.255.252.0 ## acl SURFING src 192.168.0.2 acl SURFING src 192.168.0.3 acl SURFING src 192.168.0.5 acl SURFING src 192.168.0.6 acl SURFING src 192.168.0.7 acl SURFING src 192.168.0.42 acl SURFING src 192.168.0.4 acl SURFING src 192.168.0.65 acl SURFING src 192.168.0.66 acl SURFING src 192.168.0.67 acl SURFING src 192.168.0.70 acl SURFING src 192.168.0.73 acl SURFING src 192.168.0.79 acl SURFING src 192.168.0.85 acl SURFING src 192.168.0.87 acl SURFING src 192.168.0.89 acl SURFING src 192.168.0.100 acl SURFING src 192.168.0.101 acl SURFING src 192.168.0.105 acl SURFING src 192.168.0.106 acl SURFING src 192.168.0.111 acl SURFING src 192.168.0.115 acl SURFING src 192.168.0.116 acl SURFING src 192.168.0.119 acl SURFING src 192.168.0.122 acl SURFING src 192.168.0.126 acl SURFING src 192.168.0.128 acl SURFING src 192.168.0.129 acl SURFING src 192.168.0.141 acl SURFING src 192.168.0.145 acl SURFING src 192.168.0.148 acl SURFING src 192.168.0.149 acl SURFING src 192.168.0.108 acl SURFING src 192.168.0.107 acl SURFING src 192.168.0.112 acl SURFING src 192.168.0.103 acl SURFING src 192.168.0.182 acl SURFING src 192.168.0.113 acl SURFING src 192.168.0.117 acl SURFING src 192.168.0.157 acl SURFING src 192.168.0.161 acl SURFING src 192.168.0.162 acl SURFING src 192.168.0.183 acl SURFING src 192.168.0.200 acl SURFING src 192.168.0.214 acl SURFING src 192.168.0.124 acl SURFING src 192.168.0.249 acl SURFING src 192.168.0.248 acl SURFING src 192.168.0.153 ## # General Sites acl allowedsites dstdomain .whitepages.com.au acl allowedsites dstdomain .whereis.com.au acl allowedsites dstdomain .gov.au acl allowedsites dstdomain .edu.au # IT Sites acl allowedsites dstdomain .symantec.com acl allowedsites dstdomain .symantec.com.au acl allowedsites dstdomain .canon.com acl allowedsites dstdomain .canon.com.au acl allowedsites dstdomain .microsoft.com acl allowedsites dstdomain .windowsupdate.com acl allowedsites dstdomain .akamai.net acl allowedsites dstdomain .symantecliveupdate.com acl allowedsites dstdomain .adobe.com acl allowedsites dstdomain .practicallynetworked.com acl allowedsites dstdomain .ntfaq.com acl allowedsites dstdomain .fixmypcasap.com acl allowedsites dstdomain .drivers.com acl allowedsites dstdomain .netgear.com acl allowedsites dstdomain .driverguide.com acl allowedsites dstdomain .papwalker.com acl allowedsites dstdomain .pap.homeftp.net acl allowedsites dstdomain .bmsltd.co.uk acl allowedsites dstdomain .sysinternals.com acl allowedsites dstdomain .mvps.org acl allowedsites dstdomain .sun.com acl allowedsites dstdomain .hillstouch.com # Account Sites acl allowedsites dstdomain .myob.com.au acl allowedsites dstdomain .ioof.com.au acl allowedsites dstdomain .superchoice.com.au acl allowedsites dstdomain .super.com acl AuthGroup external ldap_group gOpenProxy #Recommended minimum configuration: # # Only allow cachemgr access from localhost http_access allow manager localhost http_access deny manager # Deny requests to unknown ports http_access deny !Safe_ports # Deny CONNECT to other than SSL ports http_access deny CONNECT !SSL_ports # # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on localhost is a local user #http_access deny to_localhost # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow allowedsites http_access allow localhost http_access allow SURFING # http_access allow AuthGroup # http_access deny all -- Thanks heaps, Oliver
Re: [squid-users] Can't see usernames in logs after enabling NTLM
On Mon, 7 Feb 2005, Oliver Hookins wrote: On my 2.5STABLE3 box I didn't explicitly have a http_access rule referring to the proxy_auth. I had one referring to the squid_ldap_group helper ACL though, and that seemed to work. Correct. Anyway here's the list of acl's and http_access lines so maybe you can see what I'm doing wrong on the 2.5STABLE7: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow allowedsites http_access allow localhost http_access allow SURFING # http_access allow AuthGroup # See Squid FAQ 10.1 Access Controls - Introduction for an in-depth description of how http_access works. http://www.squid-cache.org/Doc/FAQ/FAQ-10.html Regards Henrik
Re: [squid-users] Can't see usernames in logs after enabling NTLM
On Fri, 4 Feb 2005, Oliver Hookins wrote: and then later on: acl password proxy_auth REQUIRED Have you also defined the required http_access rule using the password acl? Regards Henrik
[squid-users] Can't see usernames in logs after enabling NTLM
OK I figured out the previous problem, the Squid-2.5STABLE7-Cerberian RPM that I had installed didn't have --enable-auth=ntlm in there, only basic. So I recompiled from 2.5STABLE7 source with basic and ntlm and my modified configuration parsed ok. But now that I have enabled the NTLM and have required authentication, I am still not getting any usernames in the logs. Thus I must assume that the NTLM is not working, and so squid_ldap_group is not receiving any usernames either and thus failing the authorisation for any user. The essential bits that I have enabled which should get this working are as follows: auth_param ntlm program /usr/lib/squid/fakeauth_auth auth_param ntlm children 5 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes and then later on: acl password proxy_auth REQUIRED I also have an external_acl_type line for squid_ldap_group which I have already tested successfully, an acl line to specify the LDAP group and an http_access line to wrap it all up. I don't understand why it isn't working as I had the exact same configuration working here on another test box... Any help would be appreciated! Oliver P.S. I seem to get a lot of rejection messages to do with my Gmail account and mail filters... does anyone else have the same problem?
