[squid-users] Kerberos Auth weirdness/inconsistency when using CNAMEs/Round-robin DNS

Wed Jun 18 08:49:49 UTC 2025

Hi,

I’ve been trying to get Kerberos Authentication against AD working but 
have been seeing inconsistent results/behaviour across multiple Oses and 
I’m not sure if the issue lies with the DNS configuration, Kerberos 
itself or with the Squid config:

THE DNS setup is as follows:

test.squid.cluster. 3600 IN           CNAME                
test-squid-cluster.dyn-zone.

test-squid-cluster.dyn-zone. 60 IN A 1.2.3.4

Where 1.2.3.4 is the IP of one of the servers in the cluster. The 
intention is to have multiple Squid servers behind a single DNS name for 
high-availability.

This is what I’m seeing in the cache log with my current setup:

Windows:

negotiate_kerberos_auth.cc(182): pid=668789 :2025/06/16 16:03:01| 
negotiate_kerb

eros_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS 
failure.  Min

or code may provide more information. Cannot find key for HTTP/ 
test-squid-cluster.dyn-zone at REALM kvno 2 in keytab (request ticket 
server HTTP/test.squid.cluster at REALM

Rocky Linux:

curl -ik -vvv -L --proxy-negotiate -U : -b ~/cookiejar.txt -c 
~/cookiejar.txt -x "test.squid.cluster:3128" https://www.bbc.co.uk

negotiate_kerberos_auth.cc(182): pid=668789 :2025/06/17 08:51:52| 
negotiate_kerb

eros_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS 
failure.  Min

2025/06/17 08:51:52| negotiate_kerberos_auth: INFO: User not authenticated

2025/06/17 08:51:52.964 kid1| ERROR: Negotiate Authentication validating 
user. R

esult: {result=BH, notes={message: gss_accept_sec_context() failed: 
Unspecified

er HTTP/server1@ <mailto:HTTP/marmalade.cache.ed.ac.uk at ED.AC.UK>REALM); }}

klist -e

Ticket cache: FILE:/tmp/krb5cc_138460_vF4BWcMsZu

Default principal: ext6033 at ED.AC.UK

17/06/25 08:51:44  17/06/25 18:51:24 krbtgt/REALM at REALM

         Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

17/06/25 08:51:52  17/06/25 18:51:24 HTTP/server@

         Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

         Ticket server: server/REALM at REALM

With the same behaviour if I use the Dynamic Zone record in the curl 
command i.e.

curl -ik -vvv -L --proxy-negotiate -U : -b ~/cookiejar.txt -c 
~/cookiejar.txt -x " test-squid-cluster.dyn-zone:3128" https://www.bbc.co.uk

Ubuntu 24.04

curl -ik -vvv -L --proxy-negotiate -U : -b ~/cookiejar.txt -c 
~/cookiejar.txt -x "test.squid.cluster:3128" "https://www.bbc.co.uk" works

negotiate_kerberos_auth.cc(815): pid=668789 :2025/06/18 09:11:17| 
negotiate_kerberos_auth: DEBUG: OK 
token=oYG3MIG0oAMKAQChCwYJKoZIhvcSAQICooGfBIGcYIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvJ1BxA5rnZjKbfBVE0YqUlnYx7oLguj09HLH4SJRumUjWWXh99B/4X72vpFqCXeOKmvzSDlWG0Io1ZjQxNOxqni4sFx8exojIzg4aIWKAcYB21OHr9m0T9dfymDVoV61Cofyq38fUaN5Loen9YX0h 
user=account
2025/06/18 09:11:17| negotiate_kerberos_auth: INFO: User account 
authenticated

klist -e
Ticket cache: FILE:/tmp/krb5cc_1001_7KsHEg
Default principal: account at REALM

Valid starting     Expires            Service principal
06/18/25 09:10:09  06/18/25 19:10:09  krbtgt/REALM at REALM
     renew until 06/19/25 09:09:36, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
06/18/25 09:11:17  06/18/25 19:10:09 HTTP/test-squid-cluster.dyn-zone@
     renew until 06/19/25 09:09:36, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

curl -ik -vvv -L --proxy-negotiate -U : -b ~/cookiejar.txt -c 
~/cookiejar.txt -x "test-squid-cluster.dyn-zone:3128" 
"https://www.bbc.co.uk"

Works as well

klist -e
Ticket cache: FILE:/tmp/krb5cc_1001_7KsHEg
Default principal: account at REALM

Valid starting     Expires            Service principal
06/18/25 09:17:11  06/18/25 19:17:11  krbtgt/REAM at REALM
     renew until 06/19/25 09:16:55, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
06/18/25 09:17:38  06/18/25 19:17:11 HTTP/test-squid-cluster.dyn-zone@
     renew until 06/19/25 09:16:55, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
     Ticket server: HTTP/test-exams-cache.www-dyn.ed.ac.uk at ED.AC.UK

Mac (Sequoia 15.5)

curl -ik -vvv -L --proxy-negotiate -U : -b ~/cookiejar.txt -c 
~/cookiejar.txt -x "test.squid.cluster.dyn-zone:3128" https://www.bbc.co.uk

