[squid-users] squid 5.9 Kerberos authentication problem

Thu Oct 5 17:15:08 UTC 2023

>>>>> Amos Jeffries <squid3 at treenet.co.nz> 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.151      0 x.y.z TCP_DENIED/407 4179 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.154      0 x.y.z TCP_DENIED/407 4179 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.155      0 x.y.z TCP_DENIED/407 4179 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.155      0 x.y.z TCP_DENIED/407 4179 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.163      0 x.y.z TCP_DENIED/407 4179 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
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 -
1695983168.440      0 x.y.z TCP_DENIED/407 4139 CONNECT www.bing.com:443 - HIER_NONE/- text/html
1695983181.337 103937 x.y.z TCP_TUNNEL/200 7562 CONNECT browser.events.data.msn.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983181.367     15 x.y.z TCP_DENIED/407 4254 CONNECT assets.msn.com:443 - HIER_NONE/- text/html
1695983181.367     28 x.y.z TCP_DENIED/407 4254 CONNECT assets.msn.com:443 - HIER_NONE/- text/html
1695983181.504     24 x.y.z TCP_DENIED/407 4306 CONNECT browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.504     26 x.y.z TCP_DENIED/407 4306 CONNECT browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.559      0 x.y.z TCP_DENIED/407 4306 CONNECT browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.662      5 x.y.z TCP_DENIED/407 4234 CONNECT c.msn.com:443 - HIER_NONE/- text/html
1695983181.847      5 x.y.z TCP_DENIED/407 4238 CONNECT c.bing.com:443 - HIER_NONE/- text/html
1695983182.031     12 x.y.z TCP_DENIED/407 4242 CONNECT th.bing.com:443 - HIER_NONE/- text/html
1695983194.404      0 x.y.z TCP_DENIED/407 3952 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983200.151      0 x.y.z TCP_DENIED/407 3952 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983201.409  20034 x.y.z TCP_TUNNEL/200 4166 CONNECT assets.msn.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983202.682 131076 x.y.z TCP_TUNNEL/200 6868 CONNECT assets.msn.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983205.701      0 x.y.z TCP_DENIED/407 3952 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983221.409      0 x.y.z TCP_DENIED/407 3952 CONNECT gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983233.498   5002 x.y.z TCP_DENIED/407 4139 CONNECT www.bing.com:443 - HIER_NONE/- text/html
1695983241.717  77946 x.y.z TCP_TUNNEL/200 7596 CONNECT edge.microsoft.com:443 - FIRSTUP_PARENT/squid-parent -
1695983241.717  76955 x.y.z TCP_TUNNEL/200 58182 CONNECT ntp.msn.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.717  76795 x.y.z TCP_TUNNEL/200 8279 CONNECT api.msn.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.718  76731 x.y.z TCP_TUNNEL/200 110495 CONNECT assets.msn.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.718  74275 x.y.z TCP_TUNNEL/200 6756 CONNECT edge.microsoft.com:443 - FIRSTUP_PARENT/squid-parent -
1695983241.718  76590 x.y.z TCP_TUNNEL/200 42623 CONNECT assets.msn.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.718  73876 x.y.z TCP_TUNNEL/200 95997 CONNECT th.bing.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.718  74645 x.y.z TCP_TUNNEL/200 18121 CONNECT business.bing.com:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.718  18104 x.y.z TCP_TUNNEL/200 59080 CONNECT edge.microsoft.com:443 - FIRSTUP_PARENT/squid-parent -
1695983241.719  18234 x.y.z TCP_TUNNEL/200 7147 CONNECT go.microsoft.com:443 - FIRSTUP_PARENT/squid-parent -
1695983241.719  76826 x.y.z TCP_TUNNEL/200 7443 CONNECT deff.nelreports.net:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.719  74620 x.y.z TCP_TUNNEL/200 8392 CONNECT gw1.ris.datacentrum.sk:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.719  74562 x.y.z TCP_TUNNEL/200 4477 CONNECT gw1.ris.datacentrum.sk:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.719  74552 x.y.z TCP_TUNNEL/200 4476 CONNECT gw1.ris.datacentrum.sk:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.719  74547 x.y.z TCP_TUNNEL/200 11278 CONNECT gw1.ris.datacentrum.sk:443 name at domain FIRSTUP_PARENT/squid-parent -
1695983241.719  74552 x.y.z TCP_TUNNEL/200 66247 CONNECT gw1.ris.datacentrum.sk:443 name at domain FIRSTUP_PARENT/squid-parent -

In the gw1.ris.datacentrum.sk, there is authentication on the site
inside SSL. It is not working. As soon as I exclude
gw1.ris.datacentrum.sk from the authentication in squid, it starts
working.

    > 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>

I have no access to a windows machine. As soon as I get an access to a
windows machine, I can do the tests.

    >> 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.

Yes, I understand this.

The problem is, the client cannot access the above mentioned site with
authentication in squid.

Regards,

lk