On 4 Oct 2007, at 19:02, Booker Bense wrote:

>
> The only reason to put in a LDAP back end is to simplify the
> account management

One thing I keep thinking about implementing is an LDAP->kadmin
proxy. You'd still have the KDC database in the current DB format,
but you'd be able to access it through an overlay on your OpenLDAP
server, which would translate LDAP actions into kadmin RPCs.

S.

Simon Wilkinson writes:

> One thing I keep thinking about implementing is an LDAP->kadmin
> proxy. You'd still have the KDC database in the current DB format, but
> you'd be able to access it through an overlay on your OpenLDAP server,
> which would translate LDAP actions into kadmin RPCs.

Having done a bit of Active Directory munging over LDAP, I don't think
LDAP makes a very appealing kadmin protocol, although it may be better
with a better data model than Active Directory offers. (Separating flags
out into separate attributes, for example, rather than using a bitmask in
one attribute.)

LDAP is an extremely heavy-weight and complex protocol, although it does
have the advantage of having stable libraries and a reasonable
authentication structure.

--
Russ Allbery (rra@stanford.edu)

On Oct 4, 2007, at 14:02, Booker Bense wrote:
> In article ,
> Jonathan Javier Cordoba Gonzalez 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