Learn Kerberos - Cross-Realm Authentication

#Introduction

In episodes 0 through 9, you went through the entire authentication cycle within a single realm: one KDC, one set of policies, one collection of principals, and all tickets tracing back to a TGT issued by the same KDC. Episode 10 widens that horizon. This time you connect two independent Kerberos realms so that users from one realm can access services in the other realm without duplicate accounts and without logging in twice. This concept is called cross-realm authentication, and it is the foundation of inter-organization integration, corporate mergers, and even Active Directory forests.

#The Cross-Realm Concept

#Many Realms, One Trust

A realm is a trust boundary. Everything inside it — the KDC, principals, password policies, ticket lifetimes — is governed by a single authority. Cross-realm does not merge those realms; instead, it builds a bridge between them through a realm trust relationship: an agreement that realm A's KDC recognizes identities already verified by realm B's KDC, and vice versa. You don't need to replicate user accounts from realm B into realm A; with trust alone, tickets issued by realm B are accepted as proof of identity by realm A.

#Hierarchical Realms

Realms are often laid out following domain structure, much like DNS. EXAMPLE.COM can have a child CORP.EXAMPLE.COM, and CORP.EXAMPLE.COM can have a child LA.CORP.EXAMPLE.COM. In a hierarchical arrangement, the direction of trust follows this lineage, so policies can be managed cleanly at every level. This is the structure Active Directory uses to build domain trees.

#Transitive Trust

The transitive trust concept says: if realm A trusts realm B, and realm B trusts realm C, then realm A can reach realm C through realm B. However, note this well: in MIT Kerberos, transitivity does not happen by itself. Every hop still needs the appropriate cross-realm key, and the path through intermediate realms must be declared explicitly in [capaths]. Without that, a client only knows direct paths and gives up when no direct path exists.

#Trust Types

The difference between trust types is essentially about direction and topology:

#One-way Trust

In a one-way trust, users from realm B can access services in realm A, but not the other way around. This is the ideal pattern for vendors or partners: they keep full control over their own users, while you simply provide a one-way door.

#Two-way Trust

A two-way trust means both realms issue tickets for each other. This pattern is common in mergers, when two legacy companies keep their own realms but their employees must be able to work together. Behind the scenes, a two-way trust is simply two one-way trusts installed side by side.

#Hierarchical Trust

Hierarchical trust follows the domain structure, usually from a child realm to a parent realm. With this structure, trust policies can be inherited and managed centrally at each level — very suitable for large organizations with many realms.

#Direct Trust

Direct trust connects two realms without an intermediary. It is the simplest and fastest form of trust: one hop, one pair of cross-realm keys, and no dependency on other realms.

#Setting Up Cross-Realm

#Creating the Cross-Realm Principals

The key to cross-realm is a special pair of principals: krbtgt/REALM2@REALM1 on realm 1's KDC and krbtgt/REALM1@REALM2 on realm 2's KDC. Both hold the same shared secret — this is what makes realm 1's KDC trust that realm 2's KDC is a legitimate authority for realm 2.

sudo kadmin.local -q "addprinc -pw 'Shared-S3cret-CrossRealm-Am4n' krbtgt/REALM2.EXAMPLE.COM@REALM1.EXAMPLE.COM"

On realm 2's KDC, create its counterpart with the exact same password:

sudo kadmin.local -q "addprinc -pw 'Shared-S3cret-CrossRealm-Am4n' krbtgt/REALM1.EXAMPLE.COM@REALM2.EXAMPLE.COM"

#Sharing the Shared Secret

The principal names on both sides differ, but their keys must be identical. The same password produces the same key on both KDCs as long as the list of supported enctypes is also the same — a point that becomes very relevant in episode 11. An alternative for environments that don't want a password in the shell history: create with -randkey, export to a keytab with ktadd, then copy that keytab to the partner KDC over a secure channel.

sudo kadmin.local -q "ktadd -k /etc/krb5kdc/cross-realm.keytab krbtgt/REALM2.EXAMPLE.COM@REALM1.EXAMPLE.COM"
sudo scp /etc/krb5kdc/cross-realm.keytab root@kdc2.example.com:/etc/krb5kdc/

