On 11/01/2016 2:48 p.m., LYMN wrote: > > I did manage to get this working, you did mention the correct solution > right down the end of your message. > Correct for you yes. That can happen when making half-blind guesses at what the problem actually is based on partial information. It might have been any of the issues mentioned or any of the solutions mentioned. Others in future may find differently depending on what they have mucked up or payed around with before asking. > On Thu, Jan 07, 2016 at 09:37:46AM +0100, L.P.H. van Belle wrote: >> Hai, >> >> >> Few things to check. >> >> /etc/krb5.keytab should have rights 600 (root:root) >> > > And this was the problem but it should not, in my case, be as you > stated. In fact, /etc/krb5.keytab needed to have rights 640 with > ownership root:nobody. This is because the kerberos authenticator runs > as the user nobody and needs access to the keytab. I am not so sure I > like this situation because this does mean the nobody user now has > access to the machine kerberos keys not just the ones for the http SPN. "nobody" is the default low-privileged user account unless you build Squid with the --with-default-user=X - in which cases it will default to the "X" account. You can also configure "cache_effective_user X" in squid.conf to override the default if your Squid was built with one you dont want to use. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
