Re: Kerberos Auth weirdness/inconsistency when using CNAMEs/Round-robin DNS

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" <[email protected]> wrote in message news:[email protected]...
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@REALM kvno 2 in keytab (request ticket server HTTP/test.squid.cluster@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@REALM); }}

 

klist -e

Ticket cache: FILE:/tmp/krb5cc_138460_vF4BWcMsZu

Default principal: [email protected]

17/06/25 08:51:44  17/06/25 18:51:24  krbtgt/REALM@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@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@REALM

Valid starting     Expires            Service principal
06/18/25 09:10:09  06/18/25 19:10:09  krbtgt/REALM@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@REALM

Valid starting     Expires            Service principal
06/18/25 09:17:11  06/18/25 19:17:11  krbtgt/REAM@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/[email protected]


 

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@REALM kvno 2 in keytab (request ticket serv

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

 

klist -v

Server: HTTP/test.squid.cluster@REALM

Client: account@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@REALM

Client: account@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@REALM

Client: account@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@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@REALM

   1 TESTSQUIDCACHE@REALM

   1 TESTSQUIDCACHE@REALM

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

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

   1 HTTP/test-squid-cache.dyn.zone@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@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: [email protected]

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

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.<!--[if !vml]--><!--[endif]-->



--------------------------------------------------------------------------------
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users