On Oct 4, 2007, at 14:02, Booker Bense wrote: > In article <[EMAIL PROTECTED]>, > Jonathan Javier Cordoba Gonzalez <[EMAIL PROTECTED]> wrote: >> Thanks to all of you.... I actually got that it works... >> >> According to Russ the LDAP Back End doesn't improve the >> performance... there >> are some performance tests?? > > I find hard to imagine anything going much faster than a KDC, > it's a single key lookup into a single database that isn't all > that big. Performance of the KDC has never been an issue in Kerberos.
To be picky, it's usually going to be a couple of lookups. The entry for the requested service is needed (not just the key, but also expiration data, flags etc), and either the user's entry (for initial ticket acquisition) or the krbtgt key (for decrypting requests for additional tickets) is needed. (And we implement some preauthentication bits via additional database entries under different names, an idea which really should be revisited if and when we revamp the database format someday.) The krbtgt principal data is actually cached very briefly in the MIT KDC, but is re-fetched often because we don't get notification when it changes (a rare, but possible, event). While the performance comparison details are going to vary -- a local LDAP server process keeping all its data in memory might be faster than going out to disk to read a db2 file, if your disk cache isn't efficient -- I would expect db2 to be faster in the normal cases. However, there are other considerations. For example, MIT has received code (which needs review, and some work to integrate) to make our KDC multithreaded in the area doing database queries; the LDAP back end will support multiple queries in progress at once, but the Berkeley DB one won't. MIT's db2 code was forked from the Sleepycat (now Oracle) one years ago, back at version 1.85, when they changed their license; development on ours has pretty much stopped, and while we try to fix bugs we hear about, this database code -- this *version* of it -- isn't getting exercised by any other projects we know of. MIT's db2 code won't support databases over 4G; the LDAP back end, I presume, will support more principal entries at the high end, though I don't know what the performance characteristics are like. But, yes, as far as I recall off the top of my head, no one has complained about the performance of the MIT KDC. Ken ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos