z/OS Integrated Security Services Network Authentication Service Administration
z/OS Integrated Security Services Network Authentication Service Administration
Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Transitive trust z/OS Integrated Security Services Network Authentication Service Administration SC23-6786-00 |
|
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:
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:
A fully-connected hierarchy has, at a minimum, the following peer
trust relationships:
An additional peer trust relationship can be defined to shorten
the transited path between the lower layer of realms:
Do not include the top node in the trust hierarchy if there is
no need to obtain tickets for that realm. In the above example, IBM.COM
could be omitted and the peer trust relationships would then be the
following:
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:
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. 
|
 Copyright IBM Corporation 1990, 2014 |
