Kerberos Cross-Realm Trust

Luke Hebert

- 2 minutes read - 213 words

Cross-realm authentication in Kerberos is handled entirely through TGS (Ticket-Granting Service) messages. No special protocol is needed beyond the standard ticket exchange flow. The three-step process below shows exactly how a user in one realm reaches a service in another, and where things break when the trust is misconfigured.

The Three-Step Ticket Flow

  1. User foo obtains a TGT for krbtgt/LOCAL@LOCAL. The session key is encrypted with the user’s long-term secret (password) and the long-term key for krbtgt/LOCAL@LOCAL. This is the initial AS exchange.

  2. User foo requests a ticket for krbtgt/LOCAL@REMOTE. The session key is encrypted using both the long-term secret for krbtgt/LOCAL@REMOTE (which both the LOCAL and REMOTE KDCs share) and the session key from the krbtgt/LOCAL@LOCAL ticket. Note: the user is still talking to the LOCAL KDC here, via a TGS exchange.

  3. User foo requests a service ticket for service/remote.host@REMOTE. The session key is encrypted with the session key from krbtgt/LOCAL@REMOTE and the service’s long-term key. For this step, the user talks to the REMOTE KDC (another TGS exchange).

Key Takeaway

The shared secret between the two KDCs (the krbtgt key) is what bridges the trust. If that key is out of sync or the trust relationship is misconfigured, step 2 will fail and the user will never reach the remote service.