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
