Kerberos Ticket Lifetime After Account Disablement: Containment

Kerberos Ticket Lifetime After Account Disablement: Why Sessions Persist

Kerberos ticket lifetime after account disablement matters because changing an account's state does not automatically cancel tickets already issued to it. Microsoft documents that valid service tickets issued before disablement can still allow access. A responder therefore needs evidence about the account, the tickets and the resources accepting them, rather than treating the disable operation as proof of completed containment. Microsoft Learn: user ticket lifetime

There is a second boundary: an authenticated connection can outlive the ticket that established it. Microsoft explains that service tickets authenticate new connections; expiration does not interrupt ongoing operations on a connection already authenticated. Waiting for the ticket's end time is consequently insufficient evidence that access has stopped. Microsoft Learn: service ticket lifetime

Consider a response investigation with three separate questions. Can the identity obtain another ticket? Can a ticket already held authenticate another connection? Is a previously authenticated connection still operating? These are investigative questions derived from those documented boundaries, not three stages that every incident follows. Keep them separate in the incident record so that evidence about one cannot accidentally close the others.

This guide addresses legitimate tickets already issued, including the containment problem when such material has been stolen. For the distinct threat of forged TGTs based on a compromised krbtgt secret, see the Golden Ticket attack and its krbtgt prerequisite. For the differences between forging a service ticket and reusing a stolen ticket, see the Silver Ticket comparison with Pass-the-Ticket and the Pass-the-Hash, Overpass-the-Hash and Pass-the-Ticket comparison. Their attack walkthroughs are separate from the lifetime and containment decisions here.

The Three Clocks: TGT, Service Ticket and Established Connection

The ticket-granting ticket, or TGT, is used to obtain further Kerberos tickets. The service ticket is presented to a particular service. The established connection then has its own lifetime, which the service-ticket policy does not define. Keep the two ticket clocks and the connection clock distinct; the renewal window is an additional limit on renewable TGTs. Microsoft Learn: service ticket lifetime, RFC 4120 §2.3

The following values are Microsoft's documented defaults, not measurements of your domain. The keys and units are specified in MS-GPSB §2.2.2, Kerberos Policy.

Convert hours and minutes before comparing values. MS-GPSB identifies MaxTicketAge as the related upper limit for MaxServiceAge; the Learn service-ticket page contains a self-comparison typo that should not become an operational rule. The five-minute skew setting is a tolerance, not a guaranteed containment delay. MS-GPSB, Microsoft Learn: clock synchronization tolerance

Seven days of renewal does not mean each TGT is continuously valid for seven days. A renewable ticket has an individual expiry and a final renewal boundary. Shortening that window also has availability implications for users who cannot frequently reach a domain controller. Microsoft Learn: user ticket renewal, RFC 4120 §2.3

Account Checks Limit New Tickets Without Automatically Cancelling Issued Tickets

Windows has account checks during ticket requests. MS-KILE §5.1.3 requires account-domain KDCs to check the account when the presented TGT is older than 20 minutes. MS-KILE §3.3.5.7.1 gives the conditions: account-policy validation must be enabled, and the KDC must belong to the user's account domain. A KDC in another domain cannot perform that account check. A disabled account is rejected with KDC_ERR_CLIENT_REVOKED under those conditions.

This is request processing, not a timer that disconnects every session at minute 20. It limits subsequent TGS issuance and does not recall a service ticket already obtained. TGT requests also have documented account-policy checks, including rejection of disabled accounts when the validation option is enabled. MS-KILE §3.3.5.6.3

The protocol also describes a revocation mechanism. RFC 4120 §3.3.3.1 specifies a hot-list checked at the ticket-granting service, preventing cancelled tickets from obtaining additional tickets. It distinguishes that from normal tickets already obtained, which remain valid until their usual expiration. This specification does not establish a universal Windows administration command for globally revoking one user's tickets. RFC 4120 §3.3.3.1

