On 2/03/2012 11:53 a.m., Brett Lymn wrote:
On Thu, Mar 01, 2012 at 10:02:06PM +1300, Amos Jeffries wrote:
Can't you just support proper authentication?
I can but I have problems if I try and use kerberos for authentication.
I have kerberos working fine with squid, the auth works ok - I even have
it working correctly with the squids behind a load balancer *but* when I
turn authentication on at the upstream proxy the authentication fails at
the upstream. I can see in the status page for the upstream that
kerberos is being tried but failing probably because the principal name
is wrong but I am not sure about that. By the looks of it they are
using samba on the upstream to perform the authentication. I don't know
if it would work finding the keytab and adding the keys that squid
uses... that may have a chance of working... maybe.
You really need that functionality from 3.2 then.
* login=NEGOTIATE to have one key representing your Squid and all
users going through it. Or at least one key peer cache_peer line ;)
Or
* login=PASSTHRU to act as a transparent proxy (HTTP meaning) with
regards to proxy-auth. NTLM passthru fails if squid is authenticating
due to NTLM multi-stage handshake. But Kerberos works fine with both
layers validating and rejecting invalid keys (assuming they are both
checking it against the same AD control servers).
Despite any claims they might make, X-Authenticate-User would not work
for a properly authenticating upstream either. Since the data in it
lacks the password/token it cannot be re-authenticated, and is easily
forged. At worst they are claiming authentication but not actually doing
any when X-Authenticate-Info is received (scary thought).
Amos
