Ticket lifetime, renewal, and error conditions: Reading double-hop, SPN, and clock problems

1. Core mechanism

Ticket EncTicketPart and the separate KDC reply enc-part have different protection and consumers. Renewal is a TGS exchange using RENEW. For a KRB-ERROR, identify the sender, request and exchange stage before interpreting the code. A code name beginning KRB_AP_ERR does not prove the failure occurred at an application server; the KDC can use that namespace while processing an AS/TGS request.

Interfaces and specifications

• RFC 4120 §§5.3 and 5.4.2: EncTicketPart inside Ticket and EncKDCRepPart inside KDC-REP are separate structures; both carry times but are protected with different keys.
• RFC 4120 §§2.3/5.4.1: endtime is the current validity limit; renew-till is the latest renewal limit. They are distinct fields, often with a later renew-till, but the values need not be strictly different.
• RFC 4120 §3.3 and KDCOptions RENEW: new endtime is obtained by presenting existing ticket; renew-till remains constant.
• RFC 4120 §5.9.1: KRB-ERROR ::= [APPLICATION 30]; error-code [6] is the Int32 numeric ID of the error, e-text [11] and e-data [12] are additional information.
• RFC 4120 §7.5.9 error codes: KDC_ERR_S_PRINCIPAL_UNKNOWN 7, KDC_ERR_PREAUTH_FAILED 24, KDC_ERR_PREAUTH_REQUIRED 25, KRB_AP_ERR_TKT_EXPIRED 32 (0x20), KRB_AP_ERR_REPEAT 34 (0x22), KRB_AP_ERR_SKEW 37 (0x25), KRB_AP_ERR_MODIFIED 41 (0x29).
• Clock skew is checked where the request is processed. A KDC pre-authentication failure can appear as 4771/0x25; a service can also reject an AP request for skew. Read the event/message source before naming the stage.
• Windows Security 4768 (Result Code), 4769 (Status) and 4771 (Failure Code): KDC transaction logs; These fields are the Windows equivalent of the above error namespace and are produced only in DC.

Where is the time written on the ticket?

The validity window is stored in EncTicketPart: authtime records initial authentication, starttime marks the beginning, and endtime marks expiration. When starttime is absent, authtime supplies the effective start. For renewable tickets, renew-till bounds the latest expiration obtainable through renewal. This part is encrypted with the krbtgt key in a TGT and the service account's key in a service ticket.

The client decrypts the separate enc-part of AS-REP or TGS-REP, not the encrypted body of the ticket. EncKDCRepPart supplies the corresponding authtime/starttime/endtime/renew-till values. Ticket and the reply's enc-part are siblings: reading the reply does not decrypt the ticket. The client can learn the times but cannot alter the protected ticket to extend its lifetime.

A future endtime is not sufficient; the effective start must also have arrived. If the service clock reads 09:00, starttime is 10:00, and endtime is 18:00, the start lies beyond the permitted clock skew: the unexpired ticket is not yet usable. The service evaluates starttime/endtime against its own clock and allowed skew; the INVALID flag and service policy can also prevent acceptance.

endtime bounds the current ticket; renew-till bounds expiration obtainable through renewal. A future renew-till does not make the current expired ticket valid again. Renewal requires a separate exchange with the KDC.

Renewal generates a new ticket, does not extend the life indefinitely

A renewable ticket can be presented to the KDC with RENEW before its current expiration. The renewed instance receives a new session key and expiration within renew-till and policy limits; renewal does not move the renewal ceiling indefinitely.

A renewable ticket supports continuation up to a ceiling without a new AS exchange each time. Renewal depends on the renewable flag, renew-till, a valid request and KDC conditions. Renewability does not separately guarantee that only the legitimate user can use a ticket copy; validity and credential custody are different questions.

Once renewal is unavailable, choose the next exchange from the credentials still valid. An expired or nonrenewable service ticket can be replaced through a new TGS request if a valid TGT remains. A new AS exchange is needed when no suitable valid TGT remains. Credential validity, revocation checks and active application sessions are separate conditions.

