Kerberos dev project for review: domain_realm mapping via KDC referral

[Ken Raeburn]

On Apr 29, 2008, at 14:16, John Hascall wrote:
> PLEASE, no more evilness like the compiled in krb5_524_conv_principal
> table (which we have ripped out and replaced with a config-file option
> here since 1.0.5 BTW).

I would ask for a patch, except I'm hesitant to put more realm-wide  
config information into the config files that have to manually be kept  
in sync across all KDCs.  (Yes, some of it could be automated, if one  
wanted, but with potential per-KDC config options like pw-checking  
plugins in there too, it's not simply copying the file from KDC to  
KDC.)  This sort of info should be maintained per-realm and  
distributed with the other per-realm data (principals, key, policies),  
but that's another project.

Of course, the domain_realm mapping would now affect the KDC behavior  
in a way where it should be kept in sync realm-wide.  *sigh*

> As others have mentioned, I think it makes more sense to
> treat */looks.like.an.fqdn as a "host_based_service" unless
> there is a config-file option to turn it off.  Perhaps:
>
>  [kdc]
>    no_host_referral = host ftp
>
> (why you want to turn those two off escapes me, but go with it)
> and perhaps even an option to just turn it off entirely:
>
>  [kdc]
>    host_referral = no

Yeah, I'm starting to think that defaulting to host-principal  
treatment is the better way to go, unless Russ's unease turns into a  
real use case with bad behavior.  (I confess to a little unease  
myself, but I think it's just reluctance to change the default  
behavior.)

Is there really a need to turn this code off?  It shouldn't make any  
difference in returned data unless someone is actually talking to the  
KDC for the wrong realm and requesting a referral.  The KDC does to a  
bit more work, mainly examining the domain_realm mapping data.

Ken