Projects/domain realm referrals
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.
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 portion implemented.
Testing Plan
Unit test for the new library routine.
Manual test of cross-realm case with kvno.
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.
