Transitive trust

In a transitive trust relationship, two realms trust each other if they trust the intermediate realms involved in granting a ticket. Kerberos transitive trust is based upon a hierarchical trust path between the ticket client and the ticket server. The components in the trust path are formed by using periods to separate the realm name into its constituent parts. The common portion between the two realm names forms the top ancestor in the trust path.

For example, if the client is in realm SSTONE1.KRB2000.IBM.COM and the server is in realm DCESEC4.KRB390.IBM.COM, the trust path consists of the following entries:
  • SSTONE1.KRB2000.IBM.COM
  • KRB2000.IBM.COM
  • IBM®.COM
  • KRB390.IBM.COM
  • DCESEC4.KRB390.IBM.COM

If each realm involved in granting the service ticket is present in the trust path, then the ticket is trusted.

When attempting to obtain a service ticket, the Kerberos runtime starts with the client realm and attempts to obtain a TGT for the server realm. If the KDC for the client realm is unable to satisfy the request because there is no peer trust relationship between the client and server realms, the Kerberos runtime attempts to obtain a TGT to a realm that is in the trust path between the client and the server realms. As soon as it obtains a TGT to an intermediate realm, it tries to obtain a TGT to the server realm from the intermediate KDC. This process is repeated until either a server realm TGT is obtained or all of the intermediate realms have been tried.

When setting up transitive trust, a peer trust relationship should be defined between each realm and a common ancestor realm in the hierarchy. For example, consider the following realm tree:
  • IBM.COM (Top node)
  • KRB390.IBM.COM (First level node)
  • DCESEC4.KRB390.IBM.COM (Second level node)
  • DCESEC7.KRB390.IBM.COM (Second level node)
  • KRB2000.IBM.COM (First level node)
  • SSTONE1.KRB2000.IBM.COM (Second level node)
  • SSTONE2.KRB2000.IBM.COM (Second level node)
A fully-connected hierarchy has, at a minimum, the following peer trust relationships:
  • DCESEC4.KRB390.IBM.COM <--> KRB390.IBM.COM
  • DCESEC7.KRB390.IBM.COM <--> KRB390.IBM.COM
  • KRB390.IBM.COM <--> IBM.COM
  • KRB2000.IBM.COM <--> IBM.COM
  • SSTONE1.KRB2000.IBM.COM <--> KRB2000.IBM.COM
  • SSTONE2.KRB2000.IBM.COM <--> KRB2000.IBM.COM
An additional peer trust relationship can be defined to shorten the transited path between the lower layer of realms:
  • KRB390.IBM.COM <--> KRB2000.IBM.COM
Do not include the top node in the trust hierarchy if there is no need to obtain tickets for that realm. In the preceding example, IBM.COM could be omitted and the peer trust relationships would then be the following:
  • DCESEC4.KRB390.IBM.COM <--> KRB390.IBM.COM
  • DCESEC7.KRB390.IBM.COM <--> KRB390.IBM.COM
  • KRB390.IBM.COM <--> KRB2000.IBM.COM
  • SSTONE1.KRB2000.IBM.COM <--> KRB2000.IBM.COM
  • SSTONE2.KRB2000.IBM.COM <--> KRB2000.IBM.COM
Similarly, a lopsided trust hierarchy can be defined. Suppose there is no need to obtain tickets to the IBM.COM or KRB2000.IBM.COM realms. The peer trust relationships would then be the following:
  • DCESEC4.KRB390.IBM.COM <--> KRB390.IBM.COM
  • DCESEC7.KRB390.IBM.COM <--> KRB390.IBM.COM
  • SSTONE1.KRB2000.IBM.COM <--> KRB390.IBM.COM
  • SSTONE2.KRB2000.IBM.COM <--> KRB390.IBM.COM

When defining the transitive trust hierarchy, it is important to remember that the peer trust relationships must be symmetric (tickets can be obtained when traversing the trust path in either direction) and each realm in a peer trust relationship must be capable of either providing a TGT for the destination realm or for an intermediate realm which is further along the trust path between the client and the server realms.