Firstly, let me say that whatever you are using for a mail client makes
reading/replying to your message difficult (see below for a small
sample, I will clean up the rest as best I can)...
I did manage to get this working, you did mention the correct solution
right down the end of your message.
On Thu, Jan 07, 2016 at 09:37:46AM +0100, L.P.H. van Belle wrote:
> Hai,
>
>
>
Just in case it doesn't show - you have a lot of control-M characters
through your message.
> First whats your OS/squid and samba version, handy to know.
>
I did mention squid as being 3.5.12, OS is RHEL 6.7, samba was the
built in RHEL version, 3.6.23.
> And post your smb.conf please.
>
Well, just for posterity.
[global]
workgroup = AU
server string = %h
netbios name = %h
pid directory = /var/run
lock directory = /var/cache/samba
log file = /var/log/samba/%m.log
security = user
passdb backend = tdbsam
security = ADS
client use spnego = yes
realm = AU.BAESYSTEMS.COM
server signing = auto
domain master = no
dns proxy = no
kerberos method = secrets and keytab
dedicated keytab file = /etc/krb5.keytab
>
>
> 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.
> Run : klist -e -k /etc/krb5.keytab post the output.
>
I won't do this for brevity - the principals and encryption types were
fine. I had already checked this as I stated in my original post.
>
>
> Your SPN for squid must be HTTP/fqdn
>
> And not http/fqdn CAPS do matter here.
>
windows doesn't care, lower case actually worked fine for me in the end.
If you do a kinit on the linux command line then you must match the case
in the keytab.
>
>
> Put the HTTP/fqdn spn in a separated file and put it in the squid dir.
>
> Chown and chmod it root:squid-user 440
>
If you do this then when/if the machine account password changes then
the SPN will be invalidated. Also you assume that the kerberos
authenticator is being run as a user in the group squid-user which is
not always the case.
>
>
> Add it in your squid init script ( for debian i added it in /etc/default/squid ( squid for 3.5.12 ) (squid3 for 3.4.8 )
>
> KRB5_KTNAME=/etc/squid/keytab.PROXY1-HTTP
>
> export KRB5_KTNAME
>
For RHEL that is /etc/sysconfig/squid.
>
> The squid keytab should be like (manualy added on a different user in the AD, special user for squid services.):
>
This is how we currently run. Security policies require the user
account password to be changed regularly. This means a disruption to
the squid services while we change the password, export the keytab and
merge the entries into the proxy server keytab.
>
> install ntp and point it to you AD so time is always in sync.
>
Yes, time sync is important but pointing ntp at AD won't work properly.
The inital ntpdate will work but the ongoing sync does not - AD doesn't
do ntp. Much better if you sync AD time to a proper ntpd (unix/linux)
>
>
> Or with everyting in one keytab file and make sure squid can read this keytab file 640 root:squid !! :
>
Yes, this is what I did eventually though mine was root:nobody.
>
> I have a setup with a separated keytab file, i tested above and these work.
>
> ( tested on debian jessie, samba 4.1, squid 3.4.8, 3.5.10 and 3.5.12. )
>
Yes, we have had a separate keytab file working for a long time on rhel
with samba3 and our custom squid rpms. I wanted to avoid having to
manage a separate AD user.
>
> A big advantave with the squid-service user. You kan add all you squid hosts/services in that user.
>
> I have 1 user for this and 3 proxy servers.
>
It does mean that one password change invalidates the keytab on 3
proxies...
>
> Optionaly, start the auth progrom on command line, with the debugging enabled.
>
Yes, that wasn't terribly usful in this case though and running
negotiate_kerberos_auth_test as root and actually getting tickets was
downright confusing.
--
Brett Lymn
This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:
BAE Systems Australia Limited - Australian Company Number 008 423 005
BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846
BAE Systems Australia Logistics Pty Limited - Australian Company Number 086 228 864
Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
Edinburgh, South Australia, 5111. If the identity of the sending company is
not clear from the content of this email please contact the sender.
This email and any attachments may contain confidential and legally
privileged information. If you are not the intended recipient, do not copy or
disclose its content, but please reply to this email immediately and highlight
the error to the sender and then immediately delete the message.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
