Difference between revisions of "Projects/domain realm referrals"

Revision as of 11:23, 18 July 2008

Desired Changes

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

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 request is not a user-to-user authentication request
• the server principal name is unknown
• the canonicalize flag is set in the request
• the requested server principal has exactly two components
• either:
  • the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
  • the name type is NT-SRV-HST
• the first component is not in a list configured in the KDC config file under "no_host_referral"
• the second component looks like a fully-qualified domain name

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.

A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".

The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.

The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.

With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.

Tasks/Milestones

• Library changes
• Library change test case
• 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.

Open Issues

Should all services to process this way when NT-UNKNOWN is used be specified in the config file, or should we start with the hardcoded list in the 524 name conversion code and add from there? (The exception list could still override, but wouldn't distinguish between NT-UNKNOWN and NT-SRV-HST.) Probably default to an empty list.

Caching the lists of service names isn't in the plan; that can be added later if there's a performance concern.

Review

This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type

#~~~~

on its own line. The next section is for discussion. Use standard talk page conventions. In particular, sign comments with

--~~~~

and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with {{project-block}}. The member who raised the objection should remove this markup when their objection is handled.

Approvals

Discussion

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option. --SamHartman 13:45, 10 May 2008 (EDT)

I think today's new version should address Jeff's comments. Posting a new message asking for review.... --KenRaeburn 16:17, 3 July 2008 (EDT)