Using proxy servers is already one level more complicated than regular Internet usage. But adding a Kerberos authenticated environment into the mix just makes it even more complex. If this is something that you need to do in your organization, you may wish to know more about how it works and what are the implications involved. Let us get right into the matter.
What Is Kerberos?
Kerberos is an authentication mechanism between a client and server on a network which uses symmetric keys and tickets. In Kerberos mode, passwords are encrypted and hence prevented from being communicated across the network. Instead, a trusted third-party server, or Key Distribution Centre, maintains all the keys of the participating components, e.g. the client and server. Kerberos authentication relies on several different keys and key types for its encryption purposes. From the plain text password, a cryptographic key is created by passing the text through a cryptographic function which changes the letters to symbols via salting or hashing.
Complications When Using A Proxy Server With Kerberos
When using a proxy server, client requests are handled by the proxy, which then delegates requests through the server. But if Kerberos is activated, the proxy will not be able to read the request or act upon it. The proxy also cannot issue the request to end the service using the ticket issued to the client, since the ticket issued to the client is specifically meant to work only with the final service, which is Kerberos.
One way of getting around this issue is to make sure the proxy service as well as the client are set up with a Service Principal. Once both of these are authenticated with the Service Principal, the proxy service would therefore be able to forward the client request to the actual service. This ensures the client’s requests are handled well by the proxy, even in Kerberos authenticated environments.
Typically, a proxy service could be interacting with back-end data sources such as databases, web services, reporting services or analytical services, in order to serve the client request. It is best that these back-end sources are accessed as the same user accessing the proxy server, so that proper authorization rules can be applied. However, if this is the case, final services may not get to see the actual user making the initial request, which can be confusing.
How To Get Around The Problem
While there are different solutions to this issue, let us look at one which should be generally applicable, known as Credential Delegation. Essentially, the client forwards its Kerberos keys or tokens to the services. If the client sends a forwardable ticket to the proxy server, this ticket could be used by the proxy to communicate with other services further down, which communicates the user identity in the service request.
There is so much to learn about using proxy keys. If you’re thirsty for more information, do visit Proxy Key’s knowledge base with informative articles for you to learn from. And if you still have questions, don’t hesitate to contact our friendly customer service who would be happy to help!