On Mon, 2004-03-01 at 22:21, Love wrote: > Andrew Bartlett <abartlet@samba.org> writes: > > > On Sun, 2004-02-29 at 23:57, Love wrote: > >> Andrew Bartlett <abartlet@samba.org> writes: > >> > >> > Oops - I'll need to learn a bit more about how HDBentry works :-) > >> > >> Its more asn1/der. Heimdal's asn1_compile have implicit continuations (...) > >> so parsing data is just fine, however it wont be preserved, nor it will the > >> kdc properly reject data when it doesn't understand a critical extension. > > > > Would you consider merging my patch if I removed the extra attributes > > (which I don't use yet)? > > I considering to include your patch in heimdal doing some merge of your > patch and the proposal I have. We have to break forward compatibility at > some time (with something like hdb-extensions). There are changes that are > already not put into the tree because of this issue (per principal > configurable iteration counter for AES s2k, pkinit acl's, etc). > > Reading the ldap patch I think you break backward compatibility with the > old code, like you changed how the Key was stored, to hex encoded data from > raw octets. sambaNTpassword is hex encoded, but the krb5Key should still be raw octects. It should be raw octets inside HDBEntry. Can you point out exactly what you mean here? The only backward compatibility issue is that older Heimdal installations that query the same directory will not see the type-23 key, as it is in the sambaNTpassword. But this only happens when there is a sambaSamAccount on the entry. > > I was considering that the HDBentry in the hemidal database would simply > > not change, but that when using LDAP we would present a 'richer' > > interface. Otherwise, your proposal certainly makes sense. > > Ah, so you want a diffrent interface between libhdb and libkadm5 ? > > The hdb-structure is slighty entrenched into libkadm5 and the hprop/iprop > protocols. Also the kdc uses the hdb interface, so doing a new api seem to > be somewhat painful (based from a 2 min code review) What I was instead thinking was to continue expanding HDBEntry, but use a HDBEntry2OldHDBEntry function for db storage. > >> BTW, I've imported non ldap related parts of your patch. > > > > Thanks. > > > > How much 'samba stuff' are you willing to tolerate in Heimdal? > > > > For example, once we start updating the 'last change time', we should > > also update/honour the 'min password age' and 'must change time' > > attributes. (Ie, query the directory for those properties, and set them > > when we update the password). > > Many change that you propose above should really be part of Heimdal, so I > don't really see it as a problem to include them. Thanks. > As long as the patches are clean, sane, pretty, don't to horrible things > with abstraction layers, and that someone test them properly, I have no > problem including them i Heimdal. Also, including documentation is nice, at > least some framework for it, I really don't want to write all text myself. I can manage documentation :-) Andrew Bartlett -- Andrew Bartlett abartlet@pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet@samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net
This is a digitally signed message part