Blog | G5 Cyber Security

Kerberos Delegation: Proxying to the KDC

G5 Cyber Security

TL;DR

No, a Kerberos application server cannot directly proxy connections to the Key Distribution Center (KDC). The KDC is the central authority and doesn’t accept proxied connections in the same way an application server might. However, application servers can use delegation to obtain tickets on behalf of users for other services, effectively acting as a proxy *for* those services, not the KDC itself.

Understanding Kerberos and Proxies

Kerberos works by issuing tickets that grant access to resources. The KDC issues these tickets. An application server typically requests a ticket-granting ticket (TGT) for a user, then uses that TGT to request service tickets for other services the user needs. A proxy isn’t used to connect *to* the KDC; it’s used to access resources using tickets obtained from the KDC.

Why You Can’t Proxy Directly to the KDC

  1. KDC Role: The KDC is a security authority. Allowing direct proxies would create significant security risks, bypassing authentication and authorization mechanisms.
  2. Protocol Design: Kerberos protocol doesn’t support application servers directly proxying connections to the KDC. Communication with the KDC is typically initiated by the client (user or service).

How Delegation Works (Acting as a Proxy)

Delegation allows an application server to obtain tickets for other services on behalf of a user. This is how you achieve proxy-like functionality.

  1. Configure Delegation: You need to configure the application server to use delegation. This involves setting appropriate flags in the Kerberos configuration file (krb5.conf) and potentially using service principal names (SPNs).
  2. Request a Delegatable Ticket: When requesting a TGT, specify that it should be delegatable. The exact method depends on your Kerberos implementation. For example, with kinit you might use the -t option to specify a keytab and ensure the principal is configured for delegation.
  3. Obtain Service Tickets: The application server uses the TGT to request service tickets for other services on behalf of the user. These tickets are then used to access those resources.

Example (Conceptual)

Let’s say you have an application server ‘appserver’ and a database server ‘dbserver’. A user wants to access the database through appserver.

  1. The user authenticates with appserver.
  2. Appserver requests a TGT for the user, requesting delegation.
  3. Appserver uses the TGT to request a service ticket for dbserver on behalf of the user.
  4. Appserver presents the service ticket to dbserver to access the database.

Configuration Snippets (Illustrative)

These are examples and will vary based on your Kerberos distribution.

krb5.conf (Example Delegation Setting)

[libdefaults]
  default_tkt_enctypes = rc4-hmac
  default_tgs_enctypes = rc4-hmac
  allow_weak_crypto = true

SPN Configuration (Example)

Using setspn to register the SPN for appserver:

setspn -A HTTP/appserver.example.com appserver
setspn -A HOST/appserver.example.com appserver

Important Considerations

Exit mobile version