Invalidate all Kerberos Tickets of a Domain User

cw flag

I deactivated an active directory domain user and logged off his computer. I am not sure, maybe he is logged on anywhere else (some switch, router,..) so i was curious if it is possible to invalidate his kerberos ticket so all sessions will immediately drop. I read about it and found some threads stating that one can use

klist purge -li 0x3e7 -s <server> -c <domain-user>

on any computer (/w privileged permissions) in the domain. But does that also affect e.g Switches and Routers (using AAA authentication) to immediately close all sessions?

cn flag
`so all sessions will immediately drop`. Kerberos doesn't have sessions. What sessions are you referring to?
mbrain avatar
cw flag
All Login session which was authenticated by kerberos. Especially my Cisco switches and router. Users are authenticated using kerberos. if someone is, can i stop their session on the routers/switches?
fr flag

Kerberos tickets stay valid for the amount of time that they're valid.

Kerberized services validate the received tickets "off-line", without contacting a KDC or any other central authority – as long as the ticket decrypts using the service's key (keytab) it's good. So there is no way for tickets to be revoked except at the service.

This means that if the user only has a 'krbtgt' ticket, it can be "revoked" at the KDC by disabling the user account (i.e. making the KDC refuse to issue further tickets); however, if the user already has tickets for other services (e.g. an HTTP webapp), those tickets stay valid and it's up to each service to do the job of validating the account if they want.

Of course, the service itself can do additional checks, such as querying LDAP whether the account exists and is not locked – for example, your routers will accept the Kerberos ticket for authentication but then might check the AAA server for authorization (e.g. getting privileges from LDAP), and the user would be refused as unauthorized (despite having authenticated successfully).

But for services that do not use any additional authorization server (e.g. webapps or SSH hosts that only require a ticket), you're out of luck – the ticket will stay valid for however much more it is valid. Fortunately, that's only "until the end of this day", i.e. 24 hours max, in nearly all cases.

Finally, even if the tickets do become invalid, this does not cause sessions to immediately drop. Kerberos-authenticated RDP or SSH sessions can remain active indefinitely (unless they use gss-keyex with SSH, in which case they'll remain active until the next SSH rekey interval). Kerberos-authenticated web SSO can remain active as long as the SSO cookies are valid (depending on the system).

(This is generally true for any authentication mechanism, not just Kerberos. For example, if you SSH to a server using a pubkey, your session stays open even if that key is later removed from authorized_keys.)

stating that one can use klist purge -li 0x3e7 -s <server> -c <domain-user> on any computer (/w privileged permissions) in the domain

That doesn't sound right at all. Yes, klist purge does exist, but it purges tickets from the client machine that it's being run on – not from some kind of central domain-wide database. It's only useful to do so on the machine that contains the tickets that you want to destroy, not on "any computer". (For example, a user could purge their own tickets to refresh their AD group membership, by getting a new ticket with a new PAC.)

Moreover, the option -li 0x3e7 tells klist to access the computer's "machine" ticket cache, not any user's. It's what you would use in order to purge the tickets that the machine itself has obtained (e.g. to refresh a computer's group memberships without rebooting), but you would not use this option – not this particular LUID, at least – if you wanted to remove your own "user" tickets from the system.

But does that also affect e.g Switches and Routers (using AAA authentication) to immediately close all sessions?

No, for all of the aforementioned reasons.

In the case of switches and routers, if they're using a RADIUS or TACACS AAA server for authorization in addition to Kerberos authentication, and if they're set up with per-command authorization via AAA (as opposed to just checking at login time), then they'll likely close sessions as soon as the next command is issued and the AAA server says "Account seems locked according to LDAP". But otherwise the session stays open.

mbrain avatar
cw flag
Thank you for that exact answer to the point :D
I sit in a Tesla and translated this thread with Ai:


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.