Kerberos dev project for review: domain_realm mapping via KDC referral

[John Hascall]

> 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, ...

If anyone happens to be interested, take a look in
http://john.public.iastate.edu/public/kerberos/conv_princ.c
(look for the OLD_AND_BUSTED and NEW_HOTNESS ifdefs)

How many places are still doing 524 stuff, anyway?
(Knock on wood) we are quiting the May 15th, and we're
pretty much always the last to give stuff up :)

Anyway, the concept is simple, it's essentially doing this:

#ifdef  NEW_HOTNESS
          p = get_sconv_list(context, name, realm);
#else
          p = sconv_list;
#endif

in krb5_425_conv_principal() where get_sconv_list() constructs
a one element 'struct krb_convert' as needed from the config file.


>                     ..., 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.

Good luck with that one...



> >  [kdc]
> >    host_referral = no

> 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.

   Probably not.  I threw that out there more or less as
   an "unease" mitigator.

John