# Kerbros

## Overview

Port Number: 88

#### 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 IDs and passwords of verified users.

## Authentication and Authorization  Process:

![](https://1771079106-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQbAc68qKpvpcr7cwG8%2F-MRdamyc9kJhT56eJ32w%2F-MRdbQj0fYPUcadJWY6w%2Fimage.png?alt=media\&token=f7e87df1-1c69-43fe-b4f5-2ec84be518a9)

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.

🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳🕳

1. The user shares their username, password and domain name with the client.
2. The client develops a scrambled version of the password — or hash — and deletes the full password.
3. The client passes a plain text version of the username to the relevant server.
4. The server replies to the client with a challenge, which is a 16-byte random number.
5. In response, the client sends the challenge encrypted by the hash of the user’s password.
6. The server then sends the challenge, response and username to the domain controller (DC).
7. The DC retrieves the user’s password from the database and uses it to encrypt the challenge.
8. The DC then compares the encrypted challenge and client response. If these two pieces match, then the user is authenticated and access is granted.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://topgeartraining.gitbook.io/focus2learn/osi-model/kerbros.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.