How to identify sequence of events of a delegated account logon and resource access

 

Sequence of events 

1. T0, TGT requested and granted 

2. T1, where T1-T0 < 10hours, user uses app (I don't want to use log into app because I don't know if there was any sort of logon happening) 

3. TGT was renewed as (let's call our new TGT ST1).

4. ST1 then requested another ST (let's call it ST2) 

5. ST2 was used to access resource

How to track what kerberos ticket was used to renew or to request a new ticket?

In event 4768  (TGT request), 4769 (ST request) and event 4770 (renewal), you can use “Response Ticket Hash” (the hash of a resulting ticket) and “Request Ticket Hash” (the requesting ticket hash) to chain events together. 

---

How to interpret  event 4770 

Although the wording is 'service ticket was renewed', if the requesting hash is one of TGT, and the “service name” is krbtgt, then it is really a TGT renewal instead of a ST renewal 

Why the Wording Exists & What It Means

1. The Wording Context: To the KDC, krbtgt is formally stored as a Service Principal Name (krbtgt/DOMAIN.COM). From the operating system's internal logging template perspective, requesting an extension on the krbtgt SPN gets stamped with the generic message "A Kerberos service ticket was renewed", even though functionally it is a TGT renewal.

2. The Flow:
   Existing TGTEvent 4770 (Renew)​Renewed TGTEvent 4769 (TGS-REQ)​Real Service Ticket (ST)

• Step 1 (Event 4770): The client or application server submits its existing, valid TGT (krbtgt) back to the KDC to refresh its expiration clock.

• Step 2 (Event 4769 #1): The client immediately presents that freshly renewed TGT (krbtgt) as the Request Ticket Hash to ask for a "real" Service Ticket (e.g., targeting DC$ for LDAP/RPC, or an application SPN).

• Step 3 (Event 4769 #2, if present): That initial ST is then passed along in a S4U2Proxy / constrained delegation chain as a Request Ticket Hash to mint a second downstream ST.

---

To improve the sequence of events with event IDs: 

1. TGT granting (4768), this updates lastLogon on DC where it happens 

2. TGT renewal (4770) 

3. Request ST (4769)

Step	Action	Event ID & Details	lastLogon Behavior
1. Initial Authentication	TGT Granting	Event 4768 (AS-REQ) • User authenticates with credentials/cert. • KDC issues initial TGT (krbtgt). • Generates initial Response Ticket Hash.	UPDATED Stamps lastLogon on the specific DC that processed the request.
2. Session Extension	TGT Renewal	Event 4770 (TGS-REQ for krbtgt) • Client submits valid TGT before 10-hr expiration. • KDC extends TGT validity clock. • Windows logs this as "A Kerberos service ticket was renewed".	NOT UPDATED TGT renewals explicitly bypass lastLogon updates to reduce DC write overhead.
3. Resource Access	Request Service Ticket (ST)	Event 4769 (TGS-REQ for SPN) • Client presents renewed TGT (Request Ticket Hash matches 4770/4768 Response Hash). • KDC issues Service Ticket (Response Ticket Hash) for target SPN (DC$, HTTP/, LDAP/, etc.).	NOT UPDATED Requesting service tickets never updates lastLogon.

Key Takeaway 

Because Steps 2 and 3 can loop repeatedly for up to 7 days (or indefinitely via application-managed session caches) without ever returning to Step 1:

Step 1 (4768)⟶[Step 2 (4770)⟶Step 3 (4769)] (Repeats indefinitely)

A user can actively generate 4770s and 4769s on a DC every single day, yet their lastLogon attribute will remain completely frozen at the timestamp of their original Step 1 event.

---

Let’s suppose the app uses the ST to read group membership - this action seems to create a sequence of events alongside ticket renewal/request events 

1. 4624, account logon 

2. 4627, read group membership 

3. 4634, account logoff

What Is Happening (The 6-Event Lifecycle)

When the application uses a Service Ticket to query group membership on a Domain Controller over LDAP, Active Directory handles it in two separate phases: Kerberos Ticket Exchange (KDC level) followed by Network Authentication & Session Execution (DC OS/LSASS level).

[PHASE 1: Kerberos Ticket Exchange (KDC Service)]

1. Event 4768: TGT requested

2. Event 4770: TGT is renewed (TGT_Hash_A -> TGT_Hash_B)

3. Event 4769: Service Ticket (ST) requested for DC$ / LDAP using TGT_Hash_B

[PHASE 2: LDAP Query Execution (DC Operating System / LSASS)

4. Event 4624: Network Logon (Type 3) onto the DC using the ST

5. Event 4627: Group Membership evaluation (Read user's AD groups for token

6. Event 4634: Account Logoff (LDAP connection closed)
   
   

All phase 2 events should have same logon ID, 

Why Linking Phase 1 (Kerberos) to Phase 2 (Logon) Is Difficult

Your observation that there is no clean, direct identifier (like a single shared GUID) connecting the 4769/4770 events to the 4624/4627/4634 events is a known structural gap in Windows Security auditing.

1. Layer Separation:

• Events 4768 / 4769 / 4770 are emitted by the KDC service (Kerberos ticket issuer).

• Events 4624 / 4627 / 4634 are emitted by LSA / Security Subsystem (Resource server evaluating access).

2. No LogonId in Kerberos Events: The KDC does not assign or know about the Windows TargetLogonId (0x...) that LSA creates when Event 4624 fires.

3. Ticket Hashes Are Not Logged in 4624: The Windows 4624 logon event records details like IP address, logon type, and user name, but it does not log the Request Ticket Hash of the Kerberos ticket used to authenticate.

How to Correlate the Two Sets of Events

1. Account_Name should be same

2. Time should be very close to each other

3. Source Network Address should be same as Client Address

4. 4624/4627/4634 have same logon ID

---