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.
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:
[capaths] 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
.
[capaths] 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.
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
).
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:
[capaths] ENGR.WIN.EXAMPLE.COM = { EXAMPLE.COM = WIN.EXAMPLE.COM } SALES.WIN.EXAMPLE.COM = { EXAMPLE.COM = WIN.EXAMPLE.COM } EXAMPLE.COM = { ENGR.WIN.EXAMPLE.COM = WIN.EXAMPLE.COM SALES.WIN.EXAMPLE.COM = WIN.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.