2025/06/17 09:32:26| negotiate_kerberos_auth: INFO: User not authenticated

2025/06/17 09:32:26.600 kid1| ERROR: Negotiate Authentication validating 
user. R

esult: {result=BH, notes={message: gss_accept_sec_context() failed: 
Unspecified

GSS failure.  Minor code may provide more information. Cannot find key 
for HTTP/

test-squid-cluster.dyn-zone at REALM kvno 2 in keytab (request ticket serv

er HTTP/test.squid.cluster at REALM); }}

klist -v

Server: HTTP/test.squid.cluster at REALM

Client: account at REALM

Ticket etype: aes256-cts-hmac-sha1-96, kvno 2

Ticket length: 1690

Auth time:  Jun 17 09:32:17 2025

Start time: Jun 17 09:32:26 2025

End time:   Jun 17 19:31:56 2025

Ticket flags: enc-pa-rep, pre-authent, forwardable

Addresses: addressless

curl -ik -vvv -L --proxy-negotiate -U : -b ~/cookiejar.txt -c 
~/cookiejar.txt -x "test-squid-cluster.dyn.zone:3128" https://www.bbc.co.uk

Successful:

2025/06/17 09:36:38| negotiate_kerberos_auth: INFO: User account 
authenticated

2025/06/17 09:36:38.165 kid1| 82,2| external_acl.cc(700) 
aclMatchExternal: ldap_group = ALLOWED

Klist -v

Server: krbtgt/REALM@ <mailto:krbtgt/ED.AC.UK at ED.AC.UK>REALM

Client: account at REALM

Ticket etype: aes256-cts-hmac-sha1-96, kvno 11

Ticket length: 1683

Auth time:  Jun 17 09:36:31 2025

End time:   Jun 17 19:36:23 2025

Ticket flags: enc-pa-rep, pre-authent, initial, forwardable

Addresses: addressless

Server: HTTP/test-squid-cluster.dyn.zone at REALM

Client: account@ <mailto:ext6033 at ED.AC.UK>REALM

Ticket etype: aes256-cts-hmac-sha1-96, kvno 1

Ticket length: 1698

Auth time:  Jun 17 09:36:31 2025

Start time: Jun 17 09:36:38 2025

End time:   Jun 17 19:36:23 2025

Ticket flags: enc-pa-rep, pre-authent, forwardable

Addresses: addressless

The relevant parts of the squid.conf are:

http_port 3128

cache_mem 256 mb

maximum_object_size_in_memory 512 KB

maximum_object_size 2048 mb

cache_dir ufs /var/spool/squid 51200 16 256

debug_options ALL,2

visible_hostname test-squid-cluster.dyn.zone

unique_hostname server1

refresh_pattern .             0       20% 4320 ignore-reload

auth_param basic children 10

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k 
/etc/squid/HTTP.keytab -s HTTP/test-squid-cluster.dyn.zone at REALM -d -i -r

(We also have LDAP basic auth configured as a fallback which works as 
expected but modern Windows clients no longer support basic auth for 
proxy servers).

klist -k /etc/squid/HTTP.keytab

Keytab name: FILE:/etc/squid/HTTP.keytab

KVNO Principal

---- 
--------------------------------------------------------------------------

    1 TESTSQUIDCACHE@ <mailto:TESTEXAMSCACHE at ED.AC.UK>REALM

    1 TESTSQUIDCACHE@ <mailto:TESTEXAMSCACHE at ED.AC.UK>REALM

    1 TESTSQUIDCACHE@ <mailto:TESTEXAMSCACHE at ED.AC.UK>REALM

    1 HTTP/test-squid-cache.dyn.zone at REALM

    1 HTTP/test-squid-cache.dyn.zone at REALM

    1 HTTP/test-squid-cache.dyn.zone at REALM

/etc/hosts

1.2.3.4 server1.cache server1 test-squid-cache.dyn.zone test.squid.cluster

Finally the keytab was generated using msktutil e.g.

msktutil -c -h test-squid-cache.dyn.zone -b 
'OU=Managed-Linux,OU=Infrastructure' --computer-name TESTSQUIDCACHE -s 
HTTP/test-squid-cache.dyn.zone -k /etc/squid/HTTP.keytab --server 
domain.controller --realm REALM --use-service-account 
--dont-expire-password --upn HTTP/test-squid-cache.dyn.zone at REALM

This works fairly well/reliably if we use a keytab containing the 
HTTP/fqdn of the server itself i.e. HTTP/server1 AND connect using curl 
using the FQDN of server1 but we need resiliency and high-availability 
so having a single-host service would be a last resort.

Any ideas on where I’m going wrong or what I need to add in terms of 
DNS/keytab entries? Also some of the clients attempt to use key versions 
which have never been issued e.g. kvno 4?

Kind regards,

Mark

--
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: _Mark.Cairney at ed.ac.uk_

*******************************/

The University of Edinburgh is a charitable body, registered in 
Scotland, with registration number SC005336.signature_2526785256
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20250618/52049dec/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 263 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20250618/52049dec/attachment-0001.png>