possible new project: better realm determination heuristics -- any takers?

[Simo Sorce]

On Tue, 2008-04-08 at 08:14 +0200, Mark Phalan wrote:
> On 7 Apr 2008, at 20:54, Ken Raeburn wrote:
> > One area we're looking to improve our package is in configuration
> > requirements -- minimizing the need to manually set up the config file
> > on client hosts -- and realm determination, both of server hosts and
> > especially of the local host as a client, is a particular case of
> > this.  Is anyone interested in making some improvements in this area?
> >
> > Currently, we look for default_realm in the config file, and if that
> > doesn't work, and the compile-time and run-time configurations allow,
> > we try looking up some "_kerberos" TXT records in DNS, and then give
> > up. But our code for determining the realm of a server host does other
> > checks that we don't do for the local realm, like checking the current
> > hostname and parent domains in the domain_realm mapping table;
> > aligning the two sets of heuristics, to the degree that it makes
> > sense, would also be helpful.
> >
> > There are probably other fairly cheap heuristics that could be
> > implemented as well, for both servers and default realm
> > determination.  For example, guess that the hostname itself, or the
> > parent domain, is also the realm name, and see if we can figure out
> > where the KDCs are; if we can't, retry with the next domain up towards
> > the root.
> 
> I basically implemented this heuristic for our (Sun's) code.
> If you're interested I can make a patch for MIT 1.6.3 ?
> 
> The algorithm is:
> 
>     domain = fqdn;
>     while (domain.label_count > 2) {
> 	domain = pop_label(domain);
> 	realm = domain2realm(domain); /* for ASCII: toupper() */
> 	if (lookup_kdcs(realm) > 0)
> 	    break;
> 	realm = NULL;
>     }
> 
>     return (realm);
> 
> This was suggested by Nico back in Dec 2006.

It would be useful if discovery would be implemented as a pluggable
interface, so that custom resolvers can be implemented. This will let
people customize the resolvers based on their environment and resources.

In the samba project I could use that to load up a plugin able to
understand how to discover this information in an AD environment and use
a single file to hold the configuration. We already use the locate
pluggable interface to make kerberos libs site aware and implement
server affinity.

Therefore wouldn't it make sense to extend the service locator
interface ?
Or implement something similar anyway?

A good default could also be the proposed code above.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York