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