Identify the exchange before interpreting an error code

An error code describes a failure condition, not a unique exchange stage. First identify the AS, TGS or AP request and the endpoint that returned the error. Codes in the KRB_AP_ERR namespace can also be returned by a KDC validating a request.

For example, 4771/0x25 is KDC-side TGT/pre-authentication evidence, while 4769/0x20 concerns the evidence ticket presented in a TGS request. A service-side AP rejection needs evidence from that service. The numeric code alone cannot distinguish these locations.

The KRB-ERROR structure below shows where the error-code is located in the message. The artifact of this lesson is a synthetic example of exactly this message.

KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (30),
        stime           [4] KerberosTime,      -- KDC response time
        susec           [5] Microseconds,
        error-code      [6] Int32,             -- numeric identity of the error
        realm           [9] Realm,             -- service realm
        sname           [10] PrincipalName,    -- unresolved SPN
        e-text          [11] KerberosString OPTIONAL,
        e-data          [12] OCTET STRING OPTIONAL
}
-- In this example error-code = 7 (KDC_ERR_S_PRINCIPAL_UNKNOWN): during TGS,
-- the requested SPN is not registered to any account. The error is not AS/AP; it records the TGS stage.

Double-hop: identity is lost on the second bounce

When Tunahan connects to WEB01 and WEB01 wants to go to DB01 on behalf of Tunahan, the service ticket in WEB01's hand only carries the information 'Tunahan proved its identity to WEB01'. If there is no Delegation, WEB01 cannot request a ticket on behalf of tunahan to DB01.

The behavior of the second hop depends on the application and its fallback preference: the connection may be attempted with the service's own identity (computer/service account), may fail with no Kerberos request sent, or may be rejected at the source. Therefore, the second hop may not produce a KDC error-code in most scenarios; however, the absence of a KDC error is not definitive proof that the root cause is 'failed to migrate identity'. Double-hop is often the result of an authorization/application behavior, not a ticket error.

The solution is not a bug fix, but a delegation model (06.06): with constrained or RBCD, Tunahan's identity is carried over to the second hop. So when you see 'access denied' one of the early questions should be 'has a KDC error-code been generated and what stage does it indicate?' If there is code, it reads the stage, otherwise this is not a diagnosis alone and it is necessary to look at the source host and application behavior.

SPN and time: same symptom, different stage

If the requested SPN resolves to no account, the error is at the TGS stage: KDC_ERR_S_PRINCIPAL_UNKNOWN (7 / 0x7). No ticket is issued; a failed Event 4769 can show this KDC result.

If the same SPN is registered to multiple principals, the KDC can return KDC_ERR_PRINCIPAL_NOT_UNIQUE (8 / 0x8) at TGS; it should not choose a key for an ambiguous match. That differs from an SPN uniquely registered to an account other than the one used by the running target service: the KDC seals the ticket with the registered account's key, and the target can reject it at AP with KRB_AP_ERR_MODIFIED.

For example, 4771/0x25 is KDC-side TGT/pre-authentication evidence, while 4769/0x20 concerns the evidence ticket presented in a TGS request. A service-side AP rejection needs evidence from that service. The numeric code alone cannot distinguish these locations.

State and data flow

1. Inspect starttime, endtime and renew-till separately. endtime is current expiration; renew-till limits renewal and need not be strictly later.
2. tunahan works for hours; When the client approaches endtime, it sends the TGS-REQ with KDCOptions RENEW and renews the TGT. New endtime comes, but renew-till is impenetrable.
3. If renewal is unavailable but a valid TGT remains, request a fresh service ticket through TGS. With no suitable valid TGT, a new AS exchange is required.
4. tunahan requests ticket to DB01 for MSSQLSvc/DB01.iyelabs.example:1433. If the SPN is not registered to any account, KRB-ERROR error-code 7 (KDC_ERR_S_PRINCIPAL_UNKNOWN) is returned during the KDC TGS phase; A failed 4769 (Status 0x7) may be visible at DC01 under applicable unknown-SPN failure logging and audit/collection conditions.
5. If the SPN is registered to the wrong account, the ticket is sealed with that account's key; DB01 cannot open with its own key and an integrity error (KRB_AP_ERR_MODIFIED family) is returned in the AP phase.
6. Clock skew can cause rejection in different exchanges. A 4771/0x25 observation belongs to the KDC’s pre-authentication context; inspect endpoint clocks without assuming an AP-only error.
7. If a double-hop is required over WEB01 and there is no delegation, the second hop may be attempted with the service ID depending on the application's fallback, failing before it ever reaches the Kerberos request, or being rejected at the source; The result is often 'access denied' and the absence of a KDC error-code is not evidence of the root cause.

