| Author |
Topic: What's inside krb5.conf? -- The [capaths] Section |
|
eLDAP
member
offline  |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
 |
|
|
| What's inside krb5.conf? -- The [capaths] Section |
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.
A client uses this section to find the authentication path between its realm and the realm of the server. The server uses this section to verify the authentication path used by the client, by checking the transited field of the received ticket.
There is a subsection for each participating realm, and each subsection has relations named for each of the realms. The relation-value is an intermediate realm which can participate in the cross-realm authentication. The relations can be repeated if there is more than one intermediate realm. A value of '.' means that the two realms share keys directly, and no intermediate realms should be allowed to participate.
There are n**2 possible entries in this table, but only those entries which is needed on the client or the server need to be present. The client needs a subsection named for its local realm, with relations named for all the realms of servers it needs to authenticate with. A server needs a subsection named for each realm of the clients it serves.
|
|
|
|
|
|
|
eLDAP
member
offline  |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| Example 1 |
For example, to set-up cross realm authentication between ENG.EAST.ACME.COM and SALES.WEST.ACME.COM, krb5.conf should include the following entry:
[capaths]
ENG.EAST.ACME.COM = {
SALES.WEST.ACME.COM = .
}
SALES.WEST.ACME.COM = {
ENG.EAST.ACME.COM = .
}
On Windows 2000, you must set up a trust relationship between the two realms.
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| Example 2 |
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 authenticates with NERSC.GOV but not PNL.GOV.
The [capath] 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
}
ES.NET = {
ANL.GOV = .
}
The [capath] section of the configuration file used on NERSC.GOV systems would look like this:
[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
}
In the above example, the ordering is not important, except when the same relation is used more than once. The client uses this to determine the path.
|
|
|
|
|
|
|
|
Email To Friend | 
Set Alert To This Topic
New Topic | 
Post Reply 
posted on: 02/10/2010 09:20:03 PM
Edit
Quote
Report
Profile
Reply