> For the complete documentation index, see [llms.txt](https://officerwasu.gitbook.io/officerwasu-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://officerwasu.gitbook.io/officerwasu-docs/untitled/protocols/kerberos.md).

# Kerberos

Based on the Greek mythology's guard of hell, Kerberos is a secure, ticket-based network authentication protocol designed to verify user or host identity over insecure networks using secret-key cryptography. As the default authentication method for Windows Active Directory.

The Kerberos authentication client is implemented as a security support provider (SSP), and it can be accessed through the Security Support Provider Interface (SSPI).

Using Kerberos authentication within a domain or in a forest allows the user or service access to resources permitted by administrators without multiple requests for credentials. After initial domain sign on Kerberos manages the credentials throughout the forest whenever access to resources is attempted.

It is based on the ‘trusted third party’ concept, which means that it uses a centralised authentication server to validate identities and distribute tickets that grant access to services.

Now for a ‘trusted third party’ concept to work there are three entities needed 

* Client or User
* Service 
* Trusted third party(KDC)

#### What is **KDC** now?

KDC is the authentication server that is responsible for authenticating users and services. This authentication consists of two phases: the authentication phase and the service ticket phase.

#### How does it work?

Now the KDC runs on the Domain controller and DC has everyone's(in that domain) secret(NT hash) in it, which is located in C:\Windows\NTDS\ntds.dit. It also stores the AES keys for every user

Now if our User wants to access a service. To do that, he will need to send a **KRB\_AS\_REQ**(It contains the Username and the current timestamp which is encrypted with the User's Secret(Now it could be either the NT hash or the AES key derived from the password+username and domain). 

Now the KDC Decrypts that timestamp referencing with the username to find the AES key and returns the  **KRB\_AS\_REP**(Which contains a session key that is encrypted with our user's key and a Ticket Granting Ticket that is encrypted with the KDC'S secret key)

**note**: KDC'S secret key is the secret key of the user **krbtgt,** TGT can only be used by our user no one other than the KDC(krbtgt) can read it.The TGT we got contains Username for our user, our user's session key, How long the ticket is vaild for and lastly the PAC(Privilege Attribute Certificate).

After getting the TGT if our user now wants to access a Service we'll need to send a **KRB\_TGS\_REQ** which includes the TGT, authenticator(Username + Timestamp encrypted with our user's session key) and the name of the service. 

now the KDC will Decrypt the TGT and will get the session key from there and will use that session key to decrypt the authenticator we sent and if it's successful our user will get back  a **KRB\_TGS\_REP** which contains a Service Ticket which is encrypted with the service's key and  a session key to access the service these are encrypted with our session key.

now when our user tries to access the service well send a  **KRB\_AP\_REQ** which contains the Service Ticket and a authenticator encrypted with the new session key we got, now the service will decrypt the ticket with it's own key and extract the session key from that ticket and will use that decrypt the authenticator giving our user access to the service.

#### Sources

<https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview>

<https://en.hackndo.com/kerberos/>

<https://www.udayxd.xyz/notes/kerberos/kerberos-protocol>