Before I reply in detail, I think I may not have made one point clear enough. This is not NTLM
pass-through to webservers via an upstream proxy, it's NTLM pass-through *to* an upstream proxy.
myproxy is sending 407/Proxy-Authenticate, not relaying 401/WWW-Authenticate on
behalf of a website.
If the pinning/unpinning in Squid is dependent on the hostname in the request, then this might
explain what I'm seeing.
What I need is for the pinning to remain in place regardless of the website being accessed. In fact
I can't think of any circumstance in which the upstream connection could legitimately be unpinned
once the NTLM conversation has been completed, as the upstream end would still believe that the
connection is in use by the original user.
Anyway, I shall do some more detailed packet traces so that I can answer Amos's
questions.
Amos Jeffries wrote:
On Wed, 9 Jun 2010 17:22:09 +0100, Jeff Silver <jsil...@websense.com>
wrote:
I'm using squid/3.1.3.
It is configured with a cache-peer thus:
cache_peer myproxy parent 8081 0 default no-query no-digest
no-netdb-exchange login=PASS
'myproxy' is not squid. It is NTLM-capable.
The NTLM log-in process works OK, but it looks as if squid is not
maintaining separation between
sessions (what I think used to be called "connection pinning"). In other
words, if two users log in
from two separate browsers, upstream connections are shared across the
two
sessions (especially if
the same site is being visited).
Are you sure both clients getting TCP_MISS? If one was a HIT then that one
never actually used the link, even if it used some content previously fetch
through the link.
Do you mean Squid itself is sharing the Squid->Upstream link with both
clients?
Is Squid interleaving their requests?
Is squid forcing one to auth to use the link, then forcing the other to
re-auth to use it, etc?
Squid will 'pin' previously used persistent connections if the client
starts sending NTLM auth down it. Also 'unpin' a connection if the client
changes its auth type, if auth fails, or the server connection dies. This
latter allows persistent client connections if something recoverable
happens to the server connection (ie TCP timeout), though the client should
be challenged to re-auth the full link.
An HTTP trace (of at least the request/reply header flowing over the
link), for both the links client->squid and squid->upstream will be needed
to look deeper at this.
I tried adding connection-auth=on to both the cache-peer line and the
http_port line (although squid
3.1 docs say that this is on by default).
I also tried sending a 'Proxy-support: Session-Based-Authentication'
header from myproxy.
Upstream connections were still being shared.
Is there anything else I should set in the configuration?
Is this a bug?
Persistent connections for both servers and clients is required. Though
the default should be to have both on now as well.
persistent_connection_after_error should also be left ON.
Other than those it should be working.
Amos
To report this as spam, please forward to s...@websense.com. Thank you.
Protected by Websense Hosted Email Security -- www.websense.com
