The problem lies more in the way how Kerberos proxy authentication works.
The client uses the proxy name to create a ticket and in this case it would
be the name of the first proxy e.g. proxy1.internal. The first proxy will
pass it through to the authenticating proxy for authentication
proxy2.internal. Now the client receiving a 407 thinks that proxy1 asked for
authentication (not knowing it is only a passthrough) and will ask for a
ticket for proxy1, which it can't get as proxy1 is not in AD. Even if
proxy1 would be in AD, the client would send a proxy1 ticket to proxy2 which
will be rejected.
Markus
"Amos Jeffries" wrote in message
news:ac36f75f-97c7-211e-a5bd-b12b7035ad0d@xxxxxxxxxxxxx...
On 12/10/21 9:33 pm, 森 隆聡 wrote:
I made Single Sign On environment with AD+Squid and it worked fine.
[It works]
Client(Windows) -> Squid(CentOS) -> Internet
* Client is joined the domain and Squid configured Kerberos Authentication
with AD.
But after add another squid, it didn't work.
...
Do I misundastand something or squid originally don't support
multiple proxy those relay Kerberos authentication information?
login=PASSTHRU means your Squid plays no part in the authentication. It
literally passes the peer the same Proxy-Auth* headers it receives from
the client, and the resulting response ones go back to the client.
Which means auth issues are a problem with either the client or server
software. Squid cannot do anything about those.
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
