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

Sat Aug 16 18:55:27 UTC 2025

Hi Mark,

   Be aware that Browsers may behave differently when using CNAMES.   Some Browser uses the HTTP/<CNAME> ticket and some use HTTP/<NAME of reverse lookup of the CNAME IP>

   e.g. if proxy.example.com is a cname for server1.example.com on 192.168.1.2

   You may need tickets for both i.e. HTTP/proxy.example.com AND HTTP/server1.example.com  

   If you use GSLB or other load balancing techniques make sure all server keys plus the GSLB and CNAME keys are included in the keytab on all servers supporting the GSLB or CNAME..

Markus

"Mark Cairney" <Mark.Cairney at ed.ac.uk> wrote in message news:6a32534a-d605-474f-9cca-79d3735385b4 at ed.ac.uk...
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 at 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 at 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 at 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 at REALM

   1 TESTSQUIDCACHE at REALM

   1 TESTSQUIDCACHE at 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.<!--[if !vml]--><!--[endif]-->

--------------------------------------------------------------------------------
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20250816/12301dae/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/20250816/12301dae/attachment-0001.png>