Assuming the OSF/DCE has not completely taken out the V4 string-to-key
option that was part of the V5 spec, there may still be a chance of some
interoperability. The support for handling V4-style ticket requests may
require additional compilation options and may not be enabled, but did
they also disable the additional salt-type/salt-data functionality
provided in the V5 spec? I think only OSF can answer that one...
Well, actually, I can answer that: the additional salt-data field is
retained, and the DCE KDC supports user-defined salts. We depend on
this to allow principals to be renamed. It does not have the full
functionality of the multiple salt-type support in V5 beta.
Aside from that, there is no support in any of the administrative
tools to set the salts to anything but the default; however, you can
roll your own using the DCE API. Unfortunately, there was a bug in
dce1.0.1 and earlier with zero-length salts (i.e., V4 string-to-key);
this has been fixed in 1.0.2, which has not yet been released from OSF
(I don't think I can comment on exactly when; ask OSF for details).
The V4 compatibility code in DCE is turned off because it didn't "just
work" the first time I tried to build it, mostly due to some minor
gratuitous changes we made to the KDC-database interface. If you want
it to work "for real", ask OSF or your DCE vendor for V4 compatibility
support (and they'll come beating down my door to get it working..).
IMHO, the Transarc string-to-key algorithm is a non-standard
aberration, and should be flushed as soon as possible; I see no reason
to support it in the DCE.
On another note, maybe I *did* write asetkey; however, I don't think I
ever used it..
- Bill
