In 6893158 we add a restriction that the Kerberos service side needs to check if the KVNO presented in the AP-REQ matches the KVNO in its own keytab file, and rejects the AP-REQ if unmatched. This is specified in RFC 4120 Section 3.2.3:

                                If the key version indicated by the
   Ticket in the KRB_AP_REQ is not one the server can use (e.g., it
   indicates an old key, and the server no longer possesses a copy of
   the old key), the KRB_AP_ERR_BADKEYVER error is returned.

In most production environments, the keytab on the service side is generated using kadmin (or on Windows, ktpass.exe) by directly exporting the key materials from the Kerberos database, and thus should contain the correct KVNO value.

On the other hand, We do have a ktab.exe command included in the Windows release of JDK. For a keytab generated using ktab.exe, currently the KVNO inside is generated by the ktab command (incremented each time ktab is called), and quite likely DO NOT match the value inside the KDC's database.

ktab.exe is mainly used on the initiator (client) side for automatic logon, in which the KVNO is not used in AP-REQ check at all. However, this keytab can also be used in the acceptor (service) side for user-to-user authentications, and a BADKEYVER error is possible.

Two actions can be made:

1. Add a fallback mechanism to AP-REQ processing that when no KVNO match is available, fallback to another key with the same etype and principalname (but different KVNO).

2. Enhance ktab.exe so that user has more control over KVNOs of keys generated. If user knows the exact KVNO, he can assign the KVNO directly. Otherwise, he can choose to use 0 since it's always accepted by Java.