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."
