[squid-users] Problem with HAProxy + Squid 4.11 + Kerberos authentication

[Service MV]

Thanks Amos, Kerberos is really hard to learn for a rookie like me, but you
explained it in an excellent and concise way.
In my case, the SQUID servers are joined to the domain with their
respective SPN and UPN that I mentioned in the msktutil command.
And in the case of the Load Balancer HAProxy I used a user account and I
set that the password does not expire. I know this may not be the safest
way to do it, but I couldn't find a way to do it with a computer account. I
guess I should join the HAProxy to the domain as well.
The detail, as you mentioned, is that the DNS A record (eg
inet.mydomain.local) is to match exactly the SPN for that user account,
which at this point is a service account.

Thanks again

Gabriel

El vie., 24 de jul. de 2020 a la(s) 00:10, Amos Jeffries (
squid3 at treenet.co.nz) escribió:

> On 24/07/20 5:09 am, Service MV wrote:
> > Hi Klaus,
> > I think something similar. But I understand that you can use the
> > Kerberos delegation in AD. That's partly why I'm not convinced by the
> > documentation I read, which tells me to create a user account in Active
> > Directory. And I don't understand what a user account has to do here.
> > Maybe the documentation is wrong and actually refers to a computer
> > account, and the operation of adding a Service Principal Name should be
> > done to the computer object. I don't know. But I'm going to try to do it
> > and see what I can achieve.
> >
>
> Kerberos authentication in HTTP uses the Negotiate scheme. The model for
> that scheme is that it authenticates the exact TCP connection over which
> the credentials are transmitted.
>
> So for it to work *through* a proxy (eg HAProxy) that proxy must ensure
> the *two* TCP connections it is handling (from-client and to-Squid) are
> pinned together with all HTTP multiplexing features disabled _and_ the
> Proxy-Auth* headers are not touched or used along the way.
>
>  => If either of those conditions is broken the auth will not work and
> users will definitely get the behaviour you are seeing. That behaviour
> may also occur anyway if later stages are broken - this is just the
> first and most non-obvious problem for beginners.
>
>
> [ below is simplified a bit/lot to ensure you have the basic
> understanding. There is a steep learning curve for Kerberos tools and
> one needs basics before troubleshooting exposes the gory details ]
>
> The HTTP agent which is doing the Kerberos auth validation (eg Squid)
> must be configured with an account that can perform authentication tasks
> with the central domain server.
>  This can be either User or Machine account as you know. The important
> difference is their policy on passwords. User accounts need password
> rotation, machines are effectively permanent. Since keytab used by Squid
> has to be re-generated every time the account password changes User
> accounts are naturally far more complex to administrate for reliable auth.
>
>  => So ... your choice and YMMV. But we recommend a machine account
> unless you have reason to go the more complex way.
>
>
> At the other end the client software needs a keytab with a "Principal"
> name telling it what to request from the central domain server when it
> needs a token that Squid can validate.
>
>  => The principal name has to match up with the account details used by
> the proxy which is checking the auth credentials. This is why the middle
> proxy (eg HAProxy) cannot touch the authentication on its way to Squid.
>
>  => The principal name is also case-sensitive and and must survive
> *exact* string comparisons despite DNS resolve being involved [ because
> reasons :( ].  So be sure to use full FQDN rather than host name
> abbreviations.
>
>
>
> > I'll be back.
> >
> > El jue., 23 de jul. de 2020 a la(s) 13:16, Klaus Brandl escribió:
> >
> >     Hi Gabriel,
> >
> >     same problem here on our HA systems.
> >     I think, this is caused by kerberos overall, the tickets are always
> >     bound to
> >     the hosts realname and address, look at "klist" on your client, and
> >     only
> >     exactly this name could be used as proxy entry.
>
>
> Indeed. Use of wrong names (eg not using the full FQDN), wrong case, or
> the hostnames not being DNS resolvable are common causes of Kerberos not
> working.
>
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20200724/f18afcff/attachment.html>