1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
<html lang="en">
<head>
<title>Kerberos V5 System Administrator's Guide</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="Kerberos V5 System Administrator's Guide">
<meta name="generator" content="makeinfo 4.5">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
</head>
<body>
<div class="node">
<p>
Node:<a name="capaths">capaths</a>,
Next:<a rel="next" accesskey="n" href="Sample-krb5.conf-File.html#Sample%20krb5.conf%20File">Sample krb5.conf File</a>,
Previous:<a rel="previous" accesskey="p" href="logging.html#logging">logging</a>,
Up:<a rel="up" accesskey="u" href="krb5.conf.html#krb5.conf">krb5.conf</a>
<hr><br>
</div>
<h4 class="subsection">[capaths]</h4>
<p>In order to perform direct (non-hierarchical) cross-realm
authentication, a database is needed to construct the authentication
paths between the realms. This section defines that database.
<p>A client will use this section to find the authentication path between
its realm and the realm of the server. The server will use this section
to verify the authentication path used by the client, by checking the
transited field of the received ticket.
<p>There is a tag for each participating realm, and each tag has subtags
for each of the realms. The value of the subtags is an intermediate
realm which may participate in the cross-realm authentication. The
subtags may be repeated if there is more then one intermediate realm. A
value of "." means that the two realms share keys directly, and no
intermediate realms should be allowd to participate.
<p>There are n**2 possible entries in this table, but only those entries
which will be needed on the client or the server need to be present.
The client needs a tag for its local realm, with subtags for all the
realms of servers it will need to authenticate with. A server needs a
tag for each realm of the clients it will serve.
<p>For example, ANL.GOV, PNL.GOV, and NERSC.GOV all wish to use the ES.NET
realm as an intermediate realm. ANL has a sub realm of TEST.ANL.GOV
which will authenticate with NERSC.GOV but not PNL.GOV. The [capaths]
section for ANL.GOV systems would look like this:
<pre class="smallexample"> [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
}
ES.NET = {
ANL.GOV = .
}
</pre>
<p>The [capaths] section of the configuration file used on NERSC.GOV systems
would look like this:
<pre class="smallexample"> [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
}
</pre>
<p>In the above examples, the ordering is not important, except when the
same subtag name is used more then once. The client will use this to
determine the path. (It is not important to the server, since the
transited field is not sorted.)
<p>This feature is 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.
</body></html>
|
