[paul.moore@centrify.com - Wed Aug 18 15:38:42 2004]:
Show quoted text
>
> I dont know if this is an old topic or not.
> I would like to replace the mechanism that kerberos uses for locating
> KDCs.
> My proposal would be to allow the calling application to do something
> along these lines
>
> krb5_set_locator(<context, <my locator function>);
>
> This function sets a callback pointer in the context block And then
> have krb5_locate_kdc look to see of this function pointer is non null
> and if so call <my function> instead of the standard sequence.
> Of course I could simply hack this into the code base but would much
> prefer to have it in the main code line. It seems that this could be
> useful for many people with non standard kdc discovery processes.
It's been a while, but...
In the current release, we support plugin modules for determining the KDC locations (or
rather, the locations of any Kerberos-related service -- KDC, kadmin, etc, but not, say,
telnet). See the installed header file <krb5/locate_plugin.h> for the interface; any symbol
named "service_locator" in an object file in the plugin directory will be registered with the
library. The lookup function can return zero or more socket addresses (address family +
address + port + socket type), or an indication that it doesn't have information and therefore
the next plugin or the built-in code should be consulted.
There's also a sample plugin in the source tree, not compiled by default, which loads a
Python script and looks for a Python function to execute to locate the indicated service. (It's
got some bugs, including not being thread-safe, but it's just a sample.)
That doesn't give you per-application control, but if you really need that, you could create a
separate shared library, with both a plugin and the application linked against it, to bridge the
gap. The application can tell the library what callback to use, and the plugin can consult the
library for the stored function pointer...
