Re: [squid-users] NTLM authentication pass-through to upstream proxy

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 <jsilver_at_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 spam_at_websense.com. Thank you.

 Protected by Websense Hosted Email Security -- www.websense.com
Received on Thu Jun 10 2010 - 08:32:09 MDT