Red Hat ENTERPRISE LINUX 5 - DEPLOYMENT Deployment Manual page 704

Chapter 43. Securing Your Network
Clients in the 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.
This brings us to an important point: cross-realm trust is unidirectional by default. The KDC for the
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).
If direct trust relationships were the only method for providing trust between realms, networks which
contain multiple realms would be very difficult to set up. Luckily, cross-realm trust is transitive. If
clients from 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.
Now you face the more conventional problems: the client's system must be configured so that it can
properly deduce the realm to which a particular service belongs, and it must be able to determine how
to obtain credentials for services in that realm.
First things first: the principal name for a service provided from a specific server system in a given
realm typically looks like this:
service/server.example.com@EXAMPLE.COM
In this example, service is typically either the name of the protocol in use (other common values
include ldap, imap, cvs, and HTTP) or host, server.example.com is the fully-qualified domain name of
the system which runs the service, and EXAMPLE.COM is the name of the realm.
To deduce the realm to which the service belongs, clients will most often consult DNS or the
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).
Having determined which to which realm a service belongs, a client then has to determine the set of
realms which it needs to contact, and in which order it must contact them, to obtain credentials for use
in authenticating to the service.
This can be done in one of two ways.
The default method, which requires no explicit configuration, is to give the realms names within a
shared hierarchy. For an example, assume realms named 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.
The client in this scenario treats the realm name as one might treat a DNS name. It repeatedly strips
off the components of its own realm's name to generate the names of realms which are "above" it in
the hierarchy until it reaches a point which is also "above" the service's realm. At that point it begins
prepending components of the service's realm name until it reaches the service's realm. Each realm
which is involved in the process is another "hop".
678