Kerbros
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.
Last updated
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.
Last updated
Port Number: 88
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 IDs and passwords of verified users.
Using the shared secret method, a user can log in and get access to some application or service, as illustrated in Figure 1. The APIs used are shown in the figure, such as "AS_REQ."
Step 1: The user logs into a workstation with an existing account. The AS_REQ API makes the request of the server by sending the user name. AS_REQ is encrypted.
Step 2: The KDC uses the shared secret associated with that user to decrypt the AS_REQ packet. If successful, the request is honored and a "Ticket Granting Ticket" (TGT) is returned in the AS_REP packet.
Step 3: The TGT can then be used by the client to prove the user is who she says she is and is properly authenticated. This ticket is good for a configurable time period.
π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³π³
The user shares their username, password and domain name with the client.
The client develops a scrambled version of the password β or hash β and deletes the full password.
The client passes a plain text version of the username to the relevant server.
The server replies to the client with a challenge, which is a 16-byte random number.
In response, the client sends the challenge encrypted by the hash of the userβs password.
The server then sends the challenge, response and username to the domain controller (DC).
The DC retrieves the userβs password from the database and uses it to encrypt the challenge.
The DC then compares the encrypted challenge and client response. If these two pieces match, then the user is authenticated and access is granted.