# How kerberos works? To understand how kerberos works actually, you need to understand the components thats works during kerberos authentication protocol. ### Components of Kerberos auth: *** To authenticate a user using kerberos for a particular service, we need: * Client (User or device) - A client is the user or device that wants to access something on the network such as file server, database or any service. * Authentication Service(AS) - It is a login check that verifies the stored username and password, if success, AS grants the user first ticket called Ticket Granting Ticket (TGT). This TGT will be used for authentication on behalf of you to access the services or application across the networks. You won't need to use your password again to access the services. * Ticket Granting Service (TGS) - The TGS is the issuer for services meaning TGS gives users another ticket to access the services. The client sends the TGT generated by AS to TGS and ask for a Service Ticket. If TGT is valid, TGS send back ST for the specific service user requested for. * Key Distribution Center (KDC) - The KDC is the main kerberos server or central authority of kerberos. It combines both AS and TGS. KDC stores secrets keys, handles all the requested tickets and manages all the authentication. Every kerberos realm (a network domain) has its own KDC. * Service Principal Names (SPN) - A SPN is a unique identifier of a service instance. Kerberos authentication uses SPNs to determine what kind of service access the user wants. The SPN is linked to the service account, user account or computer object. Application or services rely on SPNs all the time to authenticate users and resources. Sometime you may have a user account with SPN attribute configured which defines it as a service account. SPN format: `service_class/hostname:port/service_name` for example: `MSSQLSvc/sqlserver.fox.com:1433` * Service Accounts - A service account is an account used to run services or application and SPNs are registerd to these service account. Also these service accounts hold the key to encrypt or decrypt the service tickets. * Service - A service in the kerberos authentication flow is the service the user is requesting access for. This service can be a web server, file share, database, etc. * PAC - Think of PAC as your digital security badge in Active Directory. Just like a physical badge shows security guards who you are and which doors you can open, PAC tells Windows services what permissions you have. PAC is included in every Kerberos ticket you receive. When you try to access a file share, that service reads your PAC to decide what you're allowed to do. PAC itself is like a message that contains: ``` Username - Your account name ("wolf") User ID (RID) - Your unique identifier number Group Memberships - All groups that user belong to (Domain Users, Domain Admins, etc.) Security Flags - Account settings (password expiry, login restrictions, etc.) Timestamps - When you logged in, password last changed, etc. Domain Info - Which domain you belong to ``` {% hint style="info" %} PAC is encrypted and digitally signed by the domain controller, so you can't just edit it and give yourself admin rights. It's tamper-proof from the user's perspective. {% endhint %} * krbtgt account - krbtgt stands for “Kerberos Ticket Granting Ticket”, It holds a secret key (password hash). This key is used to encrypt and sign all Ticket Granting Tickets (TGTs) basically it ensure TGTs are trusted and cannot be forged (easily). This key is often called TGS secret key during kerberos auth flow. ### Authentication Flow *** Let say you are a client (User) that wants to access a service which is running on a particular service account, you will have to send first message to the Authentication Service. #### AS-REQ & AS-REP: The first unencrypted message from user to AS: ``` - Username/ID (Wolf) - Timestamp (Encrypted with user's password's hash) - Requested lifetime of TGT ``` This is the first message a user sends to Authentication server. The user must send a **timestamp encrypted with the user’s password's hash** (this is the pre-auth data or PA-DATA) in the AS-REQ that validates the user is legit. If AS decrypts the timestamp sent by the user then the user is valid. The Authentication server first look for the username inside that message. Being a part of the KDC, AS has the list of username and their client secret key: | UserName/ID | Client Secret Key | | ----------- | ----------------- | | Marcus | f9K!2xP\@7 | | Wolf | Q#4Lm8$Zp | | Venus | vT7\@kR2!s | | Clair | B8x#N3q$Y | If the Username provided by the user in the first message is in the list matches, AS grab the copy of the client secret key, now if AS decrypts the timestamp sent by the user then the user is valid. and create new messages to send back to the user. The first message AS creates contains: ``` ##### Encrypted with Client secret key ##### - TGS Name/ID (id of TGS) - Timestamp (timestamp of the message was created) - Lifetime (the message lifetime same as TGT) - TGS session key ``` and second message is Ticket Granting Ticket (TGT) that contains: 
##### Encrypted with TGS secret key ######
- User Name/ID (Wolf)
- TGS Name/ID
- Timestamp
- Lifetime of TGT
- User's PAC (contains your SID and the group membership of yours)
- TGS session key
Remember krbtgt account? the secret key krbtgt account hold is used here to encrypt the TGT (often called TGS secret key) The TGS session key is just a randomly generated symmetric key added by AS. The first message is then encrypted with the user's secret key and the second message is encrypted with the TGS's secret key. {% hint style="info" %} But wait what is the role of Timestamp? Timestamp is used to prevent replay attacks and to prove the freshness of a request. Meaning if an attacker captures the ticket or request without timestamp, they could replay that same message later which then trick the server into thinking that its a legit request. Also Kerberos is configured to tolerate up to 5mins difference between timestamps of the message. {% endhint %} These two encrypted message are now send back to the user. Now the user needs to decrypt the first message, the user generates thier secret key by entering their password, kerberos then adds a salt to the password and the key version. For example: ``` user pass + salt + version letmeinwolf@fox.comkvno # letmein - password # wolf@fox.com - salt (usually the domain) # kvno - version number ``` This password run through a hashing algorithm specifically `string2key` to generate the user's secret key which then use to decrypt the first message provided by AS. This is the step where user's password is validated, if wrong password was entered, it wouldn't be able to decrypt the message. So assuming user enters the correct password and the message is decrypted. Now the user have the TGS's ID and TGS session key. Nope, the user cannot decrypt the second message which is encrypted with TGS secret key because user does not have the TGS secret key.
#### TGS-REQ & TGS-REP: User now creates two new messages the first is a simple plaintext message that indicates which service the user wants to access and the requested lifetime for the service ticket: ``` - SPN (CRM) - Requestd lifetime for ticket ``` The second message is the user authenticator which contains the user ID and the timestamp of when the message was created: ``` ##### Encrypted with TGS session key ##### - User Name/ID (Wolf) - Timestamp ``` The user authenticator message is encrypted with the TGS session key that was received earlier from the AS. The user now send these new messages along with the still encrypted TGT received from AS to the TGS (TGS-REQ). The User here has sent 3 message to the TGS: * TGT which was recieved from AS with encrypted TGS's secret key. * Simple message that has SPN of requested service and request for ticket. * The User Authenticator. The ticket granting server (TGS) now looks at the SPN contained in the unencrypted message and checks to see if the SPN in the message is in the list of services in the KDC: | SPN | Service Secret key | | ----------------------------------- | -------------------------------- | | HTTP/webapp01.corp.example.com | 9c7f3a1e5b8d4f2a6e0c1b3d7a9f8e2c | | MSSQLSvc/db01.corp.example.com:1433 | a4d9e2c7b1f6a8c3e5d0b2f9c7a1e4d8 | | CIFS/fileserver01.corp.example.com | f2a7c9e1d4b8a3c6e0f5b7d2a9c1e8f4 | | HTTP/crm.corp.example.com | c8e1b4a7d2f9c3a6e5b0d1f7a2c9e4b8 | if the service's SPN is in the list then the TGS grabs a copy of the service secret service key and decrypts the TGT with the TGS's secret key (technically using secret key that krbtgt account holds). Now the TGS can use this session key to decrypt the user authenticator message received from the user. Now that both the TGT and the user authenticator message have been decrypted the TGS starts to validate the data contained in the TGS. TGS first make sure that the user ID in the TGT and the user authenticator matches then compares the timestamps (5 mins of delay is tolerated). TGS checks that the TGT has not expired (Lifetime for TGT). TGS maintains a cache of recently received authenticators from the users. If everything is fine then TGS will check its cache to ensure that the authenticator is not already in the cache, this check provides the replay protection if the authenticator is not in the cache then the TGS will add it. The TGS now moves on to creating its own messages to the user the first message contains: ``` ##### Encrypted TGS session key ##### - SPN (CRM) - Timestamp - Lifetime of the message (same as TGT) - Service session key ``` The second message is the service ticket that contains: ``` ##### Encrypted with Service secret key ##### - User Name/ID (Wolf) - SPN (CRM) - Timestamp - User PAC - Lifetime of Service Ticket - Service session key ``` TGS generates a random symmetric service session key and adds the symmetric key to both messages. Now TGS encrypts the first message with the TGS session key and the service ticket is encrypted with the service secret key. These two messages are now sent back to the user. User receives these message and decrypt the first message with TGS session key which was received from AS earlier and **now user has a copy of service session key.** Again user cannot decrypt the second message as it was encrypted with service secret key because user does not have that key.
#### AP-REQ & AP-REP: User now create a new user authenticator message that contains: ``` ##### Encrypted with Service session key ##### - User Name/ID(Wolf) - Timestamp ``` Encrypt the message with service session key it received from TGS and send the message along with the Service Ticket to the service. Its finally the last step of the kerberos authentication flow!! Kerberos to NTLM be like fuxk three way handshakes and provide its own multistep authentication flow. Service receives these message, first it decrypts the service ticket with its secret key and grab thes service session key which the service uses to decrypt the second message user authenticator. Now that both messages are decrypted, service matches the User ID contained in the service ticket with User ID contained in user authenticator. Compares the timestamp from service ticket with user authenticator's timestamp (Again 5mins of delay is tolerated). Checks if the service ticket is not expired. If everything is fine then the service checks its cache just like the TGS, the service maintains a cache of recently received authenticators from users. The service will check its cache to ensure the Authenticator it just received is not already in the cache this check again provides replay attack protection if the user authenticator is not already in the cache then the service will add it. The service is now create its own message to send it to user. Similar to user authenticator message, service create service authenticator message that contains: 
##### Encrypted with Service Session key #####
- SPN (CRM)
- Timestamp
Service encrypt this message with service session key and send it to the user. The user receives this encrypted message from service. Now if you remember TGS sent the service session key to the user previously, so the user will use the service session key to decrypt the message. User will now verify that service name the message contained is the service name that user requested for. The user will also look at the timestamp if it was created within last couple of minutes. Just like TGS and Services, user also maintains it's own **cache** (surprise mf) since the user has mutually authenticated the service it will cache a copy of the encrypted service ticket for future use. Hence, user now has the access to service he requested for.
This completes how kerberos authentication protocol works. --- # 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://kaizoku.gitbook.io/notes/protocols/kerberos-port-88/how-kerberos-works.md?ask= ``` 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.