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