Difference between revisions of "Projects/domain realm referrals"
KenRaeburn (talk | contribs) (New page: {{project-early}} == Desired Changes == Eliminate the need for the domain_realm mapping table on the client side, in the common case. == Functional Requirements == Clients should be ab...) |
KenRaeburn (talk | contribs) |
||
| Line 28: | Line 28: | ||
* ''(there may be additional conditions that should be imposed)'' |
* ''(there may be additional conditions that should be imposed)'' |
||
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead. |
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead. |
||
| + | |||
| + | If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database. |
||
== Open Issues == |
== Open Issues == |
||
| Line 39: | Line 41: | ||
* Library changes implemented. |
* Library changes implemented. |
||
* Library change test case implemented. |
* Library change test case implemented. |
||
| − | * KDC portion implemented. |
||
| + | * KDC detection of the relevant cases |
||
| + | * KDC implementation of change of principal name |
||
== Testing Plan == |
== Testing Plan == |
||
| Line 46: | Line 49: | ||
Manual test of cross-realm case with kvno. |
Manual test of cross-realm case with kvno. |
||
| + | |||
| + | Manual test of unknown name that maps to the local realm. |
||
Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms. |
Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms. |
||
Revision as of 15:42, 28 April 2008
Contents
Desired Changes
Eliminate the need for the domain_realm mapping table on the client side, in the common case.
Functional Requirements
Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name service/canonical-fqdn@LOCAL.REALM to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (e.g., two components where first is in the set {host,ftp,...}).
The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.
Design
Use a new function, with most of the body of the current krb5_get_host_realm:
krb5_error_code krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)
Add a field to the accessor structure, to export it.
In the KDC code, in TGS processing, if:
- the server principal name is unknown
- the referral flag is set in the request
- the requested server principal has two components
- either the first component is a recognized service name (this may be hardcoded initially) or the name type is host-based
- the second component looks like a fully-qualified domain name
- (there may be additional conditions that should be imposed)
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.
If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.
Open Issues
Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)
Should we use a list of services, or just process all two-element names where the second component looks like a domain name?
Tasks/Milestones
- Library changes implemented.
- Library change test case implemented.
- KDC detection of the relevant cases
- KDC implementation of change of principal name
Testing Plan
Unit test for the new library routine.
Manual test of cross-realm case with kvno.
Manual test of unknown name that maps to the local realm.
Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.
