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