A.EXAMPLE.COM
to access a service in the B.EXAMPLE.COM
realm, both realms must share a key for a principal named krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
, and both keys must have the same key version number associated with them.
#
kadmin -r A.EXAMPLE.COM
kadmin:
add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created.
quit
#
kadmin -r B.EXAMPLE.COM
kadmin:
add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created.
quit
get_principal
command to verify that both entries have matching key version numbers (kvno
values) and encryption types.
Dumping the Database Doesn't Do It
add_principal
command's -randkey
option to assign a random key instead of a password, dump the new entry from the database of the first realm, and import it into the second. This will not work unless the master keys for the realm databases are identical, as the keys contained in a database dump are themselves encrypted using the master key.
A.EXAMPLE.COM
realm are now able to authenticate to services in the B.EXAMPLE.COM
realm. Put another way, the B.EXAMPLE.COM
realm now trusts the A.EXAMPLE.COM
realm, or phrased even more simply, B.EXAMPLE.COM
now trusts A.EXAMPLE.COM
.
B.EXAMPLE.COM
realm may trust clients from the A.EXAMPLE.COM
to authenticate to services in the B.EXAMPLE.COM
realm, but the fact that it does has no effect on whether or not clients in the B.EXAMPLE.COM
realm are trusted to authenticate to services in the A.EXAMPLE.COM
realm. To establish trust in the other direction, both realms would need to share keys for the krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM
service (take note of the reversed in order of the two realms compared to the example above).
A.EXAMPLE.COM
can authenticate to services in B.EXAMPLE.COM
, and clients from B.EXAMPLE.COM
can authenticate to services in C.EXAMPLE.COM
, then clients in A.EXAMPLE.COM
can also authenticate to services in C.EXAMPLE.COM
, even if C.EXAMPLE.COM
doesn't directly trust A.EXAMPLE.COM
. This means that, on a network with multiple realms which all need to trust each other, making good choices about which trust relationships to set up can greatly reduce the amount of effort required.
service/server.example.com@EXAMPLE.COM
EXAMPLE.COM
is the name of the realm.
domain_realm
section of /etc/krb5.conf
to map either a hostname (server.example.com) or a DNS domain name (.example.com) to the name of a realm (EXAMPLE.COM).
A.EXAMPLE.COM
, B.EXAMPLE.COM
, and EXAMPLE.COM
. When a client in the A.EXAMPLE.COM
realm attempts to authenticate to a service in B.EXAMPLE.COM
, it will, by default, first attempt to get credentials for the EXAMPLE.COM
realm, and then to use those credentials to obtain credentials for use in the B.EXAMPLE.COM
realm.
A.EXAMPLE.COM
, authenticating to a service in B.EXAMPLE.COM
A.EXAMPLE.COM → EXAMPLE.COM → B.EXAMPLE.COM
A.EXAMPLE.COM
and EXAMPLE.COM
share a key for krbtgt/EXAMPLE.COM@A.EXAMPLE.COM
EXAMPLE.COM
and B.EXAMPLE.COM
share a key for krbtgt/B.EXAMPLE.COM@EXAMPLE.COM
SITE1.SALES.EXAMPLE.COM
, authenticating to a service in EVERYWHERE.EXAMPLE.COM
SITE1.SALES.EXAMPLE.COM → SALES.EXAMPLE.COM → EXAMPLE.COM → EVERYWHERE.EXAMPLE.COM
SITE1.SALES.EXAMPLE.COM
and SALES.EXAMPLE.COM
share a key for krbtgt/SALES.EXAMPLE.COM@SITE1.SALES.EXAMPLE.COM
SALES.EXAMPLE.COM
and EXAMPLE.COM
share a key for krbtgt/EXAMPLE.COM@SALES.EXAMPLE.COM
EXAMPLE.COM
and EVERYWHERE.EXAMPLE.COM
share a key for krbtgt/EVERYWHERE.EXAMPLE.COM@EXAMPLE.COM
DEVEL.EXAMPLE.COM
and PROD.EXAMPLE.ORG
DEVEL.EXAMPLE.COM → EXAMPLE.COM → COM → ORG → EXAMPLE.ORG → PROD.EXAMPLE.ORG
DEVEL.EXAMPLE.COM
and EXAMPLE.COM
share a key for krbtgt/EXAMPLE.COM@DEVEL.EXAMPLE.COM
EXAMPLE.COM
and COM
share a key for krbtgt/COM@EXAMPLE.COM
COM
and ORG
share a key for krbtgt/ORG@COM
ORG
and EXAMPLE.ORG
share a key for krbtgt/EXAMPLE.ORG@ORG
EXAMPLE.ORG
and PROD.EXAMPLE.ORG
share a key for krbtgt/PROD.EXAMPLE.ORG@EXAMPLE.ORG
capaths
section of /etc/krb5.conf
, so that clients which have credentials for one realm will be able to look up which realm is next in the chain which will eventually lead to the being able to authenticate to servers.
capaths
section is relatively straightforward: each entry in the section is named after a realm in which a client might exist. Inside of that subsection, the set of intermediate realms from which the client must obtain credentials is listed as values of the key which corresponds to the realm in which a service might reside. If there are no intermediate realms, the value "." is used.
[capaths]
A.EXAMPLE.COM = {
B.EXAMPLE.COM = .
C.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = C.EXAMPLE.COM
}
A.EXAMPLE.COM
realm can obtain cross-realm credentials for B.EXAMPLE.COM
directly from the A.EXAMPLE.COM
KDC.
C.EXAMPLE.COM
realm, they will first need to obtain necessary credentials from the B.EXAMPLE.COM
realm (this requires that krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
exist), and then use those
credentials to obtain credentials for use in the C.EXAMPLE.COM
realm (using krbtgt/C.EXAMPLE.COM@B.EXAMPLE.COM
).
D.EXAMPLE.COM
realm, they will first need to obtain necessary credentials from the B.EXAMPLE.COM
realm, and then credentials from the C.EXAMPLE.COM
realm, before finally obtaining credentials for use with the D.EXAMPLE.COM
realm.
Note
A.EXAMPLE.COM
realm can obtain cross-realm credentials from B.EXAMPLE.COM
realm directly. Without the "." indicating this, the client would instead attempt to use a hierarchical path, in this case:
A.EXAMPLE.COM → EXAMPLE.COM → B.EXAMPLE.COM