[squid-users] squid 5.9 Kerberos authentication problem

Tue Oct 10 09:23:27 UTC 2023

Hi,

I am sorry to bother you once again, but I sent you and described just
the problem you were talking about and did not get any answer.

In the logged output you can see several 407 and afterwards 200 error
code just as you described, that the state you worry about.

Is there any solution to this?

Regards,

lk

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