[squid-users] squid 5.9 Kerberos authentication problem

[Amos Jeffries]

On 5/10/23 19:30, Ludovit Koren wrote:
> 
> Hello,
> 
> I am using squid 5.9 with AD Kerberos authentication and could not solve
> the problem of sending incorrect request according to client
> configuration followed by the correct one, i.e.:
> 
> 1695983264.808      0 x.y.z TCP_DENIED/407 4135 CONNECT th.bing.com:443 - HIER_NONE/- text/html
> 1695983264.834     21 x.y.z TCP_TUNNEL/200 6080 CONNECT th.bing.com:443 name at domain FIRSTUP_PARENT/squid-parent -
> 

This looks fine to me. The first request is sent without credentials, 
then the second contains the correct ones using the correct 
authentication scheme.

TL;DR ... I would only be worried if there were sequences 2+ of these 
407 before the final 200 status.


CONNECT tunnels are typically opened on a brand new TCP connection. Also 
the Negotiate authentication scheme used for Kerberos requires a unique 
token per-connection which is only received in the first HTTP response 
from Squid to client. Meaning the full 2-stage authentication process is 
needed every time for it to figure out how it is supposed to 
authenticate on that TCP connection.

Compared to other HTTP requests which often re-use an already 
authenticated TCP connection. So they get away with assuming the offered 
authentication schemes, and/or Kerberos token, will remain unchanged. 
Allowing the negotiation stage to be skipped.


If you are worried; you can try running the testing/troubleshooting 
checks detailed at 
<https://wiki.squid-cache.org/Features/NegotiateAuthentication#testing>


> There are some web servers which are not working even when the correct
> request follows afterwards.
> 

The TCP connection between client and Squid is different (and 
independent) from the TCP connections between Squid and servers.
The authentication you are using is only between client and Squid, it 
has nothing to do with web servers.


Cheers
Amos