The Kerberos Conundrum - A Proxy Servers Plight

This post talks about the complexities that creep in when a Proxy Server is introduced into an environment using Kerberos mode of authentication and also a potential generic solution.

Kerberos overview

Kerberos is an authentication mechanism between a client and server on a network using symmetric keys and tickets. Kerberos mode ensures that a password is not communicated across the network. A trusted third-party server — Key Distribution Centre (KDC) maintains all the keys of the participating components (client/server etc.). 

Kerberos authentication relies on several keys and key types for encryption.

The plain text password is transformed into a cryptographic key by passing the text of the password through a cryptographic function (salted/hashed etc.).

Usage of a Proxy server in Kerberos Authenticated environments

In an environment, which has a Proxy server configured, client requests are handled by the proxy and the proxy delegates requests to the Server. But if the authentication mechanism is expected to happen through Kerberos (since the ticket issued to the client is specific only to work with the final service) the proxy will not be able to read through the request nor act upon it. Similarly, the proxy cannot issue the request to end service, using the ticket issued to the client. 

This could be worked through by ensuring that the proxy service is also set up with a Service Principal, that the client tries to access. Once the client is authenticated, the proxy service forwards the request to the actual service, after authenticating itself to the Service. 

The above arrangement ensures that the client’s requests are handled well by the proxy even in the presence of Kerberos Authenticated environments. 

It is a common scenario that the proxy service could be interacting with some back-end data sources — databases, web services, reporting services or analytical services to serve the request. These data sources should be accessed as the original user so that proper authorization rules can be applied. That is, the identity of the user accessing the Proxy server, should be used as the identity of the user accessing the subsequent back-end data source. So, in cases where proxies are used, in Kerberos environments, final services may not get to see the actual user making the request. This scenario is also similar to the case where the request goes through a double hop, i.e., the client issues a request to a service and it in turn requests another service but needs to identify itself as the initiating client user.

Solution

There are different solutions for the above problem, varying with the kind of service being dealt with and the solution being very specific to the final targeted service. Let us consider here a solution which should be applicable for any kind of final targeted service. 

Usually the client forwards its Kerberos Keys or tokens –  Ticket Granting Ticket (TGT) and TGS session key to the service. If the client sends a forwardable TGT to the Proxy Server, then this TGT could be used by the proxy to communicate with upstream services thereby propagating the user identity in the request. 

This is called as Credential Delegation. 

Delegation refers to the facility for a service to impersonate an authenticated client in order to relieve the user of the additional burden of authenticating to multiple services. To the latter services it will look as if they are communicating directly with the user, whereas in reality another service will sit between them and the user.

Cases where this is not feasible:

• When the initial user authenticates to an intermediate service through non-Kerberos mode and subsequently the intermediate service should authenticate with Kerberos enabled services.
• End user cannot forward the TGT, session key or the proxy ticket.
• If there is a need to control the services to which intermediate service(proxy) can perform the delegation.

Constrained Delegation to the rescue

• Active Directory’s S4U2 Self & S4U2 Proxy Kerberos Extensions

Kerberos Extension — S4U2 Proxy

The S4U2Proxy Kerberos Extension allows a service to reuse a user's "service ticket" to request a new service ticket to the KDC. In other words, there is no more need to forward a user's TGT to the service. The simple fact that the service can present a user's ticket to a KDC is enough to prove a user's identity. 

The Service for User to Proxy (S4U2proxy) extension provides a service that obtains a service ticket to another service on behalf of a user. On Windows, this feature is known as constrained delegation. The second service is typically a proxy performing some work on behalf of the first service, and the proxy is doing that work under the authorization context of the user.

Kerberos Extension — S4U2 Self

The Server-for-User-to-Self (S4U2self) extension is intended to be used when the user authenticates to the service in some way other than by using Kerberos. For example, a user could authenticate to a web server by some means private to the web server. The web server could then use S4U2self to get a ticket, with authorization data, just as if the user had used Kerberos originally. This simplifies the server's authorization decision by making all decision paths behave as though Kerberos was used. S4U2self primarily uses the KDC to get information about the user for the caller's own benefit.

Conclusion

In the context of Kerberos authenticated environments, in cases where the obtained authentication token has to be passed onto subsequent selected services only, or if the obtained token is not explicitly marked as a forwardable token or the initial user authentication process is not through Kerberos but the subsequent services rely on Kerberos authenticated tokens, features such as Constrained Delegation and Kerberos extensions S4U2Self/S4U2Proxy could be used.