How to purge Kerberos tickets for a different session using KLIST

Cam orice admin cu experienta ar trebui sa stie cum functioneaza Kerberos si de existenta utilitarului KLIST. In ultimele versiuni de Windows nu mai trebuie instalat nimic, este deja livrat cu sistemul de operare. Pentru cei ce nu sunt familiari, o sa amintesc scenariul clasic in care adaugi un user intr-un grup ce ii da acces la o resursa (sa zicem file share), dar accesul nu functioneaza decat daca userul face logoff/logon. Iar asta se intampla pentru ca in ticketul Kerberos nu exista si SID-ul noului grup, asta fiind motivul pentru logoff/logon (refresh). Asta asa foarte pe scurt si fara prea multe detalii tehnice.

Sa revenim la KLIST. Cu acest tool puteti face refresh la ticketele TGT/TGS si astfel sa updatati group membershipul in timp real fara a mai fi nevoie de logoff/logon. Ca o nota separata, refresh-ul la ticketele Kerberos nu rezolva toate probleme de acces, dar in multe cazuri se pare ca functioneaza. Documentatia oficiala a tool-ului o gasiti aici:

https://technet.microsoft.com/da-dk/windows-server-docs/management/windows-commands/klist

In documentatie si mai peste tot pe internet este prezentat cazul in care faci renew la sesiunea curenta sau la computer account-ul local. Dar sunt scenarii in care ai nevoie sa faci refresh la cache-ul unui serviciu sau al unui alt cont logat pe sistem.

Pentru contul curent comanda este:

klist purge

Iar pentru local system account:

klist –li 0:0x3e7 purge

Ambele comenzi trebuiesc rulate dintr-un shell elevat. 0x3e7 reprezinta ID-ul contului localsystem. Pentru a face refresh la alte conturi, trebuie sa aflam ID-ul.

Incepand cu Windows 2012/8 puteti afla ID-ul tot cu KLIST:

klist sessions

Mai departe puteti accesa o alta sesiune folosind ID-ul, ca in exemplul de mai jos:

In caz ca rulati pe ceva mai vechi de Windows 2012/8 va fi nevoie de powershell si WMI. Ca sa nu mai reinventez roata, exista deja comanda in Powershell aici:

https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=56

gwmi Win32_LogonSession | % { $one = $_ ; $one.GetRelated(‘Win32_Account’) | Select Domain, Name, SID, @{ n = ‘LogonSessionHEX’ ; e = { ‘0x{0:X}’ -f ([int] $one.LogonId) } }, @{ n = ‘LogonSessionDEC’ ; e = { $one.LogonId } } , @{ n = ‘LogonType’ ; e = { $one.LogonType } } }

Output-ul arata ceva de genul asta:

Mai departe puteti filtra dupa o sesiune a unui anume user, sau dupa tipul sesiunii, folosind LogonType. Pe acestea le gasiti explicate aici: http://www.windowsecurity.com/articles-tutorials/misc_network_security/Logon-Types.html

De exemplu sesiunile RDP vor avea Logon Type 10 si serviciile vor avea Logon Type 5. Pentru a filtra dupa tipul sesiunii adaugati urmatoarele la comanda de mai sus: |? {$_.LogonType -eq 10}

Sau |? {$_.LogonType -eq 10} daca ne uitam dupa servicii:

Sau folosind |? {$_.Name -eq "aungureanu"} putem filtra dupa numele user-ului. Inlocuiti aungureanu din exemplul meu cu numele user-ului dorit:

Nota: in exemplul de mai sus puteti vedea doua sesiuni de acelasi tip (RDP) pentru acelasi user. Asta se intampla datorita UAC; fiecare user are doua tickete, unul limitat si altul elevat. Cu exceptia administratorului builtin care by default primeste doar un token elevat.

Tineti minte: KLIST si refreshul la ticketele Kerberos nu rezolva toate problemele de autentificare. Tot Logoff/Logon este recomandat. KLIST este doar un workaround pentru situatii urgente.