[squid-users] kerberos authentication with a machine account doesn't work
L.P.H. van Belle
belle at bazuin.nl
Thu Jan 7 08:37:46 UTC 2016
Hai,
First whats your OS/squid and samba version, handy to know.
And post your smb.conf please.
Few things to check.
/etc/krb5.keytab should have rights 600 (root:root)
Run : klist -e -k /etc/krb5.keytab post the output.
Your SPN for squid must be HTTP/fqdn
And not http/fqdn CAPS do matter here.
Put the HTTP/fqdn spn in a separated file and put it in the squid dir.
Chown and chmod it root:squid-user 440
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
The squid keytab should be like (manualy added on a different user in the AD, special user for squid services.):
KVNO Principal
---- -----------------------------------------------------------------------
1 HTTP/host.internal.domain.tld at YOUR_REALM (des-cbc-crc)
1 HTTP/host.internal.domain.tld at YOUR_REALM (des-cbc-md5)
1 HTTP/host.internal.domain.tld at YOUR_REALM (arcfour-hmac)
This is my default ( /etc/krb5.keytab ) (from the join of samba.)
1 host/host.internal.domain.tld at YOUR_REALM (des-cbc-crc)
1 host/host.internal.domain.tld at YOUR_REALM (des-cbc-md5)
1 host/host.internal.domain.tld at YOUR_REALM (aes128-cts-hmac-sha1-96)
1 host/host.internal.domain.tld at YOUR_REALM (aes256-cts-hmac-sha1-96)
1 host/host.internal.domain.tld at YOUR_REALM (arcfour-hmac)
1 host/host at YOUR_REALM (des-cbc-crc)
1 host/host at YOUR_REALM (des-cbc-md5)
1 host/host at YOUR_REALM (aes128-cts-hmac-sha1-96)
1 host/host at YOUR_REALM (aes256-cts-hmac-sha1-96)
1 host/host at YOUR_REALM (arcfour-hmac)
1 HOST$@YOUR_REALM (des-cbc-crc)
1 HOST$@YOUR_REALM (des-cbc-md5)
1 HOST$@YOUR_REALM (aes128-cts-hmac-sha1-96)
1 HOST$@YOUR_REALM (aes256-cts-hmac-sha1-96)
1 HOST$@YOUR_REALM (arcfour-hmac)
The needed krb5.conf
cat /etc/krb5.conf
[libdefaults]
default_realm = YOUR_REALM
dns_lookup_kdc = true
dns_lookup_realm = false
ticket_lifetime = 24h
ccache_type = 4
forwardable = true
proxiable = true
install ntp and point it to you AD so time is always in sync.
Now you have 2 options to setup and you choose based on you SPN setup.
Seperated keytab for squid HTTP service.
Use:
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth -d \
--kerberos /usr/lib/squid/negotiate_kerberos_auth -s HTTP/ host.internal.domain.tld at YOUR_REALM \
--ntlm /usr/bin/ntlm_auth --helper-protocol=gss-spnego --domain=NTDOMAIN
Or with everyting in one keytab file and make sure squid can read this keytab file 640 root:squid !! :
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth \
--kerberos /usr/lib/squid/negotiate_kerberos_auth -s GSS_C_NO_NAME -d \
--ntlm /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=NTDOMAIN
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. )
Above i told about how i did setup.
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.
So where did you go wrong.
> net ads keytab add HTTP
And rights on the /etc/krb5.keytab file are the first things to check.
Optionaly, start the auth progrom on command line, with the debugging enabled.
Greetz,
Louis
> -----Oorspronkelijk bericht-----
> Van: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] Namens
> LYMN
> Verzonden: donderdag 7 januari 2016 5:23
> Aan: squid-users at squid-cache.org
> Onderwerp: [squid-users] kerberos authentication with a machine account
> doesn't work
>
>
> Hi,
>
> We have been using kerberos authentication against Active Directory here
> for a long time by using a SPN attached to a user account and exporting
> the keytab. The issue we have is that security policy mandates that
> the password on the user account be changed which means we have to go
> and regenerate keytabs every time this happens. Not exactly difficult
> but tedious nonetheless.
>
> To avoid the password change I thought it may be an idea to use the
> machine account and add a SPN (http/fqdn.is.here) to that. I added:
>
> kerberos method = secrets and keytab
> dedicated keytab file = /etc/krb5.keytab
>
> to the smb.conf so samba will manage the keytab for me then did:
>
> net ads join
> net ads keytab add http
>
> klist -k shows me the principals that should be there and AD agrees they
> exist. I can get a TGT using:
>
> kinit -k
>
> without error (setting the UPN to host/fqdn.is.here at KERBEROS.REALM may
> have helped this). Doing a
>
> kinit -kS http/fqdn.is.here
>
> works without error too. So, I think kerberos is ok but with a squid
> 3.5.12 configured with negotiate_kerberos_auth I see the dreaded
> message:
>
> negotiate_kerberos_auth.cc(180): pid=4888 :2016/01/07 12:50:29|
> negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed:
> Unspecified GSS failure. Minor code may provide more information.
>
> and only that, no minor code when I try to use the proxy with a browser
> on a windows client. Interestingly, doing a klist on the windows client
> I can see a kerberos ticket for HTTP/fqdn.is.here that is for the proxy
> I am testing.
>
> Not sure what is missing here, I have a bee in my bonnet that this should
> Just Work (tm) as the only real difference is that the SPN is attached
> to a computer account not a user account - I would have thought as long
> as the keytab is done correctly that this should not matter but clearly
> something is not agreeing with me.
>
> --
> 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160107/14d4e968/attachment-0001.html>
More information about the squid-users
mailing list