Changing the user's password does not automatically replace the session keys and tickets already held. That is a cryptographic inference from the TGS exchange: the TGT is processed with the ticket-granting service's key, and the response uses a session key rather than the client's long-term secret. It is not a promise that every future authentication will succeed after a reset. RFC 4120 §§3.3.2–3.3.3

Group removal has another boundary. Global and universal group SIDs enter the PAC during initial TGT issuance and are copied into renewed TGTs. Renewal alone therefore does not guarantee refreshed membership. Resource-domain local groups are added during service-ticket issuance; do not generalize that every group is frozen at the first TGT. MS-PAC §4.1.2.1, MS-KILE §3.3.5.7.3

Detection

1. Build a Timeline Across Account, KDC and Destination Logs

Use the documented Windows events below as evidence inputs. The correlation strategy is an analytical recommendation based on their fields and the protocol boundaries above; no lab output or production detection result is claimed.

Event 4768 does not cover every TGT failure: Microsoft documents that result codes 0x10 and 0x18 generate event 4771 instead. Include those preauthentication failures when reviewing unsuccessful requests. Microsoft Learn: 4768 coverage

Anchor the incident on the target of 4725, not the administrator who disabled it. Map that identity to normalized names in Kerberos events: 4769 does not provide the same target-user SID field as 4725. Retain the raw event and mapping decision. Use the destination host with its logon identifier when pairing 4624 and 4634; Microsoft documents that logon IDs are unique only between reboots on the same computer. 4725 field definitions, 4769 field definitions, 4634 correlation limits

Prioritize successful ticket requests or new destination logons after disablement, unexpected source hosts, and continuing activity on known connections. Review the account-domain KDC, validation setting, TGT age and incident timing before interpreting a later successful TGS request. These are investigation leads derived from KILE, not automatic proof of ticket theft. Missing events leave a visibility gap; they do not establish that a connection ended. Corroborate the timeline with the resource owner's current connection inventory and application audit trail.

2. Measure Policy on the Relevant Domain Controllers

The examples below are adapted from documentation, not commands executed against an AD environment. Use an authorized context, the required tools/modules and an existing writable report directory. The local gpresult example targets the DC where it runs. Read the Kerberos Policy settings in the report, alongside the applied GPO context. Microsoft Learn: gpresult

gpresult /scope computer /h C:\Temp\Kerberos-RSoP.html

Inspect the Default Domain Policy's settings with the following report. Its well-known GUID is also the collector helper's lookup key at helpers/gpo_policy.go:11. A report for one GPO does not by itself demonstrate the effective policy on every DC. Microsoft Learn: Get-GPOReport

Get-GPOReport -Guid 31B2F340-016D-11D2-945F-00C04FB984F9 -ReportType XML

Inspect other GPOs, including their links and filters, with a separate report. Select the actual domain and server using documented parameters when the current context is unsuitable. Get-GPOReport

Get-GPOReport -All -ReportType XML

Get-ADDefaultDomainPasswordPolicy does not read Kerberos policy. Its output is the default domain password-policy object; do not use it to claim that MaxTicketAge or MaxRenewAge was verified. Microsoft Learn: Get-ADDefaultDomainPasswordPolicy

3. Inspect Tickets Actually Held on In-Scope Hosts

The following separate examples come from Microsoft Learn: klist. Read the current session's cache:

klist

Inspect its TGT, including the end time and renewal boundary:

klist tgt

Enumerate local logon sessions before assuming the current user's cache covers the host:

klist sessions

Select a logon session with -li, which specifies the low part of its LUID; use -lh as well if the high part is nonzero. 0x3e7 is Microsoft's documented example:

klist -li 0x3e7

Record host, session, collection time and ticket times. These observations cover the selected cache, not ticket copies on another system. Preserve that perimeter in the response record.

Remediation

1. Reduce Excessive Durations Before an Incident

Microsoft's user-ticket guidance proposes 4–10 hours, with more frequent requests increasing KDC load. Test the selected value against legitimate workflows. Configure domain Kerberos settings under Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy. Microsoft Learn: user ticket lifetime

