Kerberos - Intro

Lets start with what is kerberos? Simply put it is an authentication protocol, it allows AD to identify each user who provides a secret password. It does NOT validate to which resources or services that user can access.

Kerberos Items

Networking details

Kerberos either uses UDP or TCP as its transport protocol. Since these send data in cleartext, the kerberos service is responsible for providing encryption.

The ports it communicates on are either

• UDP/88

• TCP/88 And will listen in KDC

Agents

• Client/User - What wants to access the service

• Application Server (AP) - Offers the service required by the user

• Key Distribution Center (KDC) - The main service of Kerberos, this is responsible for issuing the tickets that are installed on the DC.

• Authentication Service (AC) - Supports the KDC by issuing the Ticket-Granting-Tickets (TGT)

Encryption Keys

Structures are handled by kerberos as ticckets. Many of these are encrypted/signed to prevent tampering from third parties. These keys are

• KDC or krbtgt key - Derided from the krbtgt account NTLM hash

• User Key - Derived from the user NTLM Hash

• Service Key - Derived from the NTLM hash of a service owner. This can be a user or a computer account

• Session key - Negotiated between the user and the KDC

• Service session key - Used between the user and service

Tickets

Kerberos's main structure is its tickets. These tickets are delivered to the end user to perform most actions in the Kerberos realm. These are

• Ticket Granting Service (TGS) - Ticket which the user uses to authenticate against a service. This is encrypted with the service key

• Ticket Granting Ticket (TGT) - Presented to the KDC to request for TGS. This is encrypted with the KDC key

Privilege Attribute Certificate

This structure is contained within almost every ticket, it contains the privileges of the user and is signed with the KDC key. It is possible for services to verify the PAC by communicating with the KDC although this is exceedingly rare. The PAC verification consists of checking only its signature, without inspecting if privileges inside of PAC are correct.

A client can avoid the inclusion of the PAC inside of the ticket by specifying it in KERB_PA_PAC_REQUEST field of ticket request.

Messages

• KRB_AS_REQ - Used to request the TGT to KDC

• KRB_AS_REP - Delivers the TGT by KDC

• KRB-TGS-REQ - Delivers the TGS to KDC using the tGT

• KRB-TGS-REP - Delivers the TGS by KDC

• KRB-AP-REQ - Authenticates a user against a service using the TGS

• KRB-AP-REP - Used by a service to identify itself against the user

• KRB-ERROR - Message used to communicate error conditions

Authentication Process's

KRB_AS_REQ

The user first gets a TGT from KDC. This sends the KRB-AS-REQ to the DC. This ticket contains the following fields

• Username of the authenticated users

• The service SPN associated with the krbtgt account

• A Nonce generated by the user

• An encrypted timestamp with the client key to both authenticate the user and prevent replay attacks.

  • This is only necessary if the user requires preauthentication. if the DONT_REQ_PREAUTH flag is set on the user account its not needed.

KRB_AS_REP

After the request is received the KDC then needs to check the user identity by decrypting the timestamp. If the message is correct then it responds with a KRB_AS_REP. This ticket contains the following

• Username

• TGT: which includes

  • Username

  • Session key

  • Expiration date of TGT

  • PAC with user privileges which are signed by KDC

• Encrypted data with the user key which includes

  • Session key

  • Expiration date of TGT

  • User nonce to prevent replay attacks

After this is complete the user already has the TGT which can be used to requests TGSs and afterwards access to the services.

KRB_TGS_REQ

In order to request a TGS this has to be sent to the KDC. This ticket includes

• Encrypted data with session key

  • Username and timestamp

• TGT

• SPN of requested service

• Nonce

KRB_TGS_REP

The KDC then returns a TGS inside of KRB_TGS_REP which includes

• Username

• TGS

  • Session key of the service

  • Username

  • Expiration date of TGS

  • PAC with user privileges that are signed by KDC

• Encrypted data with session key

  • Service session key

  • Expiration date of TGS

  • User nonce to prevent replay attacks

KRB_AP_REQ

The user at this point already has a valid TGS to interact with the service. To use it the user must send to the AP a KRB_AP_REQ message.

This message includes

• TGS

• Encrypted data with service session key

  • Username

  • Timestamp

At this point if all user privs are correct they should be able to access the service. If mutual authentication is needed it will respond to the user with a KTB_AP_REP message.