Unable to use keytab because the client keytab's kvno doesn't match the server's kvno

[chaimmintz]

Hi,

I am trying to use a keytab and I get the following error:
kerberos login failed: couldn't log in: [Root cause: Decrypting_Error] KRBMessage_Handling_Error: AS Exchange Error: AS_REP is not valid or client password/keytab incorrect < Decrypting_Error: error decrypting EncPart of AS_REP < Decrypting_Error: error decrypting AS_REP encrypted part: matching key not found in keytab. Looking for [<redacted>] realm: <redacted>.COM kvno: 4 etype: 18

The same keytab works with kinit and other kerberos-aware apps I use. The problem seems to be that the server sends kvno=4 in the AS_REP message (maybe because I changed my password a few times?), but the kvno in the client keytab is 1 because it is a fresh keytab. It seems wrong that these two number would have to match in order to be able to use the keytab given that this same keytabs works elsewhere. I can change the kvno in the client keytab to match the server but that seems very fragile and shouldn't be necessary.

Any idea?
Thanks

[jcmturner]

kinit ignores the kvno but my understanding is that is not the correct behaviour...

The RFC implies that these should match

https://datatracker.ietf.org/doc/html/rfc4120#section-3.2.3

[MikhailMS]

@jcmturner just following on exactly same issue

The RFC 4120 @ Section 3.2.3 doesn't actually mentions KVNO at all if I read it correctly (and cannot really see kvno mentioned in that RFC in the conext of this issue)

However, RFC 7751 says that we SHOULD do the kvno comparaison
IMO, it means that there should be a way to ignore KVNO comparison, especially when there are tools our there that do ignore kvno: not just kinit, for example when using Java to authenticate it ignores KVNO and so does Windows

[karman-docker]

@MikhailMS I hit the same issue and reported here #539. Wondering if you found any way to workaround this ? Is there a way to ignore kvn ?