[squid-users] squid 5.9 Kerberos authentication problem

[Amos Jeffries]

On 6/10/23 06:15, Ludovit Koren wrote:
>>>>>> Amos Jeffries writes:
> 
>      > 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.
> 
> ok, this is little bit longer output:


> 1695983167.837      0 x.y.z TCP_DENIED/407 4135 CONNECT th.bing.com:443 - HIER_NONE/- text/html
> 1695983167.842      1 x.y.z TCP_DENIED/407 4135 CONNECT th.bing.com:443 - HIER_NONE/- text/html
> 1695983167.873     27 x.y.z TCP_TUNNEL/200 6080 CONNECT th.bing.com:443 name at domain FIRSTUP_PARENT/squid-parent -

Taking this set of th.bing.com requests as clearly a bunch related they 
look like an NTLM or Negotiate/NTLM authentication sequence.


The rest of the log entries are a little too spread out with a mix of 
domains to tell where the connections are.

Also, the 200 status CONNECT tunnels in this log extract were all 
running from a time before the first line of the log snippet. So we 
cannot see how they reached 200 status.


> 
> In the gw1.ris.datacentrum.sk, there is authentication on the site
> inside SSL. It is not working.

FYI, "inside SSL" is just opaque bytes to Squid. Any failure there is 
between the client and server at the other end of the CONNECT tunnel. 
Nothing to do with this Squid.


> As soon as I exclude
> gw1.ris.datacentrum.sk from the authentication in squid, it starts
> working.

That is an indication that the client software is unable to handle 
authentication on the CONNECT tunnel properly.



For better troubleshooting there are several steps to take:

* making a custom log format and a debug log for your Squid would be 
useful to get more details about each transaction.

  I suggest adding this to your squid.conf:

  logformat debug %ts.%03tu %6tr %>a cid=%>p_%lp_%ssl::bump_mode \
     %Ss/%03>Hs %<st %rm %ru \
     user=%[un/login=%[ul/token=%[credentials %Sh/%<a/%03<Hs

  access_log /var/log/squid/debug.log debug


The "cid=" entry should be a semi-unique value per TCP connection. It is 
not true unique since ports get re-used, but should be reliable enough 
to separate overlapping connections with duplicate request URLs.

The user=/login=/token= part should allow you to see what/why the 407 is 
occuring. You can investigate the token value with this tool 
<https://gist.github.com/aseering/829a2270b72345a1dc42> to see if it is 
truly a Negotiate/Kerberos token vs a Negotiate/NTLM one.



If you need more assistance, I/we will need to see your squid.conf (in 
full but without the "#" comment lines) and the output trace from that 
debug.log.

HTH
Amos