Kerberos Protocol Explained (Animated)
Post

Kerberos Protocol Explained (Animated)

Kerberos Protocol Animated

See French version

⚡ The KEBREROS Protocol Animated!

Kerberos

🔴 Explaining Kerberos to my grandma be like:

🔻 (1) KRB_AS_REQ (Client -> DC)

You want a TGT ticket to authenticate to the domain.
To do that, send your username and a timestamp encrypted with your account’s password hash.

⏺ The KDC (Key Distribution Center) also has a copy of your account password hash.

It uses it to decrypt the encrypted timestamp.
If decryption is successful, the username inside the timestamp matches the username you sent, your identity is verified.

🔻 (2) KRB_AS_REP (DC -> Client)

The KDC returns you 2 things:

     🔵 a TGT ticket, encrypted with KRBTGT’s account password hash.
     🟢 a TGS Session Key, used for communication in the next step, encrypted with your password’s hash.

The TGT also has a copy of the TGS Session Key inside of it.
Now you have a TGT, you want a Service Ticket (ST) from the TGS (Ticket Granting Service) to use a service.

🔻 (3) KRB_TGS_REQ (Client -> DC)

You send 3 things:

     🔵 The TGT, which contains the TGS Session Key.
     ⚫ An Authenticator, which is like challenge to verify your identity, encrypted with the TGS Session Key.

ℹ The SPN (Service Principal Name), which is the name of the target service.

⏺ Now, the TGS (Ticket-Granting Service) first decrypts the TGT, as it was encrypted with KRBTGT’s password hash.

It finds the TGS Session Key inside, which allows him to decrypt the Authenticator.
Once the Authenticator is decrypted, it compares the content of the TGT with the values inside of the Authenticator (like the name).

And if it matches, then this is a valid TGS request.

🔻 (4) KRB_TGS_REP (DC -> Client)

The KDC returns you the Service Ticket (ST), which is encrypted with the target Service’s password hash, and contains:

     ◾ the Service Session Key
     ◾ the service name
     ◾ your name
     ◾ other infos…

You know have a Service Ticket (ST). Go ask for service access.

🔻 (5) KRB_AP_REQ (Client -> Service)

You send your ST and an Authenticator.
The ST is encrypted with the service account’s password hash, so the service can decrypt it.

The Authenticator is encrypted with the Service Session Key contained in the ST.
So it first decrypts the ST, finds the Service Session Key and other infos like your name.

It then decrypts the Authenticator, read the username inside, and…

🔻 (5) KRB_AP_REP (Service -> Client)

… if the names match, the request is legit: you can access the service! 🎉

🔄 If this helped you, share to help a colleague!

I omitted to include details like the PAC (Privileges Attribution Certificate) and other in-depth infos, the goal here was to have a solid foundation of what Kerberos looked like.

French version

Kerberos