The simplest case is having two realms cross-realm authenticate with each
other. To do this, you need to create two special cross-realm principals on
each KDC:

   * krbtgt/REALM2@REALM1
   * krbtgt/REALM1@REALM2

The keys of the corresponding principals have to match on the two KDCs, but
the different cross-realm principals don't have to have matching keys. In
other words, krbtgt/REALM2@REALM1 has to have the same key on each KDC, but
krbtgt/REALM2@REALM1 and krbtgt/REALM1@REALM2 don't have to match.

Another important point is that the corresponding kvnos have to match up as
well.

When clients want to connect to a server in another realm, they will use
their current TGT to get a cross-realm TGT from the local KDC. They will
then use that cross-realm TGT to request service tickets from the foreign
KDC.

Two principals are needed for each direction of the authentication path
(REALM1 to REALM2, and vice versa). When a client in REALM1 wishes to talk
to a server in REALM2, it uses the krbtgt/REALM2@REALM1 TGT. Note that this
is different than the procedure in V4, where only one cross realm secret was
created (krbtgt.FOREIGN-REALM@LOCAL-REALM) and used for both directions.

Since each principal corresponds to the different authentication paths, if
you only want one-way cross-realm authentication you can simply only create
one of the cross-realm principals.

V5 also supports transitive cross-realm, which lets you define
authentication paths between different KDCs so you don't have to share as
many keys. The difference is O(n**2) versus O(2**n), so depending on the
number of realms you plan on working with, it can make a big difference on
the number of keys you have to manage.

There are two ways to organize your transitive cross-realm authentication
paths: hierarchical and [capaths].

Hierarchical cross-realm authentication is fairly simple. Your realms must
be organized in a hierarchy almost identical to DNS domain names, and
clients magically "know" to traverse up the realm tree to talk to neighbors.
For example, if you have the realms:

   * FOO.ORG
   * BAR.FOO.ORG
   * BIZ.FOO.ORG
   * BLAH.FOO.ORG

You would have the BAR, BIZ, and BLAH sub-realms each share a cross-realm
key with the parent FOO.ORG realm, and all of the clients and application
servers would do the right things without any extra work on your part.

One thing to be careful of is that there is an implied trust when doing
hierarchical cross-realm. If you create a new realm in the above hierarchy
called BLARGH.FOO.ORG and have it share a cross-realm key with the parent
FOO.ORG realm, then all of your realms will implicitly trust cross-realm
tickets from this realm, and that may not be what you want (depending on
your environment).

The other way to do transitive cross-realm is to use the [capaths] section
of the Kerberos configuration file. The krb5.conf man page explains the
format of this section fairly well, so I'll only cover the the concepts
here.

The [capaths] section defines a series of authentication paths to use when
doing transitive cross-realm. This is used by the clients to determine the
correct path for doing transitive cross-realm, and by the application
servers to determine that a cross-realm authentication path is actually
valid.

Since each application server verifies authentication paths using this
section, the addition of a new path to one realm does not assign any
implicit trust to the other realms. The downside is that the krb5.conf file
must be updated on every host when a new authentication path is created.