For targeted preparation around privileged accounts, review authentication policies and silos for shorter Tier 0 TGTs and device restrictions. Keep that deployment decision separate from emergency cache cleanup.

Reducing a GPO lifetime is not a retrospective purge. That is an inference from tickets carrying their own validity times and from the local-cache operations documented above. Apply the change and verify newly issued tickets; retain existing-ticket evidence separately. RFC 4120, klist

2. Contain the Identity and the Resources During the Incident

Disable and reset the affected identity as appropriate for future authentication, then isolate compromised hosts and inventory the connections involving that identity. Isolation and resource-side closure are operational recommendations inferred from the documented survival of authenticated connections, not a universal Microsoft recovery procedure. Assign an owner to each affected host and service, and record which access path each action covers. MS-KILE TGT account checks, Microsoft Learn: service ticket lifetime

On a host you control, purge the current session's tickets with this documented command:

klist purge

For a selected session, Microsoft's example is a separate operation:

klist purge -li 0x3e7

Without a LUID selector, the purge applies to the current signed-in session. It does not reach other caches or tickets copied elsewhere. Close the relevant connections and arrange reauthentication as part of the response. Purge alone is not proof that every application connection ended. klist, service-ticket connection boundary

The responsible operator may choose a host or service restart to close local contexts when individual sessions cannot be controlled. Treat that as a local operational decision, not domain-wide revocation or proof of eradication. No universal restart command is prescribed here.

3. Reserve krbtgt Recovery for Compromise of That Secret

An ordinary user disablement is not a reason to rotate krbtgt twice. If that secret is compromised, follow domain recovery planning. Microsoft's forest-recovery procedure requires two resets because the password history retains two passwords. Wait 10 hours between resets at the defaults; if the maximum lifetimes were changed, the minimum wait must be greater than the configured lifetime. Check replication and the DC scope before scheduling the second operation. The cited procedure applies to writable DCs, not RODC krbtgt_number accounts. Microsoft Learn: reset the krbtgt password

Do not infer that those resets destroy every issued service ticket or existing connection. Their service keys and established contexts are separate boundaries. Validate new access attempts, local caches and previously open connections independently; record actual results when the response team performs those checks. RFC 4120 §3.3, Microsoft Learn: service ticket lifetime

How EtcSec Detects This

EtcSec's etc-collector identifies excessive configured durations through three real detector IDs. The following statements come from static inspection of their Detect() implementations, not an audit run against a customer's domain. Paths below are relative to public/internal/audit/detectors/ad/ in the collector source.

The comparisons are strict: 10 hours and 7 days do not trigger these findings. The aggregate overlaps the two specialized checks; these are two duration checks and one aggregate, not three independent containment capabilities. They do not detect ticket theft, kill sessions or implement user-ticket revocation.

The primary inputs are Kerberos settings parsed from SYSVOL GptTmpl.inf, at public/internal/providers/smb/gptmpl_parser.go:221–227. The helper public/internal/audit/helpers/gpo_policy.go:42–54 prefers the Default Domain Policy, then another available GPO with Kerberos settings. It does not calculate complete RSoP precedence. Compare the finding with the relevant DC's effective policy and observed tickets before declaring remediation complete.

The specialized detectors select positive values and contain DomainInfo fallbacks. MaxTicketAge=0, despite Microsoft's documented no-expiry meaning, is not flagged by the duration comparison. Missing or zero inputs can also leave Count=0. The aggregate returns Count=0 immediately when DomainInfo is nil, even if SYSVOL policy data is present (weak-kerberos-policy.go:25–33). Its details depend on IncludeDetails. None of these three comparisons checks service-ticket lifetime, clock skew or the account-validation flag.

The final response record should pair configured durations with ticket-cache evidence, KDC request outcomes and resource-side connection checks. That is the evidence needed to distinguish a corrected policy from access that has actually ended.