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
