Kerberos 1.7 and later does not interoperate with AD Read-only DCs
ghudson at MIT.EDU
Tue Feb 21 13:10:02 EST 2012
On 02/20/2012 09:54 PM, Adam Bernstein wrote:
> Interestingly, this problem does not reproduce using Kerberos 1.6.
In krb5 1.6 we encode by casting the kvno value (an unsigned int) to
int, then encode it as a signed value. There is a comment saying
"krb5_kvno should be int". We decode this field as a signed long and
then cast the result to an unsigned int. (That means we reject
RFC4120-conformant kvno values >= 0x80000000 on platforms where long is
In krb5 1.7-1.10, as you noted, the encoder treats the field as an
unsigned 32-bit integer, which conforms better to RFC 4120 but generates
TGS requests which don't interoperate with RODCs using RodcIDs >=
0x8000. The decoder behavior hasn't changed.
In the trunk, we encode and decode the kvno value as unsigned 32-bit
numbers, which means we would probably reject the AS reply from an RODC
with RodcID >= 0x8000.
I think the most practical solution is to restore the 1.6 behavior,
treating kvno as a signed 32-bit value when encoding and decoding.
Although this conflicts with RFC 4120, I think RODCs are the only case
where kvno values that large are likely to appear in the wild. If
you're in a position to test patches, I will run them by you.
(As an aside, Heimdal appears to treat the EncryptedData kvno field as
unsigned 32-bit, conformant to RFC 4120. It probably also doesn't
interoperate with RODCs with RodcID >= 0x8000.)
More information about the krbdev