[krbdev.mit.edu #2559] Replacement Text Explaining [capaths] forAdmin Guide
Douglas E. Engert
deengert at anl.gov
Fri May 14 11:05:42 EDT 2004
"\"\"Jeffrey Altman [Kermit Project]\" via RT\"" wrote:
>
> [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.
May want to say in the appence of any ca-ath information,
the DSN realm names wil be walked.
>
> 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
Above line may not be needed but should not hurt, and was not in previous dicumentation.
The ANL.GOV would not use this entry.
> }
> 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
Above two lines are also not needed, as the ES.NET client does not care about
the ANL.GOV path to PNL.GOV
> }
> TEST.ANL.GOV = {
> ES.NET = ANL.GOV
> NERSC.GOV = ANL.GOV
The above line is not needed.
> }
> 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.
Do you want to say anything about Microsoft, or Heimdal or SEAM?
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the krb5-bugs
mailing list