MIT Kerberos LDAP backend - Kerberos

This is a discussion on MIT Kerberos LDAP backend - Kerberos ; Hi, we're looking into trying to integrate Kerberos with our existing user authentication/authorization systems, after seeing that there was an LDAP integration option, since all of our user data is available via LDAP. However on further reading I'm not 100% ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: MIT Kerberos LDAP backend

  1. MIT Kerberos LDAP backend

    Hi, we're looking into trying to integrate Kerberos with our existing
    user authentication/authorization systems, after seeing that there was
    an LDAP integration option, since all of our user data is available via
    LDAP.

    However on further reading I'm not 100% clear on how the integration
    works. Is it possible to just use the LDAP integration for user
    authentication without having to give Kerberos write access to LDAP?

    If write access is required, what information is stored in LDAP, and
    where? As extra data in a user's nod,e or in a separate subtree?

    --
    John Gilbertson
    The University of Liverpool

  2. Re: MIT Kerberos LDAP backend

    On Fri, Nov 02, 2007 at 12:03:50PM +0000, John Gilbertson wrote:
    > Hi, we're looking into trying to integrate Kerberos with our existing
    > user authentication/authorization systems, after seeing that there was
    > an LDAP integration option, since all of our user data is available via
    > LDAP.
    >
    > However on further reading I'm not 100% clear on how the integration
    > works. Is it possible to just use the LDAP integration for user
    > authentication without having to give Kerberos write access to LDAP?
    >
    > If write access is required, what information is stored in LDAP, and
    > where? As extra data in a user's nod,e or in a separate subtree?
    >

    I don't think that write access is a requirement. That is, I have not
    had to implement it like that. Here is the HOWTO I followed (more or
    less):

    http://aput.net/~jheiss/krbldap/howto.html

    Regards,

    -Roberto

    --
    Roberto C. Sánchez
    http://people.connexer.com/~roberto
    http://www.connexer.com

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

    iD8DBQFHK36+5SXWIKfIlGQRAvOZAJ9dIzg59bGfRyhIcNlqA7 qWQ3E7+ACgnAxw
    E4QabFpa6u9MBchFVAa+qys=
    =XXxt
    -----END PGP SIGNATURE-----


  3. Re: MIT Kerberos LDAP backend

    Roberto C. Sánchez wrote:
    > I don't think that write access is a requirement. That is, I have not
    > had to implement it like that. Here is the HOWTO I followed (more or
    > less):
    >
    > http://aput.net/~jheiss/krbldap/howto.html


    Thanks for the link, but I'm not sure if that will do what we need.
    We're not looking to replace NIS or the like, just add Kerberos as an
    authentication route for various programs with Kerberos support.
    The documentation is a touch vague about what each part is being used
    for, or how things actually talk to each other, I can't find the part
    where Kerberos and LDAP will actually communicate in any way.

    We have an LDAP tree with all our user info in, and want to be able to
    use programs which only know Kerberos to be able to authenticate against
    the data in LDAP.

    --
    John Gilbertson
    The University of Liverpool

  4. Re: MIT Kerberos LDAP backend

    On Nov 6, 2007, at 09:40, John Gilbertson wrote:
    > Thanks for the link, but I'm not sure if that will do what we need.
    > We're not looking to replace NIS or the like, just add Kerberos as an
    > authentication route for various programs with Kerberos support.


    Does this mean you're using LDAP for authentication, and looking for
    a way Kerberos programs can use the LDAP setup you've already got?
    That's not how the LDAP backend works; it's for doing authentication
    the Kerberos way, except the database is stored in LDAP. The data we
    store is entirely different from what LDAP authentication uses; you
    can't just layer one on top of the other.

    Ken

  5. Re: MIT Kerberos LDAP backend

    On Thu, 8 Nov 2007, Ken Raeburn wrote:

    > On Nov 6, 2007, at 09:40, John Gilbertson wrote:
    >> Thanks for the link, but I'm not sure if that will do what we need.
    >> We're not looking to replace NIS or the like, just add Kerberos as an
    >> authentication route for various programs with Kerberos support.

    >
    > Does this mean you're using LDAP for authentication, and looking for a way
    > Kerberos programs can use the LDAP setup you've already got? That's not how
    > the LDAP backend works; it's for doing authentication the Kerberos way, except
    > the database is stored in LDAP. The data we store is entirely different from
    > what LDAP authentication uses; you can't just layer one on top of the other.
    >
    > Ken


    Thanks for clearing this up, the documentation wasn't entirely clear
    about how the LDAP module worked or what it's intended use was for.
    We had been hoping that it woudl provide a painless way to get a
    Kerberos-aware interface to our user directory.

    Do you know of any other method whereby we would be able to effectively
    let Kerberos delegate the authentication step to LDAP, and then carry on
    as if that part had been done itself?

    Or is the only solution to duplicate all user data into Kerberos, and
    then frequently sync the two?

    --
    John Gilbertson
    The University of Liverpool



  6. Re: MIT Kerberos LDAP backend



    John Gilbertson wrote:
    > Roberto C. Sánchez wrote:
    > > I don't think that write access is a requirement. That is, I have not
    >> had to implement it like that. Here is the HOWTO I followed (more or
    >> less):
    >>
    >> http://aput.net/~jheiss/krbldap/howto.html

    >
    > Thanks for the link, but I'm not sure if that will do what we need.
    > We're not looking to replace NIS or the like,


    If you did, search for nss-ldap.

    > just add Kerberos as an
    > authentication route for various programs with Kerberos support.
    > The documentation is a touch vague about what each part is being used
    > for, or how things actually talk to each other, I can't find the part
    > where Kerberos and LDAP will actually communicate in any way.


    If you are trying to authenticate ldap client to ldap server using Kerberos,
    search for SASL and GSSAPI.

    >
    > We have an LDAP tree with all our user info in, and want to be able to
    > use programs which only know Kerberos to be able to authenticate against
    > the data in LDAP.


    Not sure what you mean here as you have responded to Ken that its
    not the KDC access to its data stored in LDAP that you are interested in.

    Kerberos does authentication. LDAP can be used for authentication using
    passwords stored in LDAP, but is also used for authorization. So using pam_krb5
    with nss-ldap can work well for login.

    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

  7. Re: MIT Kerberos LDAP backend

    Douglas E. Engert wrote:
    > Not sure what you mean here as you have responded to Ken that its
    > not the KDC access to its data stored in LDAP that you are interested

    in.

    I think maybe some wires have been crossed, and I have not described
    what the issues are as well as I may have liked. We do want to use the
    KDC, but for it to access our pre-existing data in LDAP, but not write
    anything there.

    Currently our route for authenticating users for various things (online
    mostly) is to authenticate against LDAP. Our user data is actually in
    Novell eDirectory, but the LDAP interface is the preferred method for
    access.

    However we have a long term plan of rolling out an SSO service, and
    thought Kerberos would be best suited as there seems to be many Kerberos
    aware systems, and we may in the long term be moving to Active Directory
    (and ADFS) which I believe is (sort of) Kerberos which would give us an
    even greater scope of using Kerberos including for system logins.

    So what we would have liked is for a web-based user to go to one of our
    web applications that requires authentication and for them to
    authenticate in a way that ends up with them having a valid Kerberos
    ticket somehow for other Kerberos aware applications, so they don't get
    asked for user/pass again in a session.

    And we had hoped this could be achieved without having to create a
    duplication of all our user data into a Kerberos specific database, or
    for Kerberos to require to add any data to our LDAP server since it's
    basically read-only as it's populated from elsewhere.

    >From what I read of the Kerberos LDAP backend plugin, is that it can't

    just be configured to look at our existing LDAP server and it's
    associated structure when a user tries to login to something via
    Kerberos, and use its own non-LDAP database for tickets and whatever
    other information is needed.

    --
    John Gilbertson
    The University of Liverpool

  8. Re: MIT Kerberos LDAP backend

    In article ,
    Mr J.A. Gilbertson wrote:
    >On Thu, 8 Nov 2007, Ken Raeburn wrote:
    >
    >Do you know of any other method whereby we would be able to effectively
    >let Kerberos delegate the authentication step to LDAP, and then carry on
    >as if that part had been done itself?
    >


    All kerberos does is authentication. There have been some efforts
    to use LDAP as the back end data store for a KDC, but I don't
    know how successful they are. Doing it in a reasonably secure
    fashion would also require some very careful work. I think the
    heimdal code has some experimental support for this.

    Most sites that use LDAP and Kerberos either use Active Directory ( which more
    or less has this integration already) or use kerberos for
    authentication and LDAP for authorization. There is a sync
    process usually that creates accounts for users in both services.

    I don't think there is really any practical way to use LDAP
    username/password authentication inside of kerberos. Mostly since
    the password never leaves the local machine in the kerberos
    protocol.

    There's a project out there that attempts to duplicate all of
    Active Directory with open source software. I've forgotten the
    name (padl.com ?), but you might look at that to understand
    what's available and the underlying problem.

    _ Booker C. Bense



  9. Re: MIT Kerberos LDAP backend

    In article ,
    Mr J.A. Gilbertson wrote:

    >
    >And we had hoped this could be achieved without having to create a
    >duplication of all our user data into a Kerberos specific database, or
    >for Kerberos to require to add any data to our LDAP server since it's
    >basically read-only as it's populated from elsewhere.
    >
    >>From what I read of the Kerberos LDAP backend plugin, is that it can't

    >just be configured to look at our existing LDAP server and it's
    >associated structure when a user tries to login to something via
    >Kerberos, and use its own non-LDAP database for tickets and whatever
    >other information is needed.
    >


    You would have to write a whole bunch of code to make that work
    and sync'ing passwords/keys between the two systems would be even
    more work. Please don't take this the wrong way, but the fact
    that you're asking this question leads me to believe that you
    really don't understand the kerberos protocol at all. I'm not
    saying you need to know the bit fields on the wire to deploy it,
    but to use it successfully you really need to understand some
    basic details about what it can and can't do.

    _ Booker C. Bense

  10. Re: MIT Kerberos LDAP backend

    [ Replying to both of your emails at once ]

    > Do you know of any other method whereby we would be able to
    > effectively
    > let Kerberos delegate the authentication step to LDAP, and then
    > carry on
    > as if that part had been done itself?


    I think you're misunderstanding the way that Kerberos works. Kerberos
    is an authentication system, and a cryptographically based one at
    that. It requires having access to the users password in order to
    perform the encryption operations that it's security is based on. You
    can't defer these operations to another source to say "is this
    password correct". I suppose it would be technically feasible to have
    Kerberos use an external password store (it would require access to
    the plaintext of all of these passwords), and generate its keys on
    the fly, but as far as I'm aware no-one has done this work.

    > Or is the only solution to duplicate all user data into Kerberos, and
    > then frequently sync the two?


    Kerberos doesn't hold user data in the same way that something like
    LDAP does. All Kerberos holds is the user's principal (usually
    derived from their username), a set of keys (derived from the
    password), and a set of flags controlling the way in which that
    principal may be used. The Kerberos database tends to get populated
    either with an account provisioning system, or creating entries based
    on an LDAP data store. Normally Kerberos would be the authoritative
    password source, with LDAP deferring authentication operations to
    Kerberos - however it is entirely possible that you could maintain
    passwords both in Kerberos and LDAP, and keep this in sync, either by
    running code on both your KDC and LDAP servers to intercept password
    change, or by forcing all password changes to go through a central form.

    >
    > So what we would have liked is for a web-based user to go to one of
    > our
    > web applications that requires authentication and for them to
    > authenticate in a way that ends up with them having a valid Kerberos
    > ticket somehow for other Kerberos aware applications, so they don't
    > get
    > asked for user/pass again in a session.


    Kerberos and the web don't currently play that well together. Most
    organisation's web-SSO solutions that I'm aware of use technologies
    such as Cosign (from the University of Michigan) or WebAuth
    (Stanford) to translate the Kerberos authentication that's happening
    behind the scenes into cookie based authentication that works with
    all of today's web browsers. It's worth noting that there's no easy
    way for an authentication operation against a remote web site to
    result in Kerberos credentials being created on the local machine.

    However, if you're purely interested in Web based applications, you
    _may_ be able to deploy a web SSO technology without needing to have
    it backed with Kerberos. Cosign, in particular, can support pretty
    much any password database in order to authenticate users. The
    complication arises, however, if your web applications have to
    perform operations on behalf of the user. In the situation where the
    user gives their password to every web site, then that web site can
    easily use that password to gain access to other services on behalf
    of the user (whether the user want's them to or not). This is
    typically used for applications such as webmail, where the web mail
    site uses the user's password to access an IMAP server as the user.
    If you're using web-SSO, then the application never sees the user's
    password, and so can't do this. When you're working with Kerberos,
    the web-SSO system gets round this by giving the application the
    user's Kerberos credentials, allowing other Kerberos enabled services
    to be accessed as the user. This is accomplished without the site
    getting to know the user's long term password, which is a significant
    security gain. If you don't have Kerberos, then you won't be able to
    do this - you'd need to either modify all of your backend services to
    accept cosign proxy authentication, or allow your web sites to simply
    assert identities. It all depends on what you're trying to do.

    We've been through this dance at the University of Edinburgh both in
    Informatics (where I work) and centrally. I'd be happy to talk to you
    further if you'd like more information.

    Cheers,

    Simon.


+ Reply to Thread