Squid as Kerberos client?

Squid as Kerberos client?

Hello list,

We are in the process of Kerberizing our Big Data operation, but we have a GUI tool in use that is not capable of Kerberos authentication. I'm looking for a way to keep using it, which means that it needs to read data from a Kerberos-protected service.

To be clear, I'm looking for a proxy that will take care of the authentication so that our GUI tool does not need to know. It should "enrich" the client's "dumb" request to an authenticated request. This lowers security of course, but I will use other means to make sure that only that app can talk to the proxy on the network.

Re: Squid as Kerberos client?

Hi,

Easy going, you can allow traffic from a specific source or traffic to a specific destination before you require authentication on the proxy. You can also restrict it to both, src and destination and additionaly specific ports. But squid cannot authenticate those requests on the destination server if it needs authentication as well.

We are in the process of Kerberizing our Big Data operation, but we have a GUI tool in use that is not capable of Kerberos authentication. I'm looking for a way to keep using it, which means that it needs to read data from a Kerberos-protected service.

To be clear, I'm looking for a proxy that will take care of the authentication so that our GUI tool does not need to know. It should "enrich" the client's "dumb" request to an authenticated request. This lowers security of course, but I will use other means to make sure that only that app can talk to the proxy on the network.

Easy going, you can allow traffic from a specific source or traffic to a specific destination before you require authentication on the proxy. You can also restrict it to both, src and destination and additionaly specific ports. But squid cannot authenticate those requests on the destination server if it needs authentication as well.

We are in the process of Kerberizing our Big Data operation, but we have a GUI tool in use that is not capable of Kerberos authentication. I'm looking for a way to keep using it, which means that it needs to read data from a Kerberos-protected service.

To be clear, I'm looking for a proxy that will take care of the authentication so that our GUI tool does not need to know. It should "enrich" the client's "dumb" request to an authenticated request. This lowers security of course, but I will use other means to make sure that only that app can talk to the proxy on the network.

Easy going, you can allow traffic from a specific source or traffic to a specific destination before you require authentication on the proxy. You can also restrict it to both, src and destination and additionaly specific ports. But squid cannot authenticate those requests on the destination server if it needs authentication as well.

We are in the process of Kerberizing our Big Data operation, but we have a GUI tool in use that is not capable of Kerberos authentication. I'm looking for a way to keep using it, which means that it needs to read data from a Kerberos-protected service.

To be clear, I'm looking for a proxy that will take care of the authentication so that our GUI tool does not need to know. It should "enrich" the client's "dumb" request to an authenticated request. This lowers security of course, but I will use other means to make sure that only that app can talk to the proxy on the network.

Easy going, you can allow traffic from a specific source or traffic to a specific destination before you require authentication on the proxy. You can also restrict it to both, src and destination and additionaly specific ports. But squid cannot authenticate those requests on the destination server if it needs authentication as well.

We are in the process of Kerberizing our Big Data operation, but we have a GUI tool in use that is not capable of Kerberos authentication. I'm looking for a way to keep using it, which means that it needs to read data from a Kerberos-protected service.

To be clear, I'm looking for a proxy that will take care of the authentication so that our GUI tool does not need to know. It should "enrich" the client's "dumb" request to an authenticated request. This lowers security of course, but I will use other means to make sure that only that app can talk to the proxy on the network.

But now squid still does not do the SPNEGO negotiation. I can see in the logs that it connects to the specified "parent" cache_peer, which returns "401 Unauthorized" as expected. But then squid just returns that to the client instead of sending another request with the Kerberos ticket to complete the negotiation.

Am I misunderstanding what's supposed to happen?

Or am I not configuring it right? (The keytab is readable by the squid user)

Re: Squid as Kerberos client?

Thank you. It doesn't seem that the "originserver" makes a difference to may case though.

I was able to resolve my issue after I understood that I forgot to pay attention to cookies. The API expects the client to use cookies, which I didn't do until now, which resulted in a continuous "401 Unauthorized" loop.

Re: Squid as Kerberos client?

Administrator

On 17/03/18 06:41, Patrick Nick wrote:
> Thank you. It doesn't seem that the "originserver" makes a difference to
> may case though.
>
> I was able to resolve my issue after I understood that I forgot to pay
> attention to cookies. The API expects the client to use cookies, which I
> didn't do until now, which resulted in a continuous "401 Unauthorized" loop.
>

Ah, Cookies. The bane of the Internet. They can be dealt with, but you
are not going to like the difficulty level.

Your choices AFAIK (in order of easiest to seriously tricky) are to
write an eCAP module, ICAP service, or custom external ACL helper(s)
with fairly complex squid.conf settings to use the latter.

On 17/03/18 06:41, Patrick Nick wrote:
> Thank you. It doesn't seem that the "originserver" makes a difference to
> may case though.
>
> I was able to resolve my issue after I understood that I forgot to pay
> attention to cookies. The API expects the client to use cookies, which I
> didn't do until now, which resulted in a continuous "401 Unauthorized" loop.
>

Ah, Cookies. The bane of the Internet. They can be dealt with, but you
are not going to like the difficulty level.

Your choices AFAIK (in order of easiest to seriously tricky) are to
write an eCAP module, ICAP service, or custom external ACL helper(s)
with fairly complex squid.conf settings to use the latter.