Protocol practice · Identity Fundamentals & Directory Services

Kerberos: tickets, from sign-in to a file share

Objective: Rui signs in to the Harbor domain on a laptop, then opens the team’s file share without typing the password again. Get the tickets that make that work, and see where attackers come in.

About 12 minutes · simulated, no real servers

1Sign in
2Hold the TGT
3Ask for the share
4Open the share
5Know the attacks

Where Kerberos fits

Sign-inWho is this?

OpenID Connectbuilt on OAuth SAMLenterprise single sign-onKerberosYou are here

AccessWhat may this app do?

OAuthaccess for an app

AccountsDoes the account exist?

SCIMjoiners, movers, leavers

Not sure? Which protocol?

Kerberos at work, every day

Each of these happens inside a Windows domain, after one sign-in.

Signing in to a domain-joined laptopThe first ticket comes from the domain controller.
Opening a file shareNo password prompt: a ticket for the share is fetched behind the scenes.
An internal site that just knows youIntegrated Windows sign-in, using the same tickets.

Step 1 of 5

Sign in: the authentication service

Rui types their password at 08:58. The laptop asks the domain controller’s Key Distribution Center for a ticket-granting ticket.

AS-REQ  →  KDC (dc01.harbor.example)
  client:   rui@HARBOR.EXAMPLE
  service:  ______
  padata:   ______

Fill in the two blanks, then send the request.

service: which ticket you want first

padata: what proves Rui knows the password

Pick an answer for each blank to continue.

This step

Realm: The Kerberos domain, in capitals by convention: HARBOR.EXAMPLE. In Windows, the Active Directory domain.
Key Distribution Center: Issues tickets. It runs on every domain controller and has two parts: the authentication service and the ticket-granting service.
Principal: Any identity Kerberos knows, user or service: rui@HARBOR.EXAMPLE, cifs/files.harbor.example.
Pre-authentication: Proving you know the password by encrypting a timestamp with a key derived from it. The password never crosses the network.
krbtgt: The KDC’s own account. Its key encrypts every TGT, so whoever steals it can forge them (a golden ticket).

Earlier steps (0)

All terms (14)

Realm: The Kerberos domain, in capitals by convention: HARBOR.EXAMPLE. In Windows, the Active Directory domain.
Key Distribution Center: Issues tickets. It runs on every domain controller and has two parts: the authentication service and the ticket-granting service.
Principal: Any identity Kerberos knows, user or service: rui@HARBOR.EXAMPLE, cifs/files.harbor.example.
Pre-authentication: Proving you know the password by encrypting a timestamp with a key derived from it. The password never crosses the network.
krbtgt: The KDC’s own account. Its key encrypts every TGT, so whoever steals it can forge them (a golden ticket).
Ticket-granting ticket: Proof you signed in, good for hours. Shown to the KDC to get tickets for services, instead of the password.
Session key: A temporary key shared between the laptop and the KDC (or a service), handed out with each ticket.
Ticket-granting service: The part of the KDC that swaps a TGT for a ticket to a specific service.
Service principal name: How a service is named in Kerberos: service class, host, sometimes port. cifs/files.harbor.example.
Authenticator: A fresh timestamp encrypted with the session key, sent with a ticket to prove the sender holds that key.
Service ticket: Encrypted with the service account’s key, so the service can verify it alone, without calling the KDC.
Clock skew: Kerberos relies on timestamps. By default clocks may differ by five minutes; beyond that, requests fail.
Kerberoasting: Requesting service tickets to crack the service account’s password offline. Defeated by long, random service passwords.
AS-REP roasting: The same offline attack against accounts with pre-authentication turned off. Keep pre-authentication on.