Heimdal compatibility

Sam Hartman hartmans at MIT.EDU
Thu Aug 17 14:04:43 EDT 2006

>>>>> "Andrew" == Andrew Bartlett <abartlet at samba.org> writes:

    Andrew> On Wed, 2006-08-16 at 15:16 -0400, Sam Hartman wrote:
    >> >>>>> "Andrew" == Andrew Bartlett <abartlet at samba.org> writes:
    Andrew> Has anything more happened on this?
    >>  Novell responded explaining why it was different between MIT
    >> and Heimdal and you never responded to that.

    Andrew> I must have missed that mail.  I'll try and dig it up.
    Andrew> Which list was it on?

The basic issue is that MIT supports multiple kvnos and Heimdal does

    Andrew> I'm not as worried about the broader question of schema
    Andrew> compatibility (but it would be nice) as I am about this
    Andrew> particular attribute (and perhaps a representation of the
    Andrew> password's last changed time).  That is, these are
    Andrew> attributes that an LDAP server might be expected to write
    Andrew> to, if it were to implement a single password for multiple
    Andrew> protocols.
    >> I would feel very uncomfortable with the LDAP server updating
    >> this directly.  I think that the right way to handle this would
    >> be to standardize a way for LDAP servers to call out to KDCs to
    >> ask them to update their password attribute.  Possibly the set
    >> password protocol Nico is working on is sufficient; possibly it
    >> is not.
    >> I definitely don't want to see this particular attribute
    >> modified by the server.

    Andrew> Oh?  Why is that?  Because it is exactly the kind of thing
    Andrew> I expect to see folks like eDirectory wanting to do, and
    Andrew> exactly how I would design any central identity server.

Because I think you want the Kerberos implementation involved in
maintaining the Kerberos implementation's invariants.  I don't care if
this is a network callout or a directory server plugin, but I believe
the code that updates the password needs to be supplied by the KDC
vendor not the directory vendor.


More information about the krbdev mailing list