Re: [squid-users] enabling X-Authenticated-user

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.

Unfortunately, the upstream is pretty much a commercial black box, I
have little control over what it does nor what it requires. I can only
go by the documentation they offer. From what I can see of the logging
and so forth it seems that all the upstream does is take the username
and do a LDAP lookup to get the distinguished name, it can then use that
to check group memberships or look for user specific actions that may be
configured. Again, in my case, since everything is using the same
Active Directory the chances of squid authenticating and the upstream
not finding the user is slim - anyway, in my case, this would not be a
total disaster it would simply mean the user gets a set of default
actions applied to them.

>
> I'm reluctant to add the header because the data is already transmitted
> in the authentication headers.
>

Yes, understood. The problem I have is that, as I said, this upstream
is pretty much a black box so they set the rules and they won't change
them. Hell, the software insists on running on a 32 bit OS and asking
about WTF the 64bit version was was met with pretty much silence.

> Squid does have a little issue automatically mapping
> Kerberos/NTLM/Digest usernames into a Basic auth because we cannot
> easily be sure if a fake password is acceptable or real one needed by
> the upstream. I'm quite happy to accept patches which add that mapping
> ability to Squid in a secure way.
>

Definitely need a real password if the upstream is authenticating.. hmmm
or maybe not...they do give the option of authentication against an ldap
server. I wonder if I could set up a LDAP proxy that would fake up the
authentication, it could check the user exists in AD and just OK the
auth.

I am happy to do anything up to and including coding that will get me
out of this hole - if I cannot make this work somehow then I am going to
have to dump squid and try and get the stupid upstream to do all the
clever things that we currently do with squid, this would be a world of
hurt that will continue to give for the life of the damned things.

> NP: an external_acl_type helper can return the key-pairs "user=X
> password=Y" (both needed to do this) to associate some credentials to
> the request. These are available to login=PASS for relay upstream in the
> Basic auth format.
>

OK but can I manage to get a password when using negotiate? I didn't
think so but I am usually wrong. People here view an authentication
popup box as an error when they are browsing so unless I can make it
work with integrated windows authentication it won't be an option.

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."