Re: [squid-users] Authorisation fails sometimes
On 17/02/2012 1:31 a.m., Günter Merz wrote: I tested if an earlier ACL might prevent those transfers from being allowed by inserting an ACL right before the external_acl_type to allow all transfers from the host I was using. This didn't show any TCP_DENIEDs. Um, of course not. allow all will never deny anything. Absolutely anything is permitted. I understand that. What I wanted to see was if any rule _before_ my external_acl_type rule could be the reason for my sparse TCP_DENIEDs. I proved to myself that that isn't the case. Can anyone think of a reason for this behaviour or another way to debug for the cause? Beyond seeing TCP_DENIED when the credentials are missing, What makes you think there is a fault? That's the thing. The credentials shouldn't be missing. As far as I understand the browser should send the credentials with each request and I should see the credentials in each line of the access.log file. But that's not the case. Example: I'm loading 'http://wordpress.com' (I'm substituting the real user and domain names by 'user@DOMAIN'): There will be quite a few GETs like these (everything fine): 1329123214.597 35 192.168.0.15 TCP_MISS/200 29688 GET http://s2.wp.com/imgpress? user@DOMAIN DIRECT/93.184.220.20 image/jpeg Then one like these (there's a '-' where 'user@DOMAIN' should be): 1329123214.605339 192.168.0.15 TCP_DENIED/407 3899 GET http://i.kissmetrics.com/i.js - NONE/- text/html Ah, kissmetrics Evercookie. A few lines down the request passes like this (fine again, but I presume slow): 1329123215.156239 192.168.0.15 TCP_MISS/200 515 GET http://i.kissmetrics.com/i.js user@DOMAIN DIRECT/174.129.203.253 application/x-javascript If you consider 239 milliseconds slow. The auth re-handshake there took 1.7 seconds from start to finish though. Writing about it, I'm starting to think: Could this be part of a negotiation? Yes, this is the credentials being negotiated. You need to go right down to the packet level to determine whether this was a re-negotiation on a previously authenticated TCP connection (problem), or a new connection and the browser just omitted the credentials. They are not actually supposed to send credentials until asked, so the first request on a new connnection should display exactly like that as a good negotiation handshake. The pipelined requests after the end of the handshake are the ones which should consistently have credentials attached. This is why persistent connections is a minimum requirement for NTLM and Kerberos auth. squid is version 3.1.16 firefox: 10.0.1 chromium: 17.0.963.46 squid_kerb_ldap: 1.2.1a Amos
[squid-users] Authorisation fails sometimes
Hello, I'm using squid_kerb_ldap (via external_acl_type) to authenticate via kerberos and authorize access via ldap groups. This seems to work. Partly anyway. My problem is: Most of the traffic is authorized as shown in the access.log file which shows GETs and CONNECTs using the respective kerberos id (user@DOMAIN) but some GETs and CONNECTs lack that kerberos id (-) and consequently fail (TCP_DENIED). I tested if an earlier ACL might prevent those transfers from being allowed by inserting an ACL right before the external_acl_type to allow all transfers from the host I was using. This didn't show any TCP_DENIEDs. I also wondered if the browser could be at fault (not requesting each GET with the respective kerberos id) so I changed from Firefox to Chromium. The behaviour was identical. Can anyone think of a reason for this behaviour or another way to debug for the cause?
Re: [squid-users] Authorisation fails sometimes
On 16.02.2012 03:12, Günter Merz wrote: Hello, I'm using squid_kerb_ldap (via external_acl_type) to authenticate via kerberos and authorize access via ldap groups. This seems to work. Partly anyway. My problem is: Most of the traffic is authorized as shown in the access.log file which shows GETs and CONNECTs using the respective kerberos id (user@DOMAIN) but some GETs and CONNECTs lack that kerberos id (-) and consequently fail (TCP_DENIED). I tested if an earlier ACL might prevent those transfers from being allowed by inserting an ACL right before the external_acl_type to allow all transfers from the host I was using. This didn't show any TCP_DENIEDs. Um, of course not. allow all will never deny anything. Absolutely anything is permitted. I also wondered if the browser could be at fault (not requesting each GET with the respective kerberos id) so I changed from Firefox to Chromium. The behaviour was identical. Can anyone think of a reason for this behaviour or another way to debug for the cause? Beyond seeing TCP_DENIED when the credentials are missing, What makes you think there is a fault? 4xx status messages is simply the mechanism HTTP uses for the proxy to inform the client software about things it needs to do. In this case adding the credentials to its request. It can (and should) retry immediately with credentials and get accepted. At best all 4xx status are minor problems easily corrected in the background by the client. 5xx status are the major errors, only the server admin can fix those. You also omitted details about what software versions you are dealing with. It's hard to diagnose a bug fixed in say 2005 without knowing your software came out in 2002. Likewise to ignore bugs fixed already in your version. Amos
