Re: [squid-users] Fwd: Forwarding Integrated Authentication for Terminal Server / Citrix users.

On 1/10/12 4:48 PM, "Amos Jeffries" <squid3_at_treenet.co.nz> wrote:

>On 11.01.2012 02:55, Jason Fitzpatrick wrote:
>> Hi all
>>
>> We are in the process of replacing an ISA cluster with a Squid
>> Cluster
>> (Squid Cache: Version 3.1.14) and have run into some issues with the
>> forwarding of credentials to an upstream proxy.
>>
>> Our setup is as follows (names and IP addresses just for explanation
>> purposes)
>>
>> Netscaller Load-ballancer 10.0.0.10:8080 [squid.domain.local]
>>
>> Squid Node 1 10.0.0.11:8080
>> [squidnode1.domain.local] - sibling
>> Squid Node 2 10.0.0.12:8080
>> [squidnode2.domain.local] - sibling
>>
>> Upstream Websense 10.0.0.20:8080 [websense.domain.local]
>> - parent
>>
>> Upstream Transparent Proxy 10.1.0.10:8080 [parent.domain.local] -
>> parent
>>
>> Clients connect in from within a Citrix / Terminal server environment
>> to the load-ballancer, which in turn forwards the TCP connection to
>> one of the squidnode's (load ballanced / round robin with failover)
>> The Squid then forwards the connections onto the websense system
>> using
>> the following directive from squid.conf (ex from node 1)
>>
>> cache_peer 10.0.0.20 parent 8080 3130 no-query login=PASS weight=4
>> cache_peer 10.0.0.12 sibling 8080 3130 login=PASS
>>
>> The websense (running on a linux platform) then authenicates the
>> users
>> and based on its access rules then forwards the request onto the
>> upstream server and off to the internet.
>>
>> Our issue is that the websense does not seem to be authenticating all
>> Terminal Server / Citrix users correctly, it is set up to use IWA
>> with
>> a fall back to ntlm authentication, it seems to be authenticating the
>> 1st connection via the squid from the IP address of the TS but not
>> the
>> following ones.
>
>"seems" was probably a good choice of word there. Consider how is this
>authentication happening? based on what details?
>
> 1) HTTP is a stateless protocol. Multiple users requests can leave
>Squid sharing one TCP connection. => TCP and IP level details is not a
>good indication of the "user" viewing the response.
>
> 2) Squid caches responses. Multiple users can share a single response.
>=> requesting client details are not a good indication of the "user"
>viewing any cacheable response.
>
>
>Having eliminated TCP and IP, possibly also HTTP information from
>reliability what is left: only non-cachead responses and requests with
>authentication credentials which are passed back explicitly.
>
>The way Squid handles NTLM is to break HTTP performance and disable
>(1). But only for DIRECT traffic, when going through peers it does not
>always work. See below.
>
>
>>
>> Websense seem to think that this is a problem with the squid
>> configuration but I am not sure that this is true as the squid is
>> only
>> forwarding on the authentication request to the websense box. Does
>> Squid have the ability to differentiate between multiple users on a
>> single computer?
>
>Yes. HTTP authentication supports multiple users in one request stream.
>But NTLM is not user authentication. It is layer 2 TCP connection
>authentication done over HTTP at layer-7. The difference and
>interactions can cause confusing side effects. Squid supports receiving
>and validating such authentication itself. Recent Squid also support
>relaying it in www-auth logins to a web server to some degree
>(reliability varies a LOT across the Internet environment).
>
>The problem in your config is that "login=PASS" only passes Basic
>proxy-auth credentials. If no Basic auth credentials are present Squid
>will erase the existing ones and create some Basic ones with any details
>it can find for that user.
> * NOTE that Proxy-Authentication header are hop-by-hop, So "passing
>credentials on" is not a matter of relaying headers, but of Squid
>logging itself into the remote server, which is not supporting NTLM
>proxy-auth.
>
>The other part of the problem is whether websense is needing www-auth
>or proxy-auth. Probably proxy-auth which will not work in 3.1 due to the
>above lack of support.
>
>For NTLM you need at minimum a squid release which supports both
>login=PASSTHRU and connection-auth=on. This is the actual pass-thru
>style of proxy-auth headers. Officially that is 3.2, but the PASSTHRU
>patches can be adjusted easily to 3.1. By itself the PASSTHRU is no
>guarantee either, we have reports of some as yet unidentified problems
>with NTLM. Test carefully before use.
>
>
>Overall it is best to perform access controls at the point of entry to
>the system, rather than halfway across it, which means in those sibling
>Squids. The 3.2 login=NEGOTAITE option supports this with the front-end
>squid performing authentication of the users (any of the HTTP auth types
>you like) and passing their name info backwards to websense (if needed
>at all) down a connection secured with Squids own Kerberos credentials.
> Note that this is how NTLM and Kerberos were originally designed to be
>used. Authenticating the TCP connection directly between two services
>with no middleware accessing the authenticated connection.
>
>
>Amos

We are in a similar situation with Websense as the upstream peer. Having
tried various configuration changes we are going to build the 3.2 version
of Squid and see if the behavior improves. What we have seen is that with
NTLM being run locally (ntlm_auth), the pages rendered are more
consistently correct but in some cases horribly slow, with NTLM being
done at the Websense end, pages load faster but less reliably (rendering
problems, missing images).

I'll report back any findings of interest but I am wondering if the OP has
had any success with anything that has been tried.

Thanks,

Chris
>