How Kerberos Authentication Works 

Reading Time: 6 minutes

What is Kerberos?

Kerberos is an authentication protocol for client/server applications. This protocol relies on a combination of private key encryption and access tickets to safely verify user identities.

The main reasons for adopting Kerberos are:

  • Plain text passwords are never sent across an insecure network.
  • Every login has three stages of authentication.
  • Encryption protects all access keys and tickets.
  • Authentication is mutual, so both users and providers are safe from scams.

Three Main Components of Kerberos

Every Kerberos verification involves a Key Distribution Center (KDC). The KDC acts as a trusted third-party authentication service, and it operates from the Kerberos server. KDC consists of three main components:

  • An authentication server (AS): The AS performs initial authentication when a user wants to access a service.
  • A ticket-granting server (TGS): This server connects a user with the service server (SS).
  • A Kerberos database: This database stores the IDs and passwords of verified users.

All Kerberos authentications take place in Kerberos realms. A realm is a group of systems over which a KDC has the authority to verify users and services.

How does Kerberos Authentication work?

With Kerberos, users never authenticate themselves to the service directly. Instead, they go through a series of steps performed by different parts of the Key Distribution Center.

The AS Verifies Users with Decryption

The Kerberos protocol starts with the user requesting access to a service through the Authentication Server. This request is partially encrypted with a secret key, the user’s password. The password is a shared secret between the user and the AS.

The AS can only decrypt the request if the user encrypted the message with the right password. If the password is wrong, the AS cannot interpret the request. In that case, AS does not verify the user, and the authentication process fails.

Once it decrypts the request, the AS creates a ticket-granting ticket (TGT) and encrypts it with the TGS’s secret key. This key is a shared secret between the AS and the Ticket Granting Server.

A TGT contains a client/TGS session key, an expiration date, and the client’s IP address. The IP address protects from man-in-the-middle attacks. Once it issues a TGT, the AS sends it to the user.

The TGS Connects Users to Service Servers

The user sends the TGT to the TGS. If the ticket is valid and the user has permission to access the service, the TGS issues a service ticket.

A service ticket contains the client ID, client network address, validity period, and client/server session key. The service ticket is encrypted with a secret key shared with the service server.

The user then sends the ticket to the service server along with the service request. The SS decrypts the key and grants access to the requested resources.

Verification Without Plain Text Passwords

During the entire verification process, a plain text password never reaches the KDC or the service server. Encryption protects all three sets of temporary private keys.

Kerberos works both with symmetric and asymmetric (public-key) cryptography. The protocol can also handle multi-factor authentication (MFA).

Kerberos Authentication Steps:

Step 1: The User Sends a Request to the AS

The user issues an encrypted request to the Authentication Server. When the AS gets the request, it searches for the password in the Kerberos database based on the user ID.

If the user types in the correct password, the AS decrypts the request.

Step 2: The AS Issues a TGT

After verifying the user, the AS sends back a Ticket Granting Ticket.

Step 3: The User Sends a Request to the TGS

The user sends the TGT to the Ticket Granting Server. Along with the TGT, the user also explains why accessing the file server.

The TGS decrypts the ticket with the secret key shared with the AS.

Step 4: TGS Issues a Service Ticket

If the TGT is valid, the TGS issues a service ticket to the user.

Step 5: The User Contacts the File Server with the Service Ticket

The client sends the service ticket to the file server. The file server decrypts the ticket with the secret key shared with TGS.

Step 6: The User Opens the Document

If the secret keys match, the file server allows the user to open the document. The service ticket determines how long the user has access to the record.

Once access expires, the user needs to go through the entire Kerberos authentication protocol again.

Benefits of Kerberos Authentication

These are the main benefits of adopting Kerberos:

Improved Security

Cryptography, multiple secret keys, and third-party authorization make Kerberos one of the industry’s most secure verification protocols.

User passwords are never sent across the network. Secret keys pass the system in encrypted form. If someone is logging conversations, it is hard to gather enough data to
impersonal a user or the service.

Access Control

Kerberos is a crucial component of today’s enterprises in this the protocol allows excellent access control With Kerberos, the company gets a single point for enforcing security policies and keeping track of logins.

Transparency and Auditability

Kerberos makes it easy to see who requested what and at what time. Transparent and precise logs are vital for security audits and investigations.

Mutual Authentication

Kerberos enables users and service systems to authenticate each other. At each step of the authentication process, both the user and the server systems know that they are interacting with authentic counterparts.

Limited Ticket Lifetime

All tickets in the Kerberos model have timestamps and lifetime data. Admins control the duration of the users’ authentication and Short ticket lifetimes are great for preventing brute-force and replay attacks.

Scalability

Several technology giants have adopted Kerberos authentication, like Apple, Microsoft, and Sun.

Reusable Authentications

Kerberos authentications are reusable and durable. The user only verifies to the Kerberos system once. For the lifetime of the ticket, the user can authenticate to network services without re-entering personal data.

Single sign-on is the most direct end-user benefit of Kerberos.

Quick Fixes and Updates

Over the years, top programmers and security experts have tried to break Kerberos. This scrutiny ensures that any new weakness in the protocol is quickly analyzed and corrected.

Can Kerberos Be Hacked?

No security model is completely invulnerable, and Kerberos is no exception. As Kerberos is so widely used, hackers had ample opportunities to find ways around it.

The biggest threats to a Kerberos system are forged tickets, repeated attempts to guess a password, and encryption downgrading malware.

The most successful methods of hacking Kerberos include:

  • Pass-the-ticket: A cyber attacker forges a session key and presents the fake credentials to reach the resources. Hackers usually forge a golden ticket (a ticket that grants domain admin access) or a silver ticket (a ticket that grants access to a service).
  • Credential stuffing and brute-force attacks: Automated, continued attempts to guess a user password. Most brute-force attacks go after the initial ticketing and the ticket-granting service.
  • Skeleton key malware: This malware bypasses Kerberos and downgrades key encryption. The attacker must have admin access to launch the cyberattack.

Kerberos Authentication’s Weaknesses

While Kerberos effectively deals with security threats, the protocol does pose several challenges:

The Kerberos Server Is a Single Point of Failure

If the Kerberos server goes down, users cannot log in. Fallback authentication mechanisms and secondary servers are typical solutions to this problem.

Strict Time Requirements

Date/time configurations of the involved hosts must always be synchronized within predefined limits. Otherwise, authentications fail because tickets have a limited availability period.

Every Network Service Needs its Kerberos Keys

Each network service that requires a different hostname needs its set of Kerberos keys. Issues with virtual hosting and clusters are not uncommon.

Steps to start the Kerberos configuration

Change the hostname

sudo hostnamectl set-hostname EDGE.HADOOP.COM

Check by running the hostname command

Open /etc/hosts file :

sudo vim /etc/hosts

And add a below-mentioned line on that

10.0.0.33 EDGE.HADOOP.COM

Install mentioned packages

sudo apt-get install krb5-kdc krb5-admin-server -y
sudo krb5_newrealm

This will ask for the KDC database master key password.

Please enter twice to verify the same password

And also change the realm to HADOOP.COM

sudo vim /etc/krb5kdc/kdc.conf
Change the port number to 88 if not there

Now start and enable daemon services for Kerberos

sudo systemctl start krb5-kdc.service
sudo systemctl enable krb5-kdc.service

sudo systemctl start krb5-admin-server.service
sudo systemctl enable krb5-admin-server.service
Now my hostname will be Displayed as Knoldus@EDGE

Reference:

https://www.ibm.com/docs/en/streams/4.2.1?topic=authentication-introduction-kerberos