After resetting a Kerberos service account's password, what still authenticates?

## Two kinds of material, two different clocks On a domain-joined Linux fleet an operator with code on one host typically ends up holding two quite different things, and a password reset affects them differently. **Long-term key material.** The account's key is derived from its password. On a Linux host it usually lives in a **keytab** so a service can authenticate unattended; on the NTLM side the equivalent object is the NT hash. Both are functions of the current password. Change the password and both change: the old keytab no longer matches what the issuer expects, the old NT hash no longer matches what the verifier holds. Reset does its job here — subject only to the change replicating to whichever server handles the next request. **Issued proof.** A **ticket** sitting in a credential cache is a different species. It was minted by the issuer at some point in the past and carries its own validity window. Presenting it is accepted because of who issued it and when, not because the presenter can demonstrate current knowledge of anything. There is no step in accepting it that consults the account's present-day password, so changing that password does not invalidate it. The result is a window that surprises people: the credential was rotated, and the operator is still authenticated as that identity across the fleet — access that ends on the ticket's own clock rather than on anything a person decided. ## How long the window is In a default enterprise directory a ticket-granting ticket is issued with a maximum lifetime around ten hours and a renewal window of about seven days; service tickets are shorter. The exact numbers are policy, and the point is not to recite them but to recognise that they, rather than your remediation, are what is governing the situation. So the honest statement after a reset is: *new* authentications with the old material fail, and *existing* proof continues to be honoured for up to its remaining lifetime. ## What actually ends an issued ticket There are only two mechanisms, and neither is a password reset on the affected account: - **Waiting out the clock.** The ticket expires, the renewal window closes, and nothing further can be obtained without current key material. - **Invalidating the key that encrypted it.** A ticket-granting ticket is encrypted under the key of the domain's ticket-granting account. Changing that key invalidates outstanding ticket-granting tickets — and it must be done **twice**, because the previous key is retained and still accepted, which is exactly what makes a single reset ineffective. This is a domain-wide action with real blast radius, not a routine step. For service tickets there is an equivalent subtlety: the service's previous key is typically retained too, so a ticket minted under the old key can still be validated for a period after the reset. ## The NTLM contrast, which is what makes the point land There is no issued-proof problem on the NTLM side, because there is no issued object. The NT hash is recomputed from the new password, so the stolen derivative stops being accepted as soon as the change is in effect everywhere. The gap is specific to material that carries **its own lifetime**, and it is a general property, not a Kerberos quirk: the same shape appears wherever a system hands out something that is honoured on its own terms after issuance. Stating that contrast cleanly is usually what distinguishes a candidate who has actually operated an estate from one who has read a summary. ## Getting the direction of the claims right Several neighbouring statements sound similar and are wrong: - "Resetting the password logs them out." It does not. Nothing about a reset reaches material already issued. - "The ticket must have been forged, then." No. A legitimately issued ticket outliving a password change is normal protocol behaviour, not evidence of anything exotic. - "Disabling the account handles it." Disabling stops new tickets being issued for that identity, but a ticket already presented to a service is validated cryptographically; whether the service consults account state at that moment depends on the service. - "Rotating faster fixes it." Faster rotation shortens the life of long-term material; it does nothing to the life of anything already issued. ## The takeaway to say out loud A reset closes the *acquisition* path and leaves the *possession* path open for the remaining life of what was already acquired. If the question is "are we clear now?", the answer is a question back: clear of what — of new proof being obtained with the old key, yes, more or less immediately; of proof already in hand, not until its own clock runs out or the key it was issued under is invalidated.