directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From g..@hurderos.org
Subject Re: [Kerberos] Kerberos + OpenLDAP
Date Fri, 02 Mar 2007 19:31:52 GMT
On Mar 1, 11:45am, "Alex Karasulu" wrote:
} Subject: Re: [Kerberos] Kerberos + OpenLDAP

> Hi Greg,

Hi Alex, hope the day is going well for you.

> > > <enriquer9@gmail.com> wrote:
> > >
> > > > Use 'ldap' for LDAP:
> > > > krb5PrincipalName: ldap/www.example.com@EXAMPLE.COM
> >
> > > Although this is the attribute I use for my OpenLDAP directories, I
> > > will note that this attribute is not the part of any RFC standard.
> > > In fact, there is no RFC standardized way of storing Kerberos
> > > principals in a directory that I'm aware of.  I raised this issue to
> > > MIT and Heimdal once, and apparently they are "working" on
> > > something.  But that was several years ago.

> > The situation may have effectively changed now.

> I hope so as Enrique described this schema we're now using is very
> limiting.

I'm not sure its as much limited as it doesn't fully describe all the
information needed to implement an administrative interface for a KDC.

Once you you begin to get into some of the mechanistic details of what
it means to manage a KDC there are open questions which need to be
dealt with.

> > I'm polishing off the details of a kadmin back-end for OpenLDAP.  The
> > goal of this work is to be able to manage an MIT KDC implementation by
> > running an OpenLDAP server rather than kadmind on the KDC.  Putting
> > this into effective use requires some thought on how to develop an LDAP
> > based abstraction for a KDC entry.

> Excellent.  Is this happening on some mailing list we can watch to
> see your progress or is this just things you're doing by yourself.
> If you like, feel free to work it out here at Directory's dev list:
> if you think that will attract more people interested in these
> aspects.

Its pretty much happening here.  I sometimes copy the Kerberos
development list at MIT if there are issues of mututal interest.  I
see Sam Hartman sent a note indicating there would be passing interest
from the perspective of MIT for an LDAP administrative interface.

Regardless of whats actually implementing the KDC I believe there are
a number of issues of common interest which need to be addressed for
an LDAP centric method of managing a KDC is to evolve.  Keytab
management is of course on of the front and center issues.

> I looked at a number of schema representations.  Its not an RFC but
> > the most logical abstraction to use seemed to be the schema which
> > Novell developed for the LDAP back-end to MIT Kerberos.  The 1.6
> > sources have the schema in the following location:
> >
> > krb5-1.6/src/plugins/kdb/ldap/libkdb_ldap/kerberos.schema

> Is this in the MIT code base?

The above reference is with respect to the parent directory created by
therelease tarball available from MIT's site.

> I believe some effort was placed into coordinating schema details
> > between Novell, SUN, MIT and Heimdal if I'm not mistaken.
> >
> > I'm still sorting details but the schema seems to be sufficient to
> > support abstracting MIT kadmind functionality into an LDAP interface
> > definition.  Although mechanistically different ADS is essentially
> > faced with the problem of presenting the same type of abstraction.

> Indeed.  Right now we have virtually no interface at all.  Basically
> we have filters for generating keys for Kerberos entries that take
> effect on the import of such entries during startup.  Yeah it's not
> very useful as it stands.
>
> At some point I wanted to develop a tool for doing this but time
> constraints did not permit it and after all the tool would have to
> leverage the Kerberos infrastructure via changepw to securely create
> accounts and administer them.
>
> I think Enrique and I discussed the potential for this a while back.

For ADS to get 'real' as a Kerberos implementation there will be some
issues which need to be addressed.

Our work on an LDAP interface for an MIT/KDC has to address some of
the some issues your work does so I hope to feedback the results of
some of our work to your codebase if they prove suitable.

Most of the administrative functionality should be orthogonal to
changepw.  Based on our work and testing with the OpenLDAP interface
most of the management functionality can be abstracted to object
creation/deletion combined with attribute modification.

The exception, of course, is password creation/modification.  Since a
KDC doesn't deal with passwords per se but rather keys derived from
the password there is technically a requirement for an algorithmic
action when a password manipulation event needs to be processed.

It actually struck me last night when I was cross-country skiing with
my dog Iggy that administrative password modification could be done
with strictly an LDAP interface.  It would require a client which
understood the types of keys which the KDC wanted but that shouldn't
be a show stopper.  The client could be simply distributed as a tool
with ADS or whatever server was being used.

It should actually be trivially easy for the directory to 'advertise'
the types of keys required by whatever KDC implementation is being
fronted by an LDAP interface.  That would allow newer clients to
support older versions of a KDC.

> > It would seem logical for all these efforts to converge on a common
> > schema.  The above schema may be as good a place to start as any.

> Yes the schema would give us another route through which we could
> effectively manage Kerberos accounts.
>
> I know a common schema is a good thing overall regardless of whether
> the changes are taking place via LDAP or via Changepw.  However are
> there any foreseeable disadvantages to using LDAP verses Changepw
> with this new schema or another?

As I mentioned above I think the two concepts are somewhat orthogonal
in character.

I believe ChangePw is best desribed as a standardized
interface/protocol for executing password changes.  The schema which
I'm discussing is a method for describing data elements or objects
needed to manage a Kerberos authentication identity.

Other than the fact its a standardized protocol I'm not sure ChangePw
would be needed in a purely LDAP managed Kerberos environment.  One of
the things which ChangePw needs to do is authenticate the user.  If an
authenticated BIND by the user is required to their Kerberos
management object the same effect would be accomplished.  The only
left is to translate the password attribute modification into a key
generation action.

> Alex

I'll keep the list up to date with respect to how the work is going.
I was hoping to work with things a bit this weekend but the three feet
of snow which the current blizzard is depositing in the farmstead yard
is suggesting otherwise... :-)

Have a good weekend.

}-- End of excerpt from "Alex Karasulu"

As always,
Greg Wettstein

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"Much work remains to be done before we can announce our total failure
 to make any progress."
                                -- Mike Kelly

Mime
View raw message