Solución 1:
Con los cmdlets AD de PowerShell, es posible consultar kvno:
get-aduser <username> -property msDS-KeyVersionNumber
Solución 2:
No puedo creer que KVNO tenga algo que ver con tu problema , OK, tal vez con clientes Linux, pero de todos modos, use Wireshark/Network Monitor:
Los números de versión clave se describen en la sección 3.1.5.8 de MS-KILE.
Por cierto, Mathias R. Jessen tiene razón en que Windows generalmente ignora los KVNO. Pero todavía se implementan en una forma de queja RFC.
https://docs.microsoft.com/en-us/archive/blogs/openspecification/to-kvno-or-not-to-kvno-cuál-es-la-versión
No, Windows no presta atención a KVNO. Simplemente lo ignora.
Pero el KVNO tiene cierta importancia en un entorno RODC:
https://docs.microsoft.com/en-us/archive/blogs/openspecification/notes-on-kerberos-kvno-in-windows-rodc-environment
Más información aquí:https://web.archive.org/web/20150204183217/http://support.microsoft.com/kb/2716037
En un entorno con uno o más RODC, la autenticación puede fallar al interactuar con ciertos dispositivos Kerberos basados en MIT en uno de los siguientes escenarios.
· El cliente es un dispositivo MIT que recibió un TGT de Windows KDC en RODC
· El cliente pasa un TGT generado por Windows KDC en RODC al dispositivo MIT que, a su vez, usa el TGT para solicitar un TGS en nombre del usuario que llama.
En ambos escenarios, el TGT habrá sido emitido por un RODC donde el msDS-SecondaryKrbTgtNumber asociado con la cuenta krbtgt para ese RODC tendrá un valor superior a 32767.
Solución 3:
En Linux puedes usar kvno comando para recuperarlo de KDC
[[email protected] XXX]# kvno host/XXXX
host/[email protected]: kvno = 13
Solución 4:
dsquery * -filter sAMAccountName=Accountname -attr msDS-KeyVersionNumber
Solución 5:
Consulta desde un servidor Linux unido a AD:
net ads search -P '(&(objectCategory=computer)(cn=HOSTNAME))' msDS-KeyVersionNumber
reemplazar NOMBRE DE HOST con su nombre de host.