Re: Kerberos OpenLDAP Frontend - Kerberos

This is a discussion on Re: Kerberos OpenLDAP Frontend - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Kerberos OpenLDAP Frontend

  1. Re: Kerberos OpenLDAP Frontend

    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.

    The only reason to put in a LDAP back end is to simplify the
    account management and get the LDAP replication stuff. There are
    many good reasons not to put it in an LDAP back end.

    _ Booker C. Bense



  2. Re: Kerberos OpenLDAP Frontend


    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.


  3. Re: Kerberos OpenLDAP Frontend

    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)

  4. Re: Kerberos OpenLDAP Frontend

    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

+ Reply to Thread