KDC query client performance
Roland C. Dowdeswell
elric at imrryr.org
Mon Feb 14 20:02:57 EST 2011
On Mon, Feb 14, 2011 at 07:34:51PM -0500, Sam Hartman wrote:
> >>>>> "Simo" == Simo Sorce <ssorce at redhat.com> writes:
> Simo> On Mon, 14 Feb 2011 18:35:14 +0000
> Simo> "Roland C. Dowdeswell" <elric at imrryr.org> wrote:
> > Also, it might be a better idea in the longer term to write a little
> >> daemon that runs as root, listens on a UNIX domain socket and
> >> accepts requests from the krb5 libs to have conversations with
> >> various KDCs. The advantage of this would be that this daemon
> >> could keep track of which KDCs are up and perhaps even keep track
> >> of which ones answer the quickest (and are therefore likely the
> >> closest), etc.
> Simo> You can do this separately by creating a locator plugin.
> Simo> That's what we do with the SSSD project at least, so that the
> Simo> sssd daemon does the discovery and just tells the krb5 libs
> Simo> what is the ip address to use for the KDC.
> Yes, but I think that this is important enough to Kerberos performance
> that someone should really do this separately from SSSD. If you're
> going to use SSSD, or some full infrastructure, you'll use their KDC
> locator. However, you really want this service. All the time. Even if
> you just want a Kerberos client.
I was considering writing something quite cheezy for this at work
that supported UDP only. It would just be a UDP relay more or less
with a little logic about who is responding and how fast with no
analysis of the contents of either the outgoing packets or the
This would have a couple of advantages:
1. you wouldn't need to understand the contents of UDP packets
at all, all you would need to do is time the responses
and keep track of which KDCs were responding and maintain
a bit of an algorithm to keep that fresh, and
2. it would require no client-side support at all, just put
kdc = 127.0.0.1:88
in the realm section of /etc/krb5.conf and it would
work. This was important when I was considering it
because I have to ensure that many different Kerberos
libraries and versions would work properly. The main
culprit being the Java JGSS libraries whose failover
behavior really wants a little help of this sort.
Multiple realms could be supported by running UDP relays
on multiple ports. One could also put the regular KDCs
after the ``kdc = localhost'' line which would provide
the assurance that if the proxy crashed, the clients
would behave almost identically to how they might have
if it hadn't been written.
Effectively, it would be equivalent to dynamically putting the most
responsive KDC at the head of the KDC list at all times.
That said, we didn't really have a performance issues and so it
wasn't considered to be a priority. It was interesting to consider
for a while, though.
Doing it the cheezy way as described above, provides the advantage
that any Kerberos client library can use it, however it leaves lot
of the performance enhancements that could be achieved on the table.
If one took the approach of a UNIX domain socket with which the
clients have a more interesting conversation where they let the
proxy know what their intent is, then all sorts of things such as
the xrealm graph could be cached to avoid repeating the traversals
mentioned at the beginning of this thread. Although, at that point
this would be more like a new ccache type that operates over a
local socket rather than a simple KDC proxy.
There is a large advantage to be had from keeping a little bit of
states on the client hosts which can be shared amongst the various
client applications especially if said state is [safely] shared
Roland Dowdeswell http://Imrryr.ORG/~elric/
More information about the krbdev