Je suis sceptique quant au fait que le KVNO ait quelque chose à voir avec votre problème, OK peut-être avec des clients Linux, mais quoi qu’il en soit, utilisez Wireshark/Network Monitor :
Les numéros de version de clé sont décrits dans MS-KILE section 3.1.5.8.
Au passage, Mathias R. Jessen a raison en ce sens que Windows ignore typiquement les KVNO. Mais ils sont quand même implémentés de manière conforme aux RFC.
https://docs.microsoft.com/en-us/archive/blogs/openspecification/to-kvno-or-not-to-kvno-what-is-the-version
Non, Windows ne prête pas attention au KVNO. Il l’ignore simplement.
Mais le KVNO a une certaine importance dans un environnement RODC :
https://docs.microsoft.com/en-us/archive/blogs/openspecification/notes-on-kerberos-kvno-in-windows-rodc-environment
Plus d’informations ici : https://web.archive.org/web/20150204183217/http://support.microsoft.com/kb/2716037
Dans un environnement avec un ou plusieurs RODC, l’authentification peut échouer lors de
l’interaction avec certains appareils Kerberos basés sur MIT dans l’un des
scénarios suivants.
Le client est un appareil MIT qui a reçu un TGT du
KDC Windows sur le RODC
Le client transmet un TGT généré par le KDC Windows sur le RODC à un
appareil MIT qui utilise ensuite le TGT pour demander un TGS au nom de
l’utilisateur appelant.
Dans les deux scénarios, le TGT aura été émis par un RODC où le
msDS-SecondaryKrbTgtNumber associé au compte krbtgt pour ce
RODC aura une valeur supérieure à 32767.