On 21/02/2013 9:47 p.m., Tom Tom wrote:
Hi With squid 3.2.7, I have the following curiosity: SCENARIO 1 <<squid.conf>> acl AUTHENTICATED proxy_auth REQUIRED external_acl_type SQUID_KERB_LDAP ttl=7200 children-max=20 children-startup=5 children-idle=1 negative_ttl=7200 %LOGIN /usr/local/squid/libexec/ext_kerberos_ldap_group_acl -g "XXX" acl INTERNET_ACCESS external SQUID_KERB_LDAP ... ... http_access deny !INTERNET_ACCESS http_access deny !AUTHENTICATED http_access allow INTERNET_ACCESS AUTHENTICATED http_access deny all With the config above, I have the following lines in the access.log: [Thu Feb 21 06:56:45 2013].167 38 XXX TCP_REFRESH_UNMODIFIED/304 332 GET http://imagesrv.adition.com/banners/750/683036/dummy.gif USER FIRSTUP_PARENT/XXX image/gif [Thu Feb 21 06:57:04 2013].621 38 XXX TCP_REFRESH_UNMODIFIED/304 261 GET http://imagesrv.adition.com/banners/750/683036/dummy.gif USER FIRSTUP_PARENT/XXX image/gif
Note that both INTERNET_ACCESS and AUTHENTICATED access controls require authentication credentials in order to match. Both will generate authentication challenges if there are no credentials.
Without a cache.log trace showing all the auth oeprations (level 9 debug woudl be best) I can't say why the first request
---------------------------------------------------- SCENARIO 2 <<squid.conf (without proxy_auth REQUIRED)>> external_acl_type SQUID_KERB_LDAP ttl=7200 children-max=20 children-startup=5 children-idle=1 negative_ttl=7200 %LOGIN /usr/local/squid/libexec/ext_kerberos_ldap_group_acl -g "XXX" acl INTERNET_ACCESS external SQUID_KERB_LDAP ... ... http_access deny !INTERNET_ACCESS http_access allow INTERNET_ACCESS http_access deny all Now, the same request looks like this: [Thu Feb 21 06:55:59 2013].086 0 XXX TCP_DENIED/407 4153 GET http://imagesrv.adition.com/banners/750/683036/dummy.gif - HIER_NONE/- text/html [Thu Feb 21 06:55:59 2013].135 44 XXX TCP_REFRESH_UNMODIFIED/304 332 GET http://imagesrv.adition.com/banners/750/683036/dummy.gif USER FIRSTUP_PARENT/XXX image/gif A tcpdump shows, that the "authorization"-header is not sent in the first request. In scenario 2, the authorization-header is sent after the TCP_DENIED/407 response from squid (normal behavior). In scenario 1, squid response directly with 304. What is the influence of "AUTHENTICATED" in the first example, not to re-authenticate the request? Why does squid needs to re-authenticate (TCP_DENIED/407) without the "AUTHENTICATED" tag in the "http_access" line (Scenario 2)? Is it possible, that with the "AUTHENTICATED" tag squid uses the authentication-cache? And without the "AUTHENTICATED" tag, squid will not use the authentication-cache or flushes the cache-entry for every request?
No. Kerberos does not make use of the username cache for validation. It only adds recently tested credentials to the cache for reporting purposes.
Kerberos credentials are tied to the TCP connection state details and may be accepted if the new requests proxy-auth token matches the one tied to the connection already. The first request on a connectio should almost always be a DENIED/407, unless the Kerberos client is deciding to send its keytab token on the first request fof a connection - in which case Squid may be validating and accepting it immediately.
Squid of any version _in general_ should be consistently behaving as per scenario #2, except in the situations where scenario #1 is possible. But that exception is client dependent and should not be related to the squid.conf change you describe. Due to that exception case(s) it is hard to answer your question about "why" without seeing a debug ALL,9 cache.log trace of these tests. Can you supply that please?
I have other squids running (3.1.20), which are configured like scenario 2, but behaves like scenario 1. Why does squid 3.1.20 act different as 3.2.7?
Squid-3.1 has many authentication credentials management bugs that got fixed under the bug 2305 project. Including things like credentials from user-A being reported and shared by user-B - which sounds like scenario #1.
With "debug_options 29,9" (see below) in squid 3.2.7, I see that in the "wrong case" (without the AUTHENTICATED tag on the http_access line), squid is "freeing request 0x1646830".
HttpRequest or Auth::UserRequest request?
When I request the same file again, then squid response first with a "TCP_DENIED/407". Does the "freeing" means, that squid "flushes" his authentication-cache and therefore need to re-authenticate this request everytime? 2013/02/21 08:43:58.583 kid1| UserRequest.cc(506) addReplyAuthHeader: headertype:76 authuser:0x1646830*3 2013/02/21 08:43:58.583 kid1| UserRequest.cc(126) releaseAuthServer: No Negotiate auth server to release. 2013/02/21 08:43:58.583 kid1| UserRequest.cc(125) ~UserRequest: freeing request 0x1646830 I can also see, that in the wrong case (re-authenticate), squid flushes his cache and make for the same request a new entry with a new TTL: $ squidclient mgr:username_cache HTTP/1.1 200 OK Server: squid Mime-Version: 1.0 Date: Thu, 21 Feb 2013 08:36:14 GMT Content-Type: text/plain Expires: Thu, 21 Feb 2013 08:36:14 GMT Last-Modified: Thu, 21 Feb 2013 08:36:14 GMT X-Cache: MISS from XXX Via: 1.1 XXX (squid) Connection: close Cached Usernames: 1 of 7921 Next Garbage Collection in 35 seconds. Type State Check TTL Cache TTL Username --------------- --------- --------- --------- ------------------------------ AUTH_NEGOTIATE Ok -1 3600 USER In the "good case", squid does not throw away the cache-entry and the TTL is decrementing (even after I make new requests) -> expected behavior. So, why does squid flushes the authentication-cache for every request, when I use "http_access allow INTERNET_ACCESS" (without the tag AUTHENTICATED)? And why does squid 3.1.20 behaves different? Probably a bug?
Yes probably a bug. The cache management on Negotiate and NTLM auth is a little screwed up by the credentials primarily being tied to the TCP connection instead of the username cache. So garbage collection of the cache can remove them even while they are still in use, or the cache can list them even after the TCP connection has died.
Amos
