Soluzione 1:
Con i cmdlet AD di PowerShell è possibile eseguire una query per kvno:
get-aduser <username> -property msDS-KeyVersionNumber
Soluzione 2:
Sono incredulo sul fatto che KVNO abbia qualcosa a che fare con il tuo problema , OK forse con i client Linux, ma comunque, usa Wireshark/Network Monitor:
I numeri di versione della chiave sono descritti nella sezione MS-KILE 3.1.5.8.
A proposito, Mathias R. Jessen ha ragione in quanto Windows in genere ignora i KVNO. Ma sono ancora implementati in modo conforme alla RFC.
https://docs.microsoft.com/en-us/archive/blogs/openspecification/to-kvno-or-not-to-kvno-what-is-the-version
No, Windows non presta attenzione a KVNO. Lo ignora semplicemente.
Ma il KVNO ha un certo significato in un ambiente RODC:
https://docs.microsoft.com/en-us/archive/blogs/openspecification/notes-on-kerberos-kvno-in-windows-rodc-environment
Qualche informazione in più qui:https://web.archive.org/web/20150204183217/http://support.microsoft.com/kb/2716037
In un ambiente con uno o più RODC, l'autenticazione potrebbe non riuscire durante l'interazione con determinati dispositivi Kerberos basati su MIT in uno dei seguenti scenari.
· Il client è un dispositivo MIT che ha ricevuto un TGT da Windows KDC su RODC
· Il client passa un TGT generato da Windows KDC su RODC al dispositivo MIT che a sua volta utilizza il TGT per richiedere un TGS per conto dell'utente chiamante.
In entrambi gli scenari il TGT sarà stato emesso da un RODC in cui msDS-SecondaryKrbTgtNumber associato all'account krbtgt per quel RODC avrà un valore maggiore di 32767.
Soluzione 3:
Su Linux puoi usare kvno comando per recuperarlo da KDC
[[email protected] XXX]# kvno host/XXXX
host/[email protected]: kvno = 13
Soluzione 4:
dsquery * -filter sAMAccountName=Accountname -attr msDS-KeyVersionNumber
Soluzione 5:
Query da un server Linux aggiunto ad AD:
net ads search -P '(&(objectCategory=computer)(cn=HOSTNAME))' msDS-KeyVersionNumber
sostituire HOSTNAME con il tuo nome host.