2. Exploitation

Broken trust assumption

The assumption that is broken is: 'If I have a ticket that looks valid, the request is successful.' In reality, a ticket is only accepted when it is within its time window (starttime–endtime), sealed with the correct service key, and compatible with the recipient's time. When one of these three conditions is violated, the request crashes not silently but with a specific error-code. From the attacker's perspective, this means that plans built on an 'old ticket' or 'an assumption connected to the wrong service' will fail with a trace code; error namespace is a map for both attack and defense.

Technical prerequisites

• The ticket must be within its effective start/end window, with the service's clock-skew allowance applied. A start beyond that allowance or the INVALID flag causes AP-stage KRB_AP_ERR_TKT_NYV (33 / 0x21); expiration beyond the allowance causes KRB_AP_ERR_TKT_EXPIRED (32 / 0x20).
• The ticket is sealed with the current key version of the target service; If the key is returned, the old ticket is rejected at the AP stage.
• Client and target/DC time are within tolerance (default 5 min); otherwise KRB_AP_ERR_SKEW (0x25).
• Request to correct SPN; incorrect SPN assumption produces KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7) in the TGS phase, making the target intent visible in the KDC.

Exploitation mechanism

This layer is not the only vulnerability, it explains how the 'stale ticket' and 'misbinding' assumptions noisily fail and become signals for the defense. If an authenticator is replayed, the service returns KRB_AP_ERR_REPEAT (0x22) thanks to the replay cache; An expired ticket produces KRB_AP_ERR_TKT_EXPIRED (0x20). On the other hand, long ticket lifetime and long renew-till enlarge the reuse window of a stolen ticket: this is a policy choice, not a protocol vulnerability. Therefore, on the attack side, the answer to the question 'how long can it be used' is written directly in the endtime/renew-till policy, and hardening targets exactly this window.

Expired ticket and replay: not silent, coded failure

Presenting a ticket past the endtime produces KRB_AP_ERR_TKT_EXPIRED; This is a routine situation and does not constitute an attack on its own. But replaying an authenticator produces KRB_AP_ERR_REPEAT, indicating that the replay cache is enabled.

In other words, ticket-related abuse attempts leave traces on the protocol side. The 'let me reuse an old ticket' assumption often returns with a specific error code instead of giving the expected result.

Long ticket life expands the window

When a ticket or TGT is stolen, the attacker's usage time is directly limited to endtime and renew-till. If the policy keeps these values ​​unnecessarily long, the window of use of the stolen identity will also be extended.

This is not a vulnerability, but an adjustable risk. A reasonable renewal window with a short user ticket lifetime narrows the window for stolen tickets without disrupting legitimate use. That's why life values ​​are a control point on the defense side.

Boundary: code proves a stage, not an attack

An error-code says only that a stage failed for a reason; it does not prove an attack. KRB_AP_ERR_SKEW commonly points to clock drift; KDC_ERR_S_PRINCIPAL_UNKNOWN to an unresolved SPN; and KDC_ERR_PRINCIPAL_NOT_UNIQUE to duplicate principal/SPN entries. KRB_AP_ERR_MODIFIED can occur when the ticket cannot be opened with the key expected by the running service, for example when the SPN is registered to the wrong service account.

Benign causes predominate in these codes. Therefore, instead of considering a code as evidence of an attack, it is necessary to read which stage it indicates and look at the correct observation point (KDC or source host).

