On 11/7/2014 12:42 PM, Benjamin Kaduk wrote: > On Fri, 7 Nov 2014, Brandon Allbery wrote: > >> On Fri, 2014-11-07 at 11:15 -0600, Andrew Deason wrote: >>> It seems likely the 0 kvno is the problem. We only copy in a principal >>> if the kvno in the keytab is greater than 'vno' in >>> akimpersonate.c:pick_principal, which starts out at 0. I assume that's >>> valid and we just hadn't encountered this yet? >> >> I don't think it's supposed to be possible to have a kvno of 0 with a >> true Kerberos (4 or 5). kaserver, on the other hand, considered it valid >> and used 0 as the initial kvno; this has caused problems for me in the >> past when migrating from kaserver to Kerberos. > > If I remember correctly, kvno 0 was used by certain versions of windows' > krb5 implementations, but the Unix krb5 implementations do not generate it > without manual override. > > -Ben
Key version number 0 means use the latest key. It is a valid number for a key tab entry and should not result in a crash. Windows Server 2000 did not support key version numbers and all references to a key version number were 0. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
