Next: , Previous: Cross realm, Up: Setting up a realm

4.14 Transit policy

Under some circumstances, you may not wish to set up direct cross-realm trust with every realm to which you wish to authenticate or from which you wish to accept authentications. Kerberos supports multi-hop cross-realm trust where a client principal in realm A authenticates to a service in realm C through a realm B with which both A and C have cross-realm trust relationships. In this situation, A and C need not set up cross-realm principals between each other.

If you want to use cross-realm authentication through an intermediate realm, it must be explicitly allowed by either the KDCs for the realm to which the client is authenticating (in this case, realm C), or the server receiving the request. This is done in krb5.conf in the [capaths] section.

In addition, the client in realm A need to be configured to know how to reach realm C via realm B. This can be done either on the client or via KDC configuration in the KDC for realm A.

4.14.1 Allowing cross-realm transits

When the ticket transits through a realm to another realm, the destination realm adds its peer to the "transited-realms" field in the ticket. The field is unordered, since there is no way to know if know if one of the transited-realms changed the order of the list. For the authentication to be accepted by the final destination realm, all of the transited realms must be listed as trusted in the [capaths] configuration, either in the KDC for the destination realm or on the server receiving the authentication.

The syntax for [capaths] section is:

             CLIENT-REALM = {
                     SERVER-REALM = PERMITTED-CROSS-REALMS ...

In the following example, the realm STACKEN.KTH.SE only has direct cross-realm set up with KTH.SE. KTH.SE has direct cross-realm set up with STACKEN.KTH.SE and SU.SE. DSV.SU.SE only has direct cross-realm set up with SU.SE. The goal is to allow principals in the DSV.SU.SE or SU.SE realms to authenticate to services in STACKEN.KTH.SE. This is done with the following [capaths] entry on either the server accepting authentication or on the KDC for STACKEN.KTH.SE.

     	SU.SE = {
                         STACKEN.KTH.SE = KTH.SE
     	DSV.SU.SE = {
                         STACKEN.KTH.SE = SU.SE KTH.SE

The first entry allows cross-realm authentication from clients in SU.SE transiting through KTH.SE to STACKEN.KTH.SE. The second entry allows cross-realm authentication from clients in DSV.SU.SE transiting through both SU.SE and KTH.SE to STACKEN.KTH.SE.

Be careful of which realm goes where; it's easy to put realms in the wrong place. The block is tagged with the client realm (the realm of the principal authenticating), and the realm before the equal sign is the final destination realm: the realm to which the client is authenticating. After the equal sign go all the realms that the client transits through.

The order of the PERMITTED-CROSS-REALMS is not important when doing transit cross realm verification.

4.14.2 Configuring client cross-realm transits

The [capaths] section is also used for another purpose: to tell clients which realm to transit through to reach a realm with which their local realm does not have cross-realm trust. This can be done by either putting a [capaths] entry in the configuration of the client or by putting the entry in the configuration of the KDC for the client's local realm. In the latter case, the KDC will then hand back a referral to the client when the client requests a cross-realm ticket to the destination realm, telling the client to try to go through an intermediate realm.

For client configuration, the order of PERMITTED-CROSS-REALMS is significant, since only the first realm in this section (after the equal sign) is used by the client.

For example, again consider the [capaths] entry above for the case of a client in the SU.SE realm, and assume that the client or the SU.SE KDC has that [capaths] entry. If the client attempts to authenticate to a service in the STACKEN.KTH.SE realm, that entry says to first authenticate cross-realm to the KTH.SE realm (the first realm listed in the PERMITTED-CROSS-REALMS section), and then from there to STACKEN.KTH.SE.

Each entry in [capaths] can only give the next hop, since only the first realm in PERMITTED-CROSS-REALMS is used. If, for instance, a client in DSV.SU.SE had a [capaths] configuration as above but without the first block for SU.SE, they would not be able to reach STACKEN.KTH.SE. They would get as far as SU.SE based on the DSV.SU.SE entry in [capaths] and then attempt to go directly from there to STACKEN.KTH.SE and get stuck (unless, of course, the SU.SE KDC had the additional entry required to tell the client to go through KTH.SE).

4.14.3 Active Directory forest example

One common place where a [capaths] configuration is desirable is with Windows Active Directory forests. One common Active Directory configuration is to have one top-level Active Directory realm but then divide systems, services, and users into child realms (perhaps based on organizational unit). One generally establishes cross-realm trust only with the top-level realm, and then uses transit policy to permit authentications to and from the child realms.

For example, suppose an organization has a Heimdal realm EXAMPLE.COM, a Windows Active Directory realm WIN.EXAMPLE.COM, and then child Active Directory realms ENGR.WIN.EXAMPLE.COM and SALES.WIN.EXAMPLE.COM. The goal is to allow users in any of these realms to authenticate to services in any of these realms. The EXAMPLE.COM KDC (and possibly client) configuration should therefore contain a [capaths] section as follows:

     	EXAMPLE.COM = {

The first two blocks allow clients in the ENGR.WIN.EXAMPLE.COM and SALES.WIN.EXAMPLE.COM realms to authenticate to services in the EXAMPLE.COM realm. The third block tells the client (or tells the KDC to tell the client via referrals) to transit through WIN.EXAMPLE.COM to reach these realms. Both sides of the configuration are needed for bi-directional transited cross-realm authentication.