One importnat point I missed that we see this issue only when we create new trust between domain and join linux box to domain, only in that case kvno comes in TSG-RESP , when trust is already present kvno does not come in TGS-RESP. I am not sure under what cases kvno should come.
On Fri, May 29, 2015 at 11:16 AM, vishal <vicky.r...@gmail.com> wrote: > Hi Greg, > > Thanks for reply. Let me explain this issue in detail: > > 1. Windows version is 2008r2 as domain controller. > > 2. We get the ticket in TGS-RESP with kvno 255, this TGS-REQ was sent for > krbtgt for trusted domain from linux box. > 3. Now when we send this ticket in TGS-REQ to tursted domain for ldap > service we modify kvno to 4294967295 . > > We do not see this issue with kerberos 1.6.3. It sends kvno as 255 to > trusted domain (step 3) and windows kdc likes this packet. > > > > I got one old blog : > > http://kerberos.996246.n3.nabble.com/Kerberos-1-7-and-later-does-not-interoperate-with-AD-Read-only-DCs-td23528.html > > Should I try this fix? > > > > Thanks, > > Vishal > > > On Fri, May 29, 2015 at 9:17 AM, Greg Hudson <ghud...@mit.edu> wrote: > >> Vishal found issue #7092 (worked around in 1.10.1) which may provide >> some clues: >> >> http://krbdev.mit.edu/rt/Ticket/Display.html?id=7092 >> http://mailman.mit.edu/pipermail/krbdev/2012-February/010699.html >> >> 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 >> > quantities. >> > >> > -Ben Kaduk >> > >> > >> > On Thu, 28 May 2015, vishal wrote: >> > >> >> Hi, >> >> >> >> I did not get any answer for my query: >> >> >> >> " >> >> Hi, >> >> >> >> 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? >> >> >> >> Thanks, >> >> Vishal" >> >> >> >> >> >> >> >> On Tue, May 26, 2015 at 11:07 PM, vishal <vicky.r...@gmail.com> wrote: >> >> >> >>> Hi, >> >>> >> >>> 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? >> >>> >> >>> Thanks, >> >>> Vishal >> >>> >> >> ________________________________________________ >> >> Kerberos mailing list Kerberos@mit.edu >> >> https://mailman.mit.edu/mailman/listinfo/kerberos >> >> >> > ________________________________________________ >> > Kerberos mailing list Kerberos@mit.edu >> > https://mailman.mit.edu/mailman/listinfo/kerberos >> > >> > > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos