Issue with kvno
ghudson at mit.edu
Fri May 29 12:17:47 EDT 2015
Vishal found issue #7092 (worked around in 1.10.1) which may provide
and also provided a little more information. Apparently the incoming
kvno (I assume from the Ticket in an AS-REP) is encoded by Windows as
FF, and is sent outgoing (I assume as part of the Ticket in a TGS-REQ)
as 00 FF FF FF FF. No RODC is involved.
FF is the encoding of -1, not 255. I believe MIT krb5 1.10.1 and later
would round-trip this as FF, but I'm not sure if Windows would like that
either. Does the home domain have the kvno set to -1 for some reason?
What implementation of Kerberos is runing on that KDC?
On 05/29/2015 11:45 AM, Benjamin Kaduk wrote:
> I don't have a definite answer for you, but:
> 1.7 is very old.
> 4294967295 is 0xffffffff is -1 as a 32-bit twos-complement integer
> 255 is 0xff is -1 as an 8-bit twos-complement integer.
> kvnos are supposed to be unsigned integers, but krb5 prior to 1.10 (and
> evern moreso prior to 1.6) had bugs where they were treated as signed
> -Ben Kaduk
> On Thu, 28 May 2015, vishal wrote:
>> I did not get any answer for my query:
>> I see an issue with kvno with kerberos version 1.7 where linux server is
>> sending the kvno to trusted domain as 4294967295 while it gets this as 255
>> from home domain.
>> Is this an known issue?
>> On Tue, May 26, 2015 at 11:07 PM, vishal <vicky.recw at gmail.com> wrote:
>>> I see an issue with kvno with kerberos version 1.7 where linux server is
>>> sending the kvno to trusted domain as 4294967295 while it gets this as 255
>>> from home domain.
>>> Is this an known issue?
>> Kerberos mailing list Kerberos at mit.edu
> Kerberos mailing list Kerberos at mit.edu
More information about the Kerberos