In this article, we will learn what Kerberos is, how it works, and the various pros and cons of using this authentication protocol. Stay tuned for Part 2, where we will review various attacks and defenses.

What is Kerberos?

Have you ever wondered what happens when you type in your username and password at work, and magically have access to file servers, email servers, and other resources? Odds are, you are using Kerberos!

Kerberos was designed to protect your credentials from hackers by keeping passwords off of insecure networks, even when verifying user identities.

Kerberos, at its simplest, is an authentication protocol for client/server applications. It’s designed to provide secure authentication over an insecure network.

The protocol was initially developed by MIT in the 1980s and was named after the mythical three-headed dog who guarded the underworld, Cerberus. It was later refined by Microsoft for inclusion in Windows 2000 to replace NTLM – and the protocol remains Open Source.

If you need to quickly sum up Kerberos vs NTLM in an interview, the most concise description is as follows:

“While NTLM uses a three way handshake between the client and server, where credentials are sent between the systems, Kerberos avoids sending credentials across the network.”

Authentication process

Authentication via Kerberos requires the use of a Key Distribution Center (KDC) - typically a service running on all Domain Controllers (DC) as part of Active Directory Domain Services (AD DS) - containing the following components:

  1. Authentication service (AS): Authenticate users when initially attempting to access a service
  2. Ticket granting service (TGS): Connects a user with the the service server (e.g. file server) based on information stored in the database
  3. Kerberos database: Where the IDs and passwords are stored, often an LDAP server or the Security Account Manager (SAM) database in an Active Directory environment.
sequenceDiagram; autonumber; participant U as Users; participant TGS as Ticket Granting Server; participant AS as Authentication Server; participant DB as Kerberos Database; participant S as Service Server; activate U; U->>AS: User sends authentication request; activate AS; AS->>DB: Check if user exists in DB; activate DB; deactivate DB; AS->>U: Issue TGT; deactivate AS; U->>TGS: User sends request to TGS; activate TGS; TGS->>DB: TGS checks if user exists in DB; activate DB; deactivate DB; TGS->>U: TGS issues Service Ticket; deactivate TGS; U->>S: User contacts desired service server with Service Ticket; activate S; S->>U: Access granted to user; deactivate U; deactivate S;

Authentication process in depth

  1. User requests access to a service through the AS, entering their username and password locally, and sending the following information:
    1. Security Identifier (SID)
    2. Name of the requested service (e.g.
    3. User’s IP address
    4. Desired lifetime of the Ticket granting ticket (TGT). The default is 10 hours and can be changed via Group Policy
  2. AS issues a ticket granting ticket (TGT) if the user exists in the database. The AS will send two messages back to the user:
    1. The first message will contain:
      1. Security Identifier (SID)
      2. TGS ID
      3. Timestamp
      4. User’s IP address
      5. TGT lifetime
      6. TGT
      7. Session key
    2. The second message will contain:
      1. TGS ID
      2. Timestamp
      3. Session key
  3. User sends the TGT to the TGS along with the Kerberos ID of the requested services. Another message is sent containing the “Authenticator”, which is composed of the User ID and timestamp encrypted with the user’s session key.
  4. The TGS will respond to the user with two messages if the user’s information is found within the Kerberos database.
    1. The first message will contain the following information encrypted with the server’s secret service key:
      1. Service ticket
      2. User’s ID
      3. User’s IP address
      4. Validity period
      5. Service session key
    2. The second message will be sent containing the service session key, encrypted with the user’s session key (e.g. a locked box within a locked box, where the user can only unlock the first box :D)
  5. User sends the service ticket to the requested service along with the service request in two messages.
    1. The first message is the first message from the previous step that was encrypted with the server’s secret service key
    2. The second message will contain a new Authenticator with an updated timestamp, encrypted with the user’s session key
  6. Service server decrypts the ticket using it’s own secret key to retrieve the user’s session key, which is then used to decrypt the authenticator. If the user’s ID from previous messages matches, it will send a message encrypted with the user’s session key to the user with the timestamp found in the new authenticator to confirm the service’s identity.

Kerberos encryption

When creating a new account on a DC, a username and password is provided. The Kerberos client then adds a string known as a salt - a unique string used to improve the randomness of a credential - along with the Kerberos version number. In most configurations, the salt is the user’s username. These two values are then run through a string2Key function which will return the shared secret.

On a workstation, the user will request access to a service (such as logging in to the machine) by providing their username and password. The local Kerberos client will perform the same steps as the DC to arrive at a shared secret. If this secret matches the secret stored on the DC, the user can log in.

Conclusion - Kerberos benefits

Kerberos provides several benefits over previous authentication technologies, such as:

And there we have it! You are now masters of Kerberos and can hold your own in any discussion! Stay tuned for Part 2, where we will discuss the attacks against Kerberos implementations and possible defenses!

comments powered by Disqus