LDAP KDB - Kerberos

This is a discussion on LDAP KDB - Kerberos ; Dear Kerberos/LDAP gurus I've seen that the 1.6 MIT release includes support for storing the database into an LDAP server. My apologies for the dummy question, but what are the advantages of putting the database into LDAP? Ciao, Enrico --- ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: LDAP KDB

  1. LDAP KDB

    Dear Kerberos/LDAP gurus

    I've seen that the 1.6 MIT release includes support for storing the
    database into an LDAP server.

    My apologies for the dummy question, but what are the advantages of
    putting the database into LDAP?

    Ciao,

    Enrico
    ---
    Promise me no promises,
    So I will not promise you ...
    (Christina Rossetti)

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: LDAP KDB

    On Jan 22, 2007, at 4:39, Enrico M. V. Fasanelli wrote:
    > Dear Kerberos/LDAP gurus
    >
    > I've seen that the 1.6 MIT release includes support for storing the
    > database into an LDAP server.
    >
    > My apologies for the dummy question, but what are the advantages of
    > putting the database into LDAP?


    Integration with other LDAP-based account administration, especially
    if Kerberos is being added to an environment already using LDAP;
    automatic and immediate synchronization between all KDCs and kadmin
    servers and password-change servers as changes are made....

    Ken


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: LDAP KDB

    Possibly wandering off topic here, but I feel it's worth mentioning;

    Having used OpenLDAP and Kerberos, I must say that I wouldn't do this.
    I can see why people would want to, but my experience with the two bits of
    software has left me with a sour taste when it comes to OpenLDAP,
    especially with regards to replication.

    Granted, most of the problems seem to have been caused by either the BDB
    backend on OpenLDAP, or my own damn fault (schema problems, improper
    copies of replication data, flat out bad configuration, etc), but I have
    actually yet to break MIT KRB5, despite the weird and wonderful setups I
    have pushed through it, whereas OpenLDAP seems to fall over at the drop
    of that hat (or worse yet, half falls over, and doesn't tell you). Maybe
    I've done something wrong, but the fact that I've had to recreate my
    LDAP database at least five times in the past two years has left me a
    little hesitant about it.

    In any case, I'd thought I'd put a note here. If you're planning a new
    installation from scratch, using the KDB Kerberos in LDAP method...
    Don't. In fact, while I'm on this topic, my recommendation is to set
    things up in the following order;

    DNS
    Kerberos
    LDAP (using Kerberos for authentication of replicas).

    Regards
    Edward Murrell

    Ken Raeburn wrote:
    > On Jan 22, 2007, at 4:39, Enrico M. V. Fasanelli wrote:
    >
    >> Dear Kerberos/LDAP gurus
    >>
    >> I've seen that the 1.6 MIT release includes support for storing the
    >> database into an LDAP server.
    >>
    >> My apologies for the dummy question, but what are the advantages of
    >> putting the database into LDAP?
    >>

    >
    > Integration with other LDAP-based account administration, especially
    > if Kerberos is being added to an environment already using LDAP;
    > automatic and immediate synchronization between all KDCs and kadmin
    > servers and password-change servers as changes are made....
    >
    > Ken
    >
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: LDAP KDB

    >>>>> "Edward" == Edward Murrell writes:

    Edward> Possibly wandering off topic here, but I feel it's worth
    Edward> mentioning; Having used OpenLDAP and Kerberos, I must say
    Edward> that I wouldn't do this. I can see why people would want
    Edward> to, but my experience with the two bits of software has
    Edward> left me with a sour taste when it comes to OpenLDAP,
    Edward> especially with regards to replication.

    Edward> Granted, most of the problems seem to have been caused by
    Edward> either the BDB backend on OpenLDAP, or my own damn fault
    Edward> (schema problems, improper copies of replication data,
    Edward> flat out bad configuration, etc), but I have actually yet
    Edward> to break MIT KRB5, despite the weird and wonderful setups
    Edward> I have pushed through it, whereas OpenLDAP seems to fall
    Edward> over at the drop of that hat (or worse yet, half falls
    Edward> over, and doesn't tell you). Maybe I've done something
    Edward> wrong, but the fact that I've had to recreate my LDAP
    Edward> database at least five times in the past two years has
    Edward> left me a little hesitant about it.

    Funny, I've been using OpenLDAP since 2003, and its been wonderfully
    solid. I will agree that it is sensitive to configuration being
    correct, but given the point is to keep the data it stores secure,
    that's what I want. Having to recreate your database would definately
    indicate that you must be doing something incorrect (using LDBM as the
    backend would be one possibilty, or a known bad release of BDB, like
    4.3). Using distro provided versions of OpenLDAP is also known to be
    a generally bad thing to do, depending on the distro.

    And I know I don't have every message sent to the openldap-software
    list, but I don't see your email address coming up, so I'm guessing
    you never asked any questions about why you might be running into the
    issues you were running into in the first place. Searching the
    openldap-software archives doesn't turn up anything, either. Perhaps
    if you had inquired for help, you wouldn't have run into the issues
    you hit.

    --Quanah


    --
    Quanah Gibson-Mount
    Principal Software Developer
    ITS/Shared Application Services
    Stanford University
    GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

  5. Re: LDAP KDB

    Along the same lines, I find my comfort level much higher using MIT
    Kerberos as a security mechanism, and separately OpenLDAP (or any LDAP)
    as a directory server. Using a large piece of software originally
    designed, built, and optimized for directory services as a security
    mechanism seems dangerous to me, compared with using software designed,
    built, and optimized from the ground up as a security mechanism.

    However, conversely, I would love to see a LDAP replacement for the
    kadmin protocol. I am not looking for an LDAP implementation worthy of
    being called a true directory server, but rather simply a GSSAPI
    authenticated, TLS protected, LDAP enabled interface for
    adding/removing/managing users/acls/policies within the existing
    Kerberos database.

    I pondered a back-kadmin for OpenLDAP for a while, but my C skills are
    rather rusty. Has anyone else considered this path, or is it just a bad
    idea?

    Just my $0.03,
    -Matt

    On Wed, 2007-01-24 at 11:36 +1300, Edward Murrell wrote:
    > Possibly wandering off topic here, but I feel it's worth mentioning;
    >
    > Having used OpenLDAP and Kerberos, I must say that I wouldn't do this.
    > I can see why people would want to, but my experience with the two bits of
    > software has left me with a sour taste when it comes to OpenLDAP,
    > especially with regards to replication.
    >
    > Granted, most of the problems seem to have been caused by either the BDB
    > backend on OpenLDAP, or my own damn fault (schema problems, improper
    > copies of replication data, flat out bad configuration, etc), but I have
    > actually yet to break MIT KRB5, despite the weird and wonderful setups I
    > have pushed through it, whereas OpenLDAP seems to fall over at the drop
    > of that hat (or worse yet, half falls over, and doesn't tell you). Maybe
    > I've done something wrong, but the fact that I've had to recreate my
    > LDAP database at least five times in the past two years has left me a
    > little hesitant about it.
    >
    > In any case, I'd thought I'd put a note here. If you're planning a new
    > installation from scratch, using the KDB Kerberos in LDAP method...
    > Don't. In fact, while I'm on this topic, my recommendation is to set
    > things up in the following order;
    >
    > DNS
    > Kerberos
    > LDAP (using Kerberos for authentication of replicas).
    >
    > Regards
    > Edward Murrell
    >
    > Ken Raeburn wrote:
    > > On Jan 22, 2007, at 4:39, Enrico M. V. Fasanelli wrote:
    > >
    > >> Dear Kerberos/LDAP gurus
    > >>
    > >> I've seen that the 1.6 MIT release includes support for storing the
    > >> database into an LDAP server.
    > >>
    > >> My apologies for the dummy question, but what are the advantages of
    > >> putting the database into LDAP?
    > >>

    > >
    > > Integration with other LDAP-based account administration, especially
    > > if Kerberos is being added to an environment already using LDAP;
    > > automatic and immediate synchronization between all KDCs and kadmin
    > > servers and password-change servers as changes are made....
    > >
    > > Ken
    > >
    > >
    > > ________________________________________________
    > > Kerberos mailing list Kerberos@mit.edu
    > > https://mailman.mit.edu/mailman/listinfo/kerberos
    > >

    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos

    --
    Matthew J. Smith
    University of Connecticut UITS

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBFt2ikUtSvppOnag8RAqVZAKCNBH3iRkc61yHlAWVtDm 7qDShz0ACfXa4p
    grPthqAxYJol9dqlZvs4ZLQ=
    =O+D/
    -----END PGP SIGNATURE-----


  6. Re: LDAP KDB

    In article ,
    Quanah Gibson-Mount wrote:
    ....
    > Funny, I've been using OpenLDAP since 2003, and its been wonderfully
    > solid. I will agree that it is sensitive to configuration being
    > correct, but given the point is to keep the data it stores secure,
    > that's what I want. Having to recreate your database would definately
    > indicate that you must be doing something incorrect (using LDBM as the
    > backend would be one possibilty, or a known bad release of BDB, like
    > 4.3). Using distro provided versions of OpenLDAP is also known to be
    > a generally bad thing to do, depending on the distro.


    I can't speak for anyone but myself, but I think it's possible
    to be very impressed with what OpenLDAP has accomplished, and
    still allow that the classic MIT KDC database sets a standard
    for reliability.

    It could hardly be otherwise, just from the relative complexity
    and rate of development. When you move the KDC to an LDAP database,
    you're moving from a Berkeley DB that has changed little in years,
    to a complex network service built on a sometimes uneasy alliance
    of OpenLDAP, Sleepycat Berkeley DB, OpenSSL and Cyrus SASL.
    All developing at different rates, and as you observed, one
    can neither take the versions offered by one's platform vendor nor
    settle on an OpenLDAP version and expect it to serve for years.

    When you build your BDB, did you get the wrong version? Did you
    fail to apply the recommended patches? Did you get it to use the
    right type of mutexes? When you deploy the LDAP service, does
    it configure adequate cache sizes, logging options, checkpoints,
    etc.? We use OpenLDAP here, and I think we have gotten all this
    stuff square, and the result is certainly a state of the art
    LDAP service that could hardly be better. But even then, I can't
    say it has been as reliable as a the classic MIT KDC, which doesn't
    require any such attention. If you don't need LDAP here, then
    you'd be a fool to pay the price - in this much, I agree with the
    previous poster.

    And I am not convinced that replication is a great reason for moving
    to LDAP. If you need more than the backup replica you get from MIT,
    there are relatively simple and effective ways to install replication
    "in front of" the KDCs, rather than behind them (just as, ironically,
    OpenLDAP uses its own replication rather than its Berkeley DB's.)
    There's no software for it off the shelf, but it has been done
    independently at different universities and probably other sites,
    with very minor hacks to the MIT kadmind.

    Donn Cave, donn@u.washington.edu

  7. Re: LDAP KDB

    >>>>> "Donn" == Donn Cave writes:

    Donn> In article ,
    Donn> Quanah Gibson-Mount wrote:
    Donn> ...
    >> Funny, I've been using OpenLDAP since 2003, and its been
    >> wonderfully solid. I will agree that it is sensitive to
    >> configuration being correct, but given the point is to keep the
    >> data it stores secure, that's what I want. Having to recreate
    >> your database would definately indicate that you must be doing
    >> something incorrect (using LDBM as the backend would be one
    >> possibilty, or a known bad release of BDB, like 4.3). Using
    >> distro provided versions of OpenLDAP is also known to be a
    >> generally bad thing to do, depending on the distro.


    Donn> I can't speak for anyone but myself, but I think it's
    Donn> possible to be very impressed with what OpenLDAP has
    Donn> accomplished, and still allow that the classic MIT KDC
    Donn> database sets a standard for reliability.

    Just to note, I wasn't commenting one way or the other about using
    LDAP as the KDC store, just the rather uninformed comments of the
    original poster, who apparently never once thought to consult with the
    people who wrote the software about the problems he was encountering.

    --Quanah

    --
    Quanah Gibson-Mount
    Principal Software Developer
    ITS/Shared Application Services
    Stanford University
    GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

  8. Re: LDAP KDB

    Quanah Gibson-Mount writes:

    > Just to note, I wasn't commenting one way or the other about using LDAP
    > as the KDC store, just the rather uninformed comments of the original
    > poster, who apparently never once thought to consult with the people who
    > wrote the software about the problems he was encountering.


    The original poster had a very valid point in that setting up OpenLDAP
    successfully is about an order of magnitude more work, with far more
    gotchas and potential problems, than setting up a KDC with a local account
    store. As wonderful as OpenLDAP is, it's not trivial to set up, whereas
    just about anyone who can install Unix software can install a KDC.

    It takes me about ten minutes to set up a new generic KDC from scratch for
    testing, starting with a bare build and nothing but vendor packages, and
    the result always works and doesn't require being careful of particular
    vendor versions or building my own software. As wonderful as OpenLDAP is,
    you can't really say the same about it.

    What this means for the LDAP backend is that you're making your KDC far
    more complex by using it, and therefore probably don't want to use it
    unless it's doing something specific and important for you. (However, one
    of the specific and important things that it *might* do, which MIT
    Kerberos currently does not, is incremental replication.)

    --
    Russ Allbery (rra@stanford.edu)

  9. Re: LDAP KDB

    In article <87fya0p6ae.fsf@windlord.stanford.edu>,
    Russ Allbery wrote:

    > unless it's doing something specific and important for you. (However, one
    > of the specific and important things that it *might* do, which MIT
    > Kerberos currently does not, is incremental replication.)


    How much interest is there, really, in incremental replication,
    among people who weren't already wanting to go to an LDAP database?

    In our situation, it was so easy to get that we didn't have to
    think very hard about how much we really needed it. If the
    situation changed, I suspect we might look at the numbers and
    decide that incremental replication is not a major issue.

    I can see it might be different for a much larger institution
    or one spread across distant sites, but wouldn't know for sure.
    We're only ca. 300K principals, all in one urban area.

    But it's no secret that various sites have hacked up something
    to make increment replication happen, and don't recall ever
    hearing that anyone was interested in making this technology
    into something people could get off the shelf. That's fine,
    I suppose there are plenty of reasons why once you get to that
    point, you'd just as soon "roll your own", but I'm just thinking
    that the lack of interest in this area may mean that incremental
    replication isn't worth all that much to the average site.

    Donn Cave, donn@u.washington.edu

  10. Re: LDAP KDB

    Donn Cave writes:
    > Russ Allbery wrote:


    >> (However, one of the specific and important things that it *might* do,
    >> which MIT Kerberos currently does not, is incremental replication.)


    > How much interest is there, really, in incremental replication, among
    > people who weren't already wanting to go to an LDAP database?


    I personally thought I cared until I looked at the database replication
    speed in practice and realized that I could do a full replication in under
    a minute to both slaves. At that point, I decided it wasn't important.

    Multimaster would still be interesting just to avoid a downtime of admin
    services should one host go down, but even that isn't a huge issue for
    us.

    --
    Russ Allbery (rra@stanford.edu)

  11. Re: LDAP KDB


    On Jan 24, 6:09 am, matt.sm...@uconn.edu ("Matthew J. Smith") wrote:
    > Along the same lines, I find my comfort level much higher using MIT
    > Kerberos as a security mechanism, and separately OpenLDAP (or any LDAP)
    > as a directory server. Using a large piece of software originally
    > designed, built, and optimized for directory services as a security
    > mechanism seems dangerous to me, compared with using software designed,
    > built, and optimized from the ground up as a security mechanism.


    In general I would agree, use the right tool for the job, etc. But
    directories have been intimately tied to security and user management
    from the very beginning. Speaking as someone who's been working with
    Kerberos since the mid 1980s and directories since the 90s, I know this
    from direct experience.

    Looking at that timeline, it's clear that Kerberos has about a decade's
    head start on LDAP in terms of maturity. I find it amusing reading in
    this thread how easy it is to deploy a KDC vs deploying LDAP. Back in
    1987 we were cursing how hard it was to get Kerberos deployed. (What,
    we have to have *all* of our hosts in DNS? And we have to keep the
    clocks synchronized?? How are we supposed to manage that on top of
    everything else we already have to worry about?) Suffice to say,
    there's both a growth curve for the software and a learning curve for
    the user base. Having lived thru deploying AFS, porting it to IBM
    mainframes, transitioning from K4 to K5, and migrating to DCE/DFS, yes,
    some of the software is a little easier to use now, but also it's clear
    that the population of people trying to use Kerberos are more familiar
    with Kerberos now than they were back then.

    Of course compartmentalization is an important aspect in designing a
    secure system, and keeping security info isolated can be beneficial.

    But there's also a real demand for SSO and a real need for easier
    manageability of otherwise far-flung diverse user information. There's
    also a good argument for putting all your eggs in one basket and
    Guarding that basket.

    > However, conversely, I would love to see a LDAP replacement for the
    > kadmin protocol. I am not looking for an LDAP implementation worthy of
    > being called a true directory server, but rather simply a GSSAPI
    > authenticated, TLS protected, LDAP enabled interface for
    > adding/removing/managing users/acls/policies within the existing
    > Kerberos database.
    >
    > I pondered a back-kadmin for OpenLDAP for a while, but my C skills are
    > rather rusty. Has anyone else considered this path, or is it just a bad
    > idea?


    At this point I would consider it wasted effort when full KDC
    integration already exists. If you still want
    isolation/compartmentalization, just use a separate slapd database for
    the KDC info. You get the same degree of isolation but you still have
    all of the flexibility that a full LDAP service provides - replication,
    fine-grained access control with delegation, etc. etc.

    Yes, there are tradeoffs. Making an LDAP query that eventually gets
    handled by a BerkeleyDB will probably (but not necessarily) be slower
    than just calling BerkeleyDB directly. In exchange for this trade, you
    get more flexibility. For sites trying to manage credentials for Unix
    systems, Samba/Windows and miscellaneous other ID management purposes,
    this trade is a net win. Any time you create an additional thing to
    manage, you lose. Any time you can consolidate/eliminate one thing to
    manage, you win.
    --
    -- Howard Chu
    Chief Architect, Symas Corp. http://www.symas.com
    Director, Highland Sun http://highlandsun.com/hyc
    OpenLDAP Core Team http://www.openldap.org/project/


+ Reply to Thread