Inside Kerberos - 4: Tickets - Nero Blanco IT Migration Specialists

Ok I think we have talked enough about SIDs in the previous two parts on SIDs and SIDHistory.  Let’s move on to Kerberos tickets…

Luckily in Kerberos there are really only two tickets (which confusingly are sometimes also referred to as Tokens)

1. Ticket Granting Ticket (TGT)
2. Service Ticket (ST)

Both of these tickets are issued by the Key Distribution Center (KDC) service on the Domain Controllers.  Let’s explore…

Ticket Granting Ticket

What does a Ticket Granting Ticket allow me to do?

A Ticket Granting Ticket (TGT) contains information that you can send to the KDC to support your request to get a ticket for a service.  It used by the KDC to verify who you are and that you are authenticated already by another KDC in the realm or in a trusted realm.  The TGT is what allows you to keep consuming services and not have to re-enter your password each time.

How do I get a Ticket Granting Ticket?

You get a TGT by asking the KDC for it using a KRB_AS_REQ message.  The KDC will ask for pre-authentication in order to be sure that you have the userkey that belongs to the user for whom the TGT is being generated.

What is in a Ticket Granting Ticket?

The TGT contains the following main fields:

• Ticket Version (which is currently 5)
• The name of the realm that issued the TGT
• The krbtgt user principal name that issued the TGT
• A payload encrypted with the KDC’s krbtgt secret key:
  • Ticket flags
  • TGS session key
  • User Realm
  • User Principal Name
  • Transited Realm list
  • Timestamps for valid from, valid to, renew to
  • Client IP Address(es)
  • Authorization Data (also known as the Privilege Access Certificate or PAC)

How is the Ticket Granting Ticket secured?

The TGT itself is secured using the secret key of the krbtgt account in the domain.  The TGT is only expected to be read by other KDCs in the same domain.

Service Ticket

What does a Service Ticket allow me to do?

A Service Ticket (ST) allows you to request access to a service on an application server.  The application server will use the information in the Service Ticket to create your access token, authorize your request and if authorized then attach the access token to the process that you’re creating (or the thread that is impersonating you).

How do I get a Service Ticket?

You get a ST by asking the KDC for it using a KRB_TGS_REQ message.  The KDC will use the TGT and other information in the request like the service principal name to locate the right realm and create a Service Ticket.

What is in a Service Ticket?

The ST contains the following main fields

• Ticket Version (which is currently 5)
• The name of the realm that issued the ST
• The krbtgt user principal name that issued the ST
• A payload encrypted with the server’s or service principal’s secret key:
  • Ticket flags
  • TGS session key
  • User Realm
  • User Principal Name
  • Transited Realm list
  • Timestamps for valid from, valid to, renew to
  • Client IP Address(es)
  • Authorization Data (also known as the Privilege Access Certificate or PAC)

How is the Service Ticket secured?

The ST itself is secured using the secret key of the server or service account in the domain.  The ST is only expected to be read by the destination server or service.

So that covers both of the types of tickets inside Kerberos.  In the next part we will expand on the Privilege Access Certificate (PAC) and take a look at Access Tokens