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@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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
