[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