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.cair...@ed.ac.uk> wrote in message news:6a32534a-d605-474f-9cca-79d373538...@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@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: ext6...@ed.ac.uk 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/test-exams-cache.www-dyn.ed.ac...@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@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: mark.cair...@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@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