#Configuring capaths

[capaths] in krb5.conf draws the path map between realms. For a direct trust, capaths is actually optional — the KDC will issue referrals automatically. capaths becomes mandatory when the path is indirect, or when more than one path is possible so the client must know which path is correct.

Drawing the hierarchical path in /etc/krb5.conf

[capaths]
    LA.CORP.EXAMPLE.COM = {
        CORP.EXAMPLE.COM = {
            EXAMPLE.COM = .
        }
    }

Reading the block above: realm LA.CORP.EXAMPLE.COM reaches EXAMPLE.COM by transiting through CORP.EXAMPLE.COM. The dot in the innermost section marks the final hop as direct. Because every realm reads its own capaths, the same block should be aligned across all participating clients.

#Testing Cross-Realm Authentication

Once the principals and capaths are in place, test the path by requesting a ticket for the destination realm:

kinit budi@REALM1.EXAMPLE.COM
kvno host/server@REALM2.EXAMPLE.COM
klist

If kvno successfully retrieves a service ticket for host/server@REALM2.EXAMPLE.COM, then the whole chain — local TGT, referral ticket, and ticket from the destination KDC — is working. klist will show the sequence of tickets including the intermediate realm.

#Tracing the Trust Path

#Referral Tickets

When a user holding a TGT from realm 1 requests a service ticket for host/server@REALM2, realm 1's KDC doesn't recognize that service. Instead of rejecting outright, it checks the cross-realm key krbtgt/REALM2@REALM1. If it exists, realm 1's KDC issues a referral ticket — in essence a TGT for realm 2 encrypted with that cross-realm key. The client then uses it to talk to realm 2's KDC, which finally issues the actual service ticket. This is the mechanism behind the ticket that carries users across realms.

#Intermediate Realms and the Trust Chain

When there is no direct trust between the origin and destination realms, the client traces the trust chain hop by hop. From LA.CORP.EXAMPLE.COM, the client requests a referral to CORP.EXAMPLE.COM, then another referral from there to EXAMPLE.COM, and only then to the destination service. Each hop produces one cross-realm TGT, and they all link together into a chain. Every intermediate realm must have a cross-realm key to its neighbor, and the path must be known to the client via capaths.

#Path Optimization

The longer the chain, the more round trips and the more keys to hold. That's why path optimization is a recommended practice: use direct trust for realm pairs that communicate frequently, and keep chains short. [capaths] also serves to pick a path and avoid loops when more than one route exists — without capaths, a client might try a random route that ends in a dead end.

#Use Cases

Cross-realm solves problems that appear in almost every growing organization:

• Mergers & acquisitions — two companies keep their own realms and KDCs, then connect them with a two-way trust without rebuilding the entire directory.
• Partner organization access — a one-way trust gives partner users access to your services while closing the reverse direction.
• Multi-datacenter deployment — each data center can hold its own KDC and realm, linked by trust so a single KDC failure doesn't cripple the entire environment.
• Forest trusts (Active Directory) — when Windows speaks of forest trust, behind the scenes it's the Kerberos cross-realm mechanism with the krbtgt principal at work.

#Conclusion

In episode 10, you connected many realms: the trust boundary and trust relationship concepts, the one-way, two-way, hierarchical, and direct trust types; the krbtgt principal pair with a shared secret; the path map in capaths; how referral tickets work through intermediate realms; and real-world use cases from mergers to forest trusts.

Key takeaways:

• Cross-realm is a key pair — krbtgt/REALM2@REALM1 and its counterpart on the destination KDC must share an identical secret.
• Transitivity is not automatic — every hop needs a cross-realm key, and the path is declared in capaths.
• A referral ticket is a cross-realm TGT — the client traces the trust chain until the destination KDC issues the service ticket.
• kvno host/server@REALM2 is the quick test that proves a trust path works.

In the next episode, episode 11, we go into the detail that determines whether all of this succeeds: encryption types — how to choose modern AES enctypes, get rid of the weak DES and RC4, and align encryption capabilities across the entire realm.