Skip to content

TGS Request

KRB_TGS_REQ

The client sends its TGT back with fresh proof and names the service it wants.

  • Kerberos
  • Client to domain controller
  • Kerberos, port 88

Why It Matters

The DC believes any TGT that opens with the krbtgt key and never asks for the password here, so a stolen or forged TGT is spent at this step. Any signed-in account may ask for a ticket to any service.

Where It Sits

The strip shows every step of the Kerberos sign-in, with this page's step marked. Each of the others links to its own page, and Step Through It opens the walk-through on the topic page.

KerberosStep Through It
  1. Step 1 of 6, AS Request, ws-017 to dc-01
  2. Step 2 of 6, AS Reply, dc-01 to ws-017
  3. Step 3 of 6, TGS Request, ws-017 to dc-01
  4. Step 4 of 6, TGS Reply, dc-01 to ws-017
  5. Step 5 of 6, AP Request, ws-017 to srv-fin-01
  6. Step 6 of 6, AP Reply, srv-fin-01 to ws-017

What Happens

The request carries the TGT unchanged, an authenticator (the account's name and the current time) encrypted with the TGT session key, and the service principal name (SPN) of the service wanted, such as cifs/srv-fin-01.corp.example for the file share. Only a holder of the session key can make the authenticator, so a copied TGT works only with its session key.

dc-01 opens the TGT with the krbtgt key, checks the authenticator, and copies the TGT's PAC into the service ticket, adding dana's domain local groups. Her other groups come from the TGT, so a change to them takes effect only after her next sign-in. Whether she may use the service is for the service to decide, unless an authentication policy or a trust to another organisation asks the DC to check.

The DC looks up which account owns the SPN, because that account's key will seal the ticket. That is a computer account for most services and a user account where a service runs as one. Nothing is logged for the request alone, and dc-01 writes event 4769 to its Security log once it answers or refuses.

dc-01 checks that dana's account is still enabled, unlocked and in date only once the TGT is more than twenty minutes old. Disabling an account therefore stops its TGTs here within twenty minutes, while service tickets already issued work until they expire.

A sign-in at a desktop also asks for a ticket to the workstation itself, whose PAC tells it who signed in. Computer accounts (names ending in $) ask for their own too, so a DC's Security log holds far more 4769 events than one user's work suggests.

What Is Sent

Each part of the message is listed with what it holds and what protects it. A part sealed with a key can be read only by whoever holds that key, and a part marked In the clear has no protection of its own.

PartWhat It HoldsProtection and Who Can Read It
The TGT PA-TGS-REQSent back unchanged, as ws-017 cannot open it.Encrypted with the krbtgt AES keyOnly dc-01 can open it.
An authenticator authenticatordana's name and the current time, proof that the TGT is hers.Encrypted with the TGT session keyOnly ws-017 and dc-01 can open it.
The service wanted snameIts service principal name (SPN), cifs/srv-fin-01.corp.example.In the clearAnyone who sees the traffic can read it.

What the DC Checks Before Answering

Before it issues a service ticket, dc-01 runs these checks in turn. When one fails, event 4769 in its Security log records the failure as a Failure Code, shown beside each check.

CheckFailure Code
The TGT opens with the krbtgt key and has not expired0x20 for an expired ticket, which is common and routine
The authenticator's time is within five minutes of the DC's clock0x25
Exactly one account owns the SPN0x7 if none does, 0x8 if more than one does
The account is in good standing, checked once the TGT is over twenty minutes old0x12
The PAC requestor matches the account the TGT names0x14 (TGT revoked)
A ticket type the service account allows, and a session key type both sides allow0xE

What Is Logged

dc-01 writes event 4769 to its Security log once it answers. A refused request gets a 4769 with a Failure Code.

Check It on a Machine

These Windows Registry keys hold the settings this page names. Open one to see where it lives and how to read it on a machine.

Attacks That Hook in Here

These attacks work through what this page describes. Each card says what the attack is and, where it uses one of these steps, what it does there.

  • Kerberoasting

    Asks for service tickets, then guesses the service account's password offline.

    At This Step Kerberoasting starts here, as any domain account may name any service's SPN in this request, and dc-01 issues the ticket as for anyone.

  • Pass-the-Ticket

    Replays a Kerberos ticket copied from one machine's memory on another.

    At This Step A copied TGT is sent here from a second machine. On DCs with the January 2025 update, 4769 shows one Request ticket hash at two addresses.

  • Golden Ticket

    Forges a TGT with the krbtgt key, for any account and groups, that every DC accepts.

    At This Step A forged TGT is first used here. dc-01 keeps no list of the TGTs it issued, so one sealed and signed with the krbtgt key is believed.

  • Diamond and Sapphire Tickets

    Alters a real TGT with the krbtgt key, so a genuine sign-in sits behind the forgery.

    At This Step The altered TGT is first used here. It is real, but its groups were changed and it was resealed with the krbtgt key, so dc-01 believes it.

  • Kerberos Delegation Abuse

    Uses a server trusted for delegation to reach other services in users' names.

    At This Step A server trusted for delegation sends this request in a user's name and gets a ticket to another service as that user.

  • noPac (sAMAccountName Spoofing)

    A renamed computer account makes a ticket name a privileged account.

    At This Step Here the TGT names a computer account renamed since, so a patched dc-01 refuses it and writes KDC events 35 to 38 to its System log.

Sources