On Thu, 31 Mar 2005, Matt Hamilton wrote:
The main issue is that whilst squid (2.5 at least) supports keepalives to the clients and the parent/neighbour caches there is no real way to get all the requests in one keepalive session to go to the same neighbour cache. This is a requirement in order to get NTLM to work through the cache.
Proxying of NTLM requires connection pinning, not only persistent connections. This has been discussed a couple of times before and is generally viewed as something we should eventually implement, but not very important.
I have been working through the squid code for a bit now and have managed to implement a neighbour selection policy that keeps track of the initial neighbour selected for a keepalive session and then subsequently re-uses this.
This is not sufficient to solve your problem. You need to reuse the exact same connection, not only peer. And you need to make sure no other clients can use that connection while it is idle. If not horror will arise when there is multiple clients accessing the same server.
Client A request some authenticated resource.
Client B request some authenticated resource and gets the server connection opened by client A as this is now an idle persistent connection.
At this stage your server will think it was Client A who sent both requests.
There is also similar problems during the authentication handshake as such, which will cause random failures if not dealt with correctly.
So in essense you are looking at the problem from a slightly bad angle, causing you to go down the wrong and very dangerous path in solving this problem.
Generally it is best (and easiest) if you do the NTLM on the reverse proxy, and only forward the user name to the web server using the login=*:secret cache_peer option.
You could also implement connection pinning but this assumes that you have straight forwarding on a domain basis, not selecting different backend servers depending on what file/directory is requested. This is due to NTLM being connection oriented making it impossible to maintain authentication for the same client connection with two different backend web servers.
Regards Henrik
