On Mon, 2004-03-01 at 23:57, Love wrote:
> Andrew Bartlett <abartlet@samba.org> writes:
>
> >> 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?
>
> Oh, sorry, it was a comment. I've still to get used to this "new" c99
> comments.
It's real ugly stuff too, but I was deep in LDAP errors, (hence the
change to the randkey code) and needed some idea what was really going
on :-)
> > 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.
>
> Shouldn't type-23 keys be stored in both entries ?
Perhaps they should. I'm a bit worried about storing duplicate data -
what do we do when they don't match. Now, that is pretty lame, as if
the two representations of the type-32 key don't match, then the DES
keys would also be in conflict with the NT password....
> >> 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.
>
> The "real" way of solving this should be doing something like this:
>
> hdb-extension ::= CHOICE {
> some-value[0] SomeType,
> some-value2[0] SomeType2,
> ...
> }
>
> hdb-extensions ::= SEQUENCE OF SEQUENCE ::= {
> mandatory[0] INTEGER, -- kdc MUST understand this extension
> extension[1] hdb-extension
> }
>
> and make sure sure that the asn1 library supports ... for CHOICE (and thus
> preserved data).
>
> Then the structure would be extented in and forward compatibility maner
> that old kdc would understand.
>
> However, the asn1 lib on head doesn't support CHOICE, thus by idea of using
> OCTET STRING instead. The joda-asn1-branch asn1_compile (used for pkinit)
> support CHOICE, but I'm not completely trust it since I'm not sure since
> the branch was done 2 years ago and all changes might not he pulled over
> From head.
>
> The db really need to store all the data, so using something like
> HDBEntry2OldHDBEntry wouldn't work.
OK.
BTW, I just dropped my patch into production at Hawker, and it seems to
work nicely. Now, it's not exactly at the core of my network, but
that's the beauty of the patch - Kerberos can just sit on the side of my
Samba databases, without major pain!
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