3. Defense & Detection

Telemetry scope

• Audit Kerberos Authentication Service (DC only): 4768 (TGT request, Result Code field) and 4771 (pre-authentication failed, Failure Code field).
• Audit Kerberos Service Ticket Operations (DC only): 4769 KDC's transaction record in the TGS phase; In unsuccessful service ticket requests, the Status field carries the TGS-stage result given by the KDC (e.g. 0x7 SPN could not be resolved). This field does not indicate whether the target service has rejected a service ticket (AP phase); If 0x20 appears here, it means that the TGT submitted as evidence to the DRC in the TGS-REQ has expired, not the rejection decision of the target service.
• AP phase errors (KRB_AP_ERR_SKEW, KRB_AP_ERR_MODIFIED) appear where the decision is made, i.e. on the source host side (service/System logs); It may not appear in DC because decoding/validation is not done there. Therefore, no failed 4769 may be generated for these AP errors and it is necessary to look for the event at the source host.
• Event 4771 covers KDC pre-authentication failure, including applicable clock-skew failures. A later service-side AP failure needs resource evidence; absence of 4771 cannot locate the failure by itself.
• For clock skew, compare clock measurements at the relevant endpoints. The difference between two event TimeCreated values alone does not establish actual clock offset; distinguish request delay, producing host and message stage.
• Inspect ticket timing through client cache information and the times in the KDC reply; 4769 Status alone does not expose starttime/endtime. A target's not-yet-valid decision and a KDC's issuance/renewal result are different observation points.

Events and relevant fields

• 4769 / Status: 0x0 no error; 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN (requested SPN could not be resolved, TGS stage); 0x20 KRB_AP_ERR_TKT_EXPIRED — in this KDC record it means that the TGT (evidence ticket) presented to the KDC in TGS-REQ has expired, not that the target service has rejected the service ticket.
• 4771 / Status (Failure Code in Event Viewer): 0x18 KDC_ERR_PREAUTH_FAILED means invalid pre-authentication information; an incorrect password is a common cause. 0x17 KDC_ERR_KEY_EXPIRED indicates an expired password; 0x25 KRB_AP_ERR_SKEW in the pre-authentication phase indicates excessive clock skew.
• 4768 / Status (Result Code in Event Viewer): the TGT request outcome; 0x0 is success. An AS request without preauthentication can receive 0x19 KDC_ERR_PREAUTH_REQUIRED; if the client retries with the required preauthentication, this negotiation alone is neither an attack nor a final failure. Do not assume every client follows this initial exchange.
• 4769 / ServiceName: the account or computer for which the service ticket was requested. It is not the full requested SPN and can be empty in some records. Use the client/request context separately to establish which SPN was requested or could not be resolved.
• 4769 / TicketOptions: KDCOptions bitmask of the request (such as forwardable, renewable); Carries flags that affect ticket life and renewal behavior.
• TimeCreated is the DC event timestamp. It is not an offset measurement by itself; establish clock differences with suitable endpoint time observations and the request context.

Read the source, then the code

An error code describes a failure condition, not a unique exchange stage. First identify the AS, TGS or AP request and the endpoint that returned the error. Codes in the KRB_AP_ERR namespace can also be returned by a KDC validating a request.

For example, 4771/0x25 is KDC-side TGT/pre-authentication evidence, while 4769/0x20 concerns the evidence ticket presented in a TGS request. A service-side AP rejection needs evidence from that service. The numeric code alone cannot distinguish these locations.

Source / request     Code example     Interpretation
4771 / KDC AS        0x25             Pre-authentication clock-skew failure
4769 / KDC TGS       0x20             Expired evidence ticket in TGS request
KDC / TGS reply      0x07             Requested service principal unresolved
Resource / AP        Context required Service-side ticket/authenticator checks
Code alone does not identify the exchange or prove an attack.

Same symptom, different root cause

Five possible explanations for ‘access denied’ include missing second-hop identity, an unresolved SPN, duplicate SPNs, ticket/key mismatch, or clock skew. These require different evidence; the phrase alone identifies none of them.

When a code exists, interpret it in the known request and endpoint context. Absence of a KDC error is not a diagnosis: the application may use its own identity, fail before contacting Kerberos, or be rejected by the resource. Inspect DC, resource and application evidence separately.

Detection logic · XPath

<!-- Ornek 4769 belgesi icinde basarisiz (Status != 0x0) service ticket taleplerini secer. -->
<!-- Bu yalnizca tek bir Event XML belgesi uzerindeki secimdir; cok-host zaman -->
<!-- korelasyonu yapmaz ve kaynak host'taki AP hatalarini gormez. -->
//*[local-name()='Event']
  [*[local-name()='System']/*[local-name()='EventID']='4769']
  [*[local-name()='EventData']/*[local-name()='Data'][@Name='Status'][normalize-space(text())!='0x0']]

Query assumptions

• XPath only selects on a single given Event XML document; does not correlate across multiple hosts or time windows.
• The status value is compared as text in the format '0x0'; If a backend stores the value as an integer, the match type must be adapted.
• AP phase errors (skew, modified) do not appear in this 4769 selection; they are looked up in the records on the source host side, and no failed 4769 may be generated for these AP errors. This statement was tested only on a sample document in this session, not on a live system.
• Routine failures such as Status 0x20 (TGT submitted to DRC in TGS-REQ has expired) are also selected; Without a second code-based filter, the result contains noise.

False positives

• Status 0x20 is the expiration (routine) of the TGT (proof ticket) presented to the DRC in the TGS-REQ and usually has no security implications; It should not be confused with the service ticket rejection of the target service (AP phase).
• Misspelled or not yet registered SPNs produce 0x7; This is usually a configuration error, not an attack.
• Negative example: if the attacker already has a valid ticket, it will generate success 4769 (Status 0x0) and this filter will not see it at all. Failure selection is a scope limit, not evidence.

Hardening

• In Kerberos Policy, keep 'Maximum lifetime for user ticket' (default 10 hours) and 'Maximum lifetime for user ticket renewal' (default 7 days) values ​​based on need; unnecessary longevity increases the usage window of a stolen ticket.
• Align clock synchronization (W32Time) to DC hierarchy; MaxClockSkew defaults to 5 minutes and measure the actual skew of the slowest/mobile client before lowering it or legitimate authentication will be broken.
• Inventory and deduplicate SPNs: duplicate entries can produce TGS KDC_ERR_PRINCIPAL_NOT_UNIQUE (0x8); if an SPN is unique but belongs to the wrong service account, correct its owner and investigate a possible target-side KRB_AP_ERR_MODIFIED (0x29).
• Meet the double-hop requirement with constrained or RBCD, not with unconstrained delegation (06.06); Thus, the scope of carrying ID is narrowed.
• Group failed 4769/4771 records by error-code and separate routine codes (0x20, 0x19); just examine unexpected code distributions.
• Verification step: repeat the same workflow after the change; 4769 Status 0x0 should be returned, the client–DC clock offset should be within tolerance, and the target SPN should be unique.

Read the examples

7e 81 8e 30 81 8b a0 03 02 01 05 a1 03 02 01 1e
a4 11 18 0f 32 30 32 36 30 39 32 39 30 36 31 35
33 30 5a a5 03 02 01 00 a6 03 02 01 07 a9 11 1b
0f 49 59 45 4c 41 42 53 2e 45 58 41 4d 50 4c 45
aa 30 30 2e a0 03 02 01 02 a1 27 30 25 1b 08 4d
53 53 51 4c 53 76 63 1b 19 44 42 30 31 2e 69 79
65 6c 61 62 73 2e 65 78 61 6d 70 6c 65 3a 31 34
33 33 ab 1d 1b 1b 4b 44 43 5f 45 52 52 5f 53 5f
50 52 49 4e 43 49 50 41 4c 5f 55 4e 4b 4e 4f 57
4e

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4769</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>14337</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T06:15:30.4120000Z" />
    <EventRecordID>20714</EventRecordID>
    <Correlation />
    <Execution ProcessID="712" ThreadID="1180" />
    <Channel>Security</Channel>
    <Computer>DC01.iyelabs.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">tunahan@IYELABS.EXAMPLE</Data>
    <Data Name="TargetDomainName">IYELABS.EXAMPLE</Data>
    <Data Name="ServiceName">MSSQLSvc/DB01.iyelabs.example:1433</Data>
    <Data Name="ServiceSid">S-1-0-0</Data>
    <Data Name="TicketOptions">0x40810000</Data>
    <Data Name="TicketEncryptionType">0xffffffff</Data>
    <Data Name="IpAddress">::ffff:192.0.2.60</Data>
    <Data Name="IpPort">52140</Data>
    <Data Name="Status">0x7</Data>
    <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="TransmittedServices">-</Data>
  </EventData>
</Event>

Two reality checks

Assumption: Ticket renewal extends the life of the ticket as long as desired.

In fact: Once renewal is unavailable, choose the next exchange from the credentials still valid. An expired or nonrenewable service ticket can be replaced through a new TGS request if a valid TGT remains. A new AS exchange is needed when no suitable valid TGT remains. Credential validity, revocation checks and active application sessions are separate conditions. RFC 4120 §§2.3/5.4.1: endtime is the current validity limit; renew-till is the latest renewal limit. They are distinct fields, often with a later renew-till, but the values need not be strictly different.

Assumption: The double-hop error is a clock or SPN problem; There is no need to look at the error-code.

In fact: Double-hop is when the ID cannot be carried on the second hop; The behavior of the second hop depends on the implementation — the service may try with its own identity, fail without ever reaching the Kerberos request, or be rejected at the source — so most of the time it does not produce a KDC error-code. However, the absence of this code is not proof that identity migration is the root cause. Clock problem (KRB_AP_ERR_SKEW, 0x25) and SPN problem (KDC_ERR_S_PRINCIPAL_UNKNOWN, 0x7) produce distinct error-code. So when you see 'access denied' it helps to see if there is a KDC error-code and what stage it indicates; If there is no code, the diagnosis is completed with the source host and application behavior.

Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §2.3 Renewable tickets (renew-till upper bound); §3.3 TGS renewal; §5.3 EncTicketPart (authtime/starttime/endtime/renew-till); §5.9.1 KRB-ERROR ([APPLICATION 30], error-code/e-text/e-data); §7.5.9 error code table (7, 24, 25, 32, 34, 37, 41). §§3.2.3, 5.4.2: start/end checks and the separate client-decryptable reply part.
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Event XML (Failure); Status/Failure Code table (0x0, 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN, 0x20 KRB_AP_ERR_TKT_EXPIRED); ServiceName, ServiceSid (NULL on failure), TicketEncryptionType 0xffffffff, LogonGuid fields.
• Microsoft · 4768(S, F) A Kerberos authentication ticket (TGT) was requested
  Result Code / Failure Code table; 0x19 KDC_ERR_PREAUTH_REQUIRED (routine first round), 0x18 KDC_ERR_PREAUTH_FAILED; Audit Kerberos Authentication Service, DC only.
• Microsoft · 4771(F) Kerberos pre-authentication failed
  Failure Code field and value table (0x18 preauth failed, 0x17 key expired, 0x25 clock skew); pre-authentication stage; DC only.
• Microsoft · Maximum tolerance for computer clock synchronization
  Default maximum client-DC clock skew is 5 minutes; replay attack rationale; Account Policies\Kerberos Policy.
• Microsoft · Maximum lifetime for user ticket
  Default maximum lifetime for user ticket is 10 hours; related 'Maximum lifetime for user ticket renewal' default is 7 days; Account Policies\Kerberos Policy.
• Microsoft · KDC configuration and unknown-SPN failure audit
  KdcExtraLogLevel unknown-SPN error logging; protocol failure versus collected Security4769. No registry action performed.