Ticket History #2559: Replacement Text Explaining [capaths] for Admin Guide

[capaths]

In order to perform direct (non-hierarchical) cross-realm authentication,
a database is needed to specify the authentication paths between the
various source and destination realms. This section defines the database.

The database is used for different purposes by a Kerberos client and
a Kerberos server (kdc and application server). The client uses the
capaths to determine the authentication path between the client principal
realm and the realm of the server, The server verifies the the transited
field of the ticket received from the client against this database.

The database defines for each source and destination pair an ordered list
of intermediary realms which represent cross realm relationships. The
authentication paths specified in the database are unidirectional.
Each direction of a bidirectional path must be specified separately.

The best way to explain how to construct the database is to show by example.
The realms ANL.GOV, PNL.GOV, and NERSC.GOV all wish to use the ES.NET realm
as an intermediate realm. TEST.ANL.GOV is a sub realm of ANL.GOV which must
authenticate with NERSC.GOV but not PNL.GOV.


NERSC.GOV
/
/
TEST.ANL.GOV -- ANL.GOV -- ES.NET
\
\
PNL.GOV


Enumerating the desired relationships results in the following table.


Client Service
Principal Intermediary Principal
Realm Realms Realm
----------------------------------------------------------
ANL.GOV TEST.ANL.GOV
ANL.GOV ES.NET PNL.GOV
ANL.GOV ES.NET NERSC.GOV
ANL.GOV ES.NET
TEST.ANL.GOV ANL.GOV
TEST.ANL.GOV ANL.GOV ES.NET
TEST.ANL.GOV ANL.GOV ES.NET NERSC.GOV
PNL.GOV ES.NET
PNL.GOV ES.NET ANL.GOV
PNL.GOV ES.NET NERSC.GOV
NERSC.GOV ES.NET
NERSC.GOV ES.NET PNL.GOV
NERSC.GOV ES.NET ANL.GOV
NERSC.GOV ES.NET ANL.GOV TEST.ANL.GOV
ES.NET ANL.GOV
ES.NET ANL.GOV TEST.ANL.GOV
ES.NET NERSC.GOV
ES.NET PNL.GOV


From the table we can then produce the [capaths] sections for each of
the five realms. The section consists of a separate subsection for each
client principal realm. Within each subsection are one or more entries
for each destination realm specifying the intermediate realm(s) used
on the path. A path with no intermediary realms is indicated by the
symbol "." (period).

The [capaths] section for ANL.GOV systems would look like this:

[capaths]
ANL.GOV = {
TEST.ANL.GOV = .
PNL.GOV = ES.NET
NERSC.GOV = ES.NET
ES.NET = .
}
TEST.ANL.GOV = {
ANL.GOV = .
}
PNL.GOV = {
ANL.GOV = ES.NET
}
NERSC.GOV = {
ANL.GOV = ES.NET
TEST.ANL.GOV = ES.NET
}
ES.NET = {
ANL.GOV = .
}


The [capaths] section for NERSC.GOV systems:

[capaths]
NERSC.GOV = {
ANL.GOV = ES.NET
TEST.ANL.GOV = ES.NET
TEST.ANL.GOV = ANL.GOV
PNL.GOV = ES.NET
ES.NET = .
}
ANL.GOV = {
NERSC.GOV = ES.NET
}
PNL.GOV = {
NERSC.GOV = ES.NET
}
ES.NET = {
NERSC.GOV = .
}
TEST.ANL.GOV = {
NERSC.GOV = ANL.GOV
NERSC.GOV = ES.NET
}

The [capaths] section for ES.NET systems:
ES.NET = {
ANL.GOV = .
TEST.ANL.GOV = ANL.GOV
NERSC.GOV = .
PNL.GOV = .
}
ANL.GOV = {
ES.NET = .
NERSC.GOV = ES.NET
PNL.GOV = ES.NET
}
TEST.ANL.GOV = {
ES.NET = ANL.GOV
NERSC.GOV = ANL.GOV
}
PNL.GOV = {
ES.NET = .
}
NERSC.GOV = {
ES.NET = .
}

The [capaths] section for PNL.GOV systems:
PNL.GOV = {
ANL.GOV = ES.NET
NERSC.GOV = ES.NET
ES.NET = .
}
ANL.GOV = {
PNL.GOV = ES.NET
}
NERSC.GOV = {
PNL.GOV = ES.NET
}
ES.NET = {
PNL.GOV = .
}

The [capaths] section for TEST.ANL.GOV systems:
TEST.ANL.GOV = {
ANL.GOV = .
ES.NET = ANL.GOV
NERSC.GOV = ANL.GOV
NERSC.GOV = ES.NET
}
ANL.GOV = {
TEST.ANL.GOV = .
}
ES.NET = {
TEST.ANL.GOV = ANL.GOV
}
NERSC.GOV = {
TEST.ANL.GOV = ES.NET
TEST.ANL.GOV = ANL.GOV
}

In the above [capaths] sections, the ordering of the destination realm
values
are not important except when the same destination realm is used more
then once
to specify a sequence of intermediary realms. (Ordering is never
important to
the server since the transited realm field in the ticket is not ordered.)

Client systems from which client principals issued by multiple realms
are used
must include the transited realm rules appropriate for each of the client
principals.

The error message "Illegal cross-realm ticket" implies that a [capaths]
section for the authentication path must be added to the server machine.
The error message "KDC policy rejects request" implies that the [capaths]
section on the server specifies an authentication path which does not match
the authentication path that was actually used.

Cross realm authentication paths are not currently supported by DCE. DCE
security servers can be used with Kerberized clients and servers, but
versions
prior to DCE 1.1 did not fill in the transited field, and should be used
with
caution.

"\"\"Jeffrey Altman [Kermit Project]\" via RT\"" wrote:

May want to say in the appence of any ca-ath information,
the DSN realm names wil be walked.



Above line may not be needed but should not hurt, and was not in previous dicumentation.
The ANL.GOV would not use this entry.


Above two lines are also not needed, as the ES.NET client does not care about
the ANL.GOV path to PNL.GOV


The above line is not needed.



Do you want to say anything about Microsoft, or Heimdal or SEAM?



--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444