Kerberos — 3-headed dog OR Auth Protocol

4 min readFeb 22, 2025

The OG Authentication protocol.

What does the name mean?

For some it might sound cool, and for others it might sound complicated or scary.
The name is derived from Cerberus. In Greek mythology, it is supposed to be a 3 headed dog.

**Why that name?**

Cerberus was a guard dog. And the protocol was built to guard systems. Simple.

What is it and what does it do?

The Wikipedia page explains it fairly well. But if you want a quicker answer, continue reading.

It is an authentication protocol. Which means, it helps a system securely connect to another system over an insecure network.
“System” in this case can usually be anything from a user trying to access a server, to a server trying to access another server.
In this context, to explain how the authentication easily, we refer to these systems are Client and Server
Client is the system that is trying to connect to the Server.
Server is the system that has the information that the Client wants.
Since Kerberos is a protocol, the way it is implemented differs from org to org
The below explanation is the base level implimentation of how Kerberos is supposed to be setup

How does it do it?

This is a larger and more important section compared to the ones above.

This is a long flow. It’s not too complicated, but make sure you concentrate on the various elements through all the steps. Refer back to the previous steps or go through all the steps to see if you can remember what the next steps are.

Few things before we start:

Normally you don’t really need to know all this if you are stepping into an existing infrastructure in an org. But if you are setting this infrastructure up for the first time in an org, it is super critical to understand these as they will help you troubleshoot issues much easier.
I will not put too much importance into terminology. Understanding how this works is more critical than knowing the exact terms.
And finally, it gets very confusing if a lot of details about each step is shared while explaining an already complicated concept. So i have skipped some finer details. If you still want those details, this video explains it the best: Destination Certification.

Ok, Let the fun begin.

Starting with the end goal. The User just wants from data from the Server.
User requests for it in Step 1, the server responds in Step 2.

Super simple? Yes, but not really
The user needs to know if they are actually requesting the data from the correct server.
And the Server needs to know if the user is who they say they are.
So in-between the User and the Server, there are a few more components that help with validating the User and the Server.
Adding those components in.
Now, we have a new system called KDC (Key Distribution Center) which comprises of an Authentication Server (AuthN Server) and a Ticket Granting Server (TGS).

3 things happen initially (Refer Image above)

Step 1: User first authenticates with the AuthN(Authentication) server.
Step 2: The AuthN server grants the user a Ticket Granting Ticket (TGT) after successful AuthN.
Step 3: The same ticket is also shared with the Ticket Granting Server(TGS).

Step 4: The user then shares the TGT to the TGS
Step 5: The TGS then compares the TGT provided by the user and the TGT provided by the AuthN Server.
Step 6: If the two match, the TGS generates a “Service Ticket” which is sent back to the user.

Step 7: The user then shares this Service ticket to the final destination which is the Server.
Step 8: The Server inspects the Service Ticket and responds to the user with what the user originally asked for.

Again, there are a lot of super interesting (and honestly fascinating) steps in-between which I have skipped on purpose. It’s just not feasible to explain it in an article.

References and further reading:

Kerberos (protocol) — Wikipedia
Cerberus — Wikipedia
Kerberos Authentication Explained | A deep dive