>>>>>> "Luke" == Luke Howard <[EMAIL PROTECTED]> writes:
>
> Luke> Last time I looked into it, the MIT backend API was nowhere
> Luke> near as simple as Heimdal's. So, we are very unlikely to do
> Luke> so.
>
>Chicken :)
Well, why don't you just use Heimdal? Unless you are a vendor with
an existing investment in MIT Kerberos, I would not expect this to
be a major problem; you can still keep your MIT clients. :-)
>I doubt that I have the time to take a look at it, but any quick
>pointers on where/how you did it for Heimdal?
Yes, see:
http://www.padl.com/Research/Heimdal.html
The schema is included with OpenLDAP as krb5-kdc.schema. The
source code for the backend is part of Heimdal and has been
for almost three years now. (Note that it will not work with
OpenLDAP 2.1.x; you'll need to use 2.0.x for now.)
We don't actively maintain this backend; we have an internal
LDAP KDC backend that uses a different schema, and that's
where our efforts are focused at present.
Essentially, the KDC communicates with the LDAP server over
domain sockets (or some other form of IPC; we're thinking of
doing an LDAP over Doors implementation). This was done more
for authorization reasons than performance, although it may
be a little faster than TCP.
The LDAP schema is designed to let you keep Kerberos, UNIX
and general person information in the same entry, should you
wish. Kerberos keys are stored as ASN.1 encoded values of
the krb5Key attribute (really, we should probably have made
this a single-valued attribute storing a SEQUENCE of keys).
This schema is somewhat simpler than the IETF proposed
Kerberos LDAP schema, but I think in this case simplicity
is not such a bad thing.
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
________________________________________________
Kerberos mailing list [EMAIL PROTECTED]
http://mailman.mit.edu/mailman/listinfo/kerberos
