The previous fix was incomplete. But it also finally uncovered an
old check-des problem that I'd had once and which may have gotten
papered over by changing the default of one of the *strongest* KDC
parameters. The old problem is that we were passing the wrong
enctype to _kdc_encode_reply(): we were passing the session key
enctype where the ticket enc-part key's enctype was expected.
The whole enctype being passed in is superfluous anyways. Let's
clean that up next.
When I added support for configuring how the KDC selects session,
reply, and ticket enc-part keys I accidentally had the KDC use the
session key selection algorithm for selecting the ticket enc-part
key. This becomes a problem when using a Heimdal KDC with an MIT
KDB as the HDB backend and when the krbtgt keys are not in
strongest-to-weakest order, in which case forwardable tickets minted
by the Heimdal KDC will not be accepted by MIT KDCs with the same
KDB.
We don't need a cast in that case.
Before commit 1124c4872d
(KVNOs are krb5uint32 in RFC4120, make it so),
we compared krb5int32 casted to size_t with unsigned int,
which resulted in the following problem:
Casting krb5int32 to (size_t) is wrong, as sizeof(int)==4 != sizeof(size_t)== 8.
If you cast negative int values to size_t you'll get this:
int ival = -5000; // 0xFFFFEC78
size_t sval = (size_t)ival; // this will be 0xFFFFFFFFFFFFEC78
So we better compare while casting to (unsigned int).
This is important for Active Directory RODC support,
which adds a random number into the higher 16-bits of the
32-bit kvno value.
metze
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
We need to use the name that the HDB entry returned, otherwise we
will not canonicalise the reply if requested.
Andrew Bartlett
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
