Kerberos OpenLDAP Frontend

[Ken Raeburn]

On Oct 4, 2007, at 14:02, Booker Bense wrote:
> In article <mailman.121.1190741359.2905.kerberos at mit.edu>,
> Jonathan Javier Cordoba Gonzalez  <jcordoba at uniandes.edu.co> 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