On 10/17/21 10:57 AM, Grant Taylor wrote:
My understanding is that you can use Kerberos from clinet0 to proxy1 and
that proxy1 can use the same mechanism to get a special ticket to
communicate from proxy1 to proxy2 as the original user.
I looked at my copy of Kerberos - The Definitive Guide by
On 10/17/21 10:46 AM, Markus Moeller wrote:
I see, I think this would mean using Basic Auth to proxy1 which then
gets a Kerberos ticket for the user to authenticate to proxy2. This is
possible, but I would not think it is a good secure option.
I think that we're now talking about the same fu
I see, I think this would mean using Basic Auth to proxy1 which then gets a
Kerberos ticket for the user to authenticate to proxy2. This is possible,
but I would not think it is a good secure option.
Regards
Markus
"Grant Taylor" wrote in message
news:a2070fca-07fd-9a67-3f23-551c1fe77...@s
On 10/16/21 1:31 PM, Markus Moeller wrote:
I think you talk about a kdc proxy, which is for another case.
I don't think so. I'm not talking about using a proxy to access the KDC.
I'm talking about using a component of the following scenario:
1) Client uses traditional username and password
Hi Amos,
If you let me know where exactly I can add a few lines.
One way to make this setup work would be to add proxy1 also to AD like
proxy2 and then merge the keytab for proxy1 into the keytab of proxy2 using
ktutil. The negotiate_kerberos_auth handle would require the -s
GSS_C_NO_NAME
I think you talk about a kdc proxy, which is for another case.
Regards
Markus
"Grant Taylor" wrote in message
news:b815528d-34ff-0fed-3194-dc6f34199...@spamtrap.tnetconsulting.net...
On 10/13/21 1:48 PM, Markus Moeller wrote:
The problem lies more in the way how Kerberos proxy authenticatio
On 10/13/21 1:48 PM, Markus Moeller wrote:
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 auth
On 14/10/21 8:48 am, Markus Moeller wrote:
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 aut
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.
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.
...
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.
[Not works]
Client -> Squid(No Auth.) ->
11 matches
Mail list logo
