Heimdal compatibility

Andrew Bartlett abartlet at samba.org
Wed Aug 16 18:13:43 EDT 2006

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.

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

>     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.

Oh?  Why is that?  Because it is exactly the kind of thing I expect to
see folks like eDirectory wanting to do, and exactly how I would design
any central identity server.  Naturally, they would call some kerberos
libs to do the crypto manipulations, but there are very good reasons to
do an in-process, in-place atomic modify of all password attributes at

I felt the same about other projects (like PHP-based admin tools)
updating Samba's password attributes, but I would feel much better about
these projects being told to call the directory server, and getting it
right *once* in a lib the directory server can call.

Making this a network callout to my mind makes this harder and less safe
to implement, which increases the chance it won't happen 'right' in the
directory server, and increases the chance that it ends up back in the
kind of mess we currently are in (sync protocols).

Andrew Bartlett
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20060817/182384f0/attachment.bin

More information about the krbdev mailing list