Kerberos dev project for review: domain_realm mapping via KDC referral

[Ken Raeburn]

On Apr 28, 2008, at 19:01, Russ Allbery wrote:
> I would prefer to be able to configure the list of services in a KDC
> configuration file from early on rather than using a hard-coded list,
> since we frequently run into host-based principals of types that  
> software
> isn't already familiar with.

I definitely think it's desirable for a site to be able to define  
their own.  I'm just concerned that the default list (presumably, the  
same set as used by krb5_524_conv_principal) is going to be non- 
trivial in size anyways, and do we want sites to be able to remove  
entries relative to MIT's default settings, and/or replace the full  
list?  That could be tricky without making the admin copy the default  
list into the config file and start editing from there, and that's a  
pretty ugly solution too.

(And as I noted, there's the config-file vs in-database question.   
Having one KDC return a referral to a request when another would not,  
because of differences in the config files, would be confusing.)

That said, I guess customers of Sun, Apple, Red Hat, etc., aren't  
going to want to recompile things to add a new name, are they?  Okay,  
how about this:

[kdc]
   host_based_services = foo bar
   host_based_services = baz

...adds foo, bar, and baz to the compiled-in default list, and no  
option to disable or subtract from the default list.  Would that be  
sufficient?

(I suppose I should've also noted in the original proposal, there  
wasn't an explicit configuration option in the plan to turn off the  
behavior, though I guess one could remove the domain_realm mapping on  
the KDC.)

> I think having a configurable list of components is better than just
> looking at the second component and checking whether it looks like a
> hostname.

You mean, be able to say that, if the first component is "fred", we  
treat component 3 as the hostname?  This is supposed to be a minimal  
implementation -- sufficient to handle your basic host-based services,  
nothing terribly fancy.  Just enough to be able to get rid of the  
domain_realm specs in most client cases.

Ken