Understanding Kerberos Authentication
Understanding Kerberos Authentication Kerberos is one of those protocols that can look complicated when you first come across terms like KDC, TGT, TGS, Realm, Principal, SPN, and Service Ticket. But once the basic flow is clear, Kerberos becomes much easier to understand. In this blog, I am not going too deep into every Kerberos attack or packet-level detail. The goal is to understand the main Kerberos components and how they work together inside an Active Directory environment. --- What is Kerberos? Kerberos is a network authentication protocol that allows users to authenticate and securely access authorised services. Kerberos has been the default domain authentication protocol in Active Directory environments since Windows 2000. By default, Kerberos uses: One of the important things about Kerberos is that the user's password is not normally transmitted across the network during authentication. Instead, Kerberos uses cryptographic keys and tickets. The main advantage of Kerberos is that a user normally authenticates once and can then access authorised services using tickets instead of entering the password again and again. The two main tickets we will discuss are: Ticket Granting Ticket (TGT) Service Ticket (ST) If a client has a valid TGT, it means that the initial Kerberos authentication process has successfully taken place and the client can use that ticket to request Service Tickets. However, having a valid TGT does not mean the user automatically has permission to access every service. The TGT is used to request a Service Ticket, while the actual access to the resource still depends on the permissions assigned to the user. --- A Simple Example Before going into the technical terms, let's understand Kerberos with a simple example. Imagine I am visiting a company for an audit. When I reach the company, I first go to the reception or security desk and provide my details. The security team verifies my identity. Once my identity is verified, they provide me with a temporary ID card. Now I do not need to verify my identity from the beginning every time I want to access another department. Instead, I can show that temporary ID card and request access to a specific department. If I am authorised to enter that department, I receive the required access pass. Kerberos works in a similar way. This is the basic idea behind Kerberos authentication. --- Kerberos Components The main Kerberos components and concepts we need to understand are: Key Distribution Center (KDC) Realm Principal Ticket Granting Ticket (TGT) Ticket Granting Service (TGS) Service Ticket (ST) Let's go through them one by one. --- Key Distribution Center (KDC) The Key Distribution Center, or KDC, is the core component of Kerberos. It handles authentication and is responsible for issuing Kerberos tickets. The KDC mainly provides two services: Authentication Service (AS) Ticket Granting Service (TGS) Both have different responsibilities. Authentication Service (AS) The Authentication Service handles the initial Kerberos authentication process. The client proves that it possesses the correct credential material for the user. After successful authentication, the KDC returns a Ticket Granting Ticket (TGT) to the client as part of the AS-REP response. The TGT can then be used to request Service Tickets. Ticket Granting Service (TGS) The Ticket Granting Service is responsible for issuing Service Tickets. Once the client has a valid TGT, it can present the TGT to the TGS and request a ticket for a specific service. For example: The client can then present that Service Ticket to the MSSQL service. Service Tickets allow authenticated clients to authenticate to individual services without entering the user's password again. --- Kerberos Realm A Kerberos Realm is an administrative authentication boundary containing users, computers, and services managed by a Kerberos KDC. In Active Directory, the Kerberos Realm normally corresponds to the Active Directory domain and is conventionally represented in uppercase. Example: The Realm helps Kerberos identify which authentication environment an identity belongs to. For example, suppose we have two domains: Now imagine both domains contain a user called madhav. They can be represented as: Even though the username is the same, they belong to different Kerberos Realms. The Realm helps Kerberos identify: Which KDC is responsible for the identity Which users and services belong to that Realm Which Realm a Kerberos ticket belongs to So the username may be the same, but the Realm helps distinguish the identities. --- Principal A Kerberos Principal is an identity known to Kerberos. A Principal can represent a: User Service Computer User Principal A User Principal represents a user inside the Kerberos Realm. In Active Directory, users commonly have a User Principal Name (UPN). Example: Here: --- Service Principal A Service Principal represents a service that clients want to authenticate to. Some common examples are: In Active Directory, Kerberos identifies service instances using Service Principal Names (SPNs). Examples: The SPN identifies the service and maps it to the account that owns that service identity. This allows the KDC to issue the correct Service Ticket. If Kerberos cannot locate an appropriate SPN for a requested service, it cannot issue the expected Kerberos Service Ticket for that SPN. Depending on the application and configuration, authentication may use another mechanism such as NTLM. --- HOST Service Principal You may also see SPNs such as: HOST is a built-in service class commonly associated with a computer account. It is used by Kerberos for several host-based Windows services. So rather than thinking of this as a completely separate type of Kerberos identity, it is better to think of it as a HOST service principal/SPN associated with the computer account. --- Secret Keys Kerberos Principals are associated with cryptographic keys. For user accounts using password-based Kerberos authentication, the Kerberos key is derived from the user's password according to the encryption type being used. Computer and service accounts also have credential material from which their Kerberos keys are derived. These keys are used throughout Kerberos to protect authentication information and tickets. A Principal is commonly represented as: Example: A service principal can look like: Example: --- Ticket Granting Ticket (TGT) A Ticket Granting Ticket, or TGT, is issued during the initial Kerberos authentication process. The client later uses the TGT to request Service Tickets from the Ticket Granting Service. The important thing here is that the user does not need to provide the password again every time a new Kerberos-enabled service is accessed. Instead, the existing TGT and session key are used. --- How a TGT is Obtained Let's look at the process a little more closely. 1. User Enters Credentials The user provides their credentials to the local system. The password itself is not simply sent to the KDC. --- 2. Client Derives the Kerberos Key The Kerberos client derives the user's Kerberos key from the password according to the encryption type being used. That key will be used during the authentication process. --- 3. Client Sends AS-REQ In a typical password-based Kerberos flow with pre-authentication enabled, the client sends an AS-REQ to the Authentication Service. The request can include information such as: PA-ENC-TIMESTAMP is a common Kerberos pre-authentication mechanism where the client sends timestamp data encrypted using the user's Kerberos key. Depending on the exchange, the KDC may first respond that pre-authentication is required before the client sends the appropriate pre-authentication data. --- 4. Authentication Service Validates Pre-Authentication The Authentication Service attempts to validate the pre-authentication data using the Kerberos key associated with the user. If the KDC can successfully validate it, the client has demonstrated possession of the expected credential-derived key. --- 5. KDC Generates a Client/TGS Session Key The KDC generates a new Client/TGS Session Key. This session key will later be shared between: The client will use this session key when requesting Service Tickets from the TGS. --- 6. KDC Creates the TGT The KDC creates the Ticket Granting Ticket. The TGT contains information such as: Client identity Realm information Ticket validity information Ticket flags Client/TGS Session Key Authorization data, where applicable In an Active Directory environment, the ticket can also contain authorization information such as the Privilege Attribute Certificate (PAC). The important security property is: The TGT is encrypted using the krbtgt account's Kerberos key. Because the client does not possess the krbtgt key, the client cannot decrypt or modify the TGT itself. At the same time, the KDC also prepares information for the client, including the Client/TGS Session Key. That client-readable portion of the AS-REP is protected using the user's Kerberos key. So we effectively have: The Client/TGS Session Key appears in both contexts because both sides need it: --- 7. AS Sends AS-REP The Authentication Service sends an AS-REP back to the client. Conceptually, the response contains: The TGT remains opaque to the client. --- 8. Client Processes the AS-REP The client uses its password-derived Kerberos key to decrypt the client-readable encrypted portion of the AS-REP. From this, the client obtains the Client/TGS Session Key. However: The client cannot decrypt the TGT itself because the TGT is protected using the krbtgt account key. The client does not need to decrypt the TGT. It simply stores the ticket and later sends it back to the KDC when requesting a Service Ticket. --- 9. Client Stores the TGT and Session Key The client now has: These can later be used to request Service Tickets from the Ticket Granting Service. The important points to remember are: TGT = protected using the krbtgt account key. Client/TGS Session Key = shared between the client and the TGS for the next stage of Kerberos authentication. --- A Quick Note About AS-REP Roasting Normally, Kerberos pre-authentication is required for user accounts. However, if Kerberos pre-authentication is disabled for an account, an attacker may be able to request an AS-REP for that user without first proving knowledge of the user's password-derived Kerberos key. The attacker can then obtain encrypted material from the response and attempt to crack it offline. This is known as: AS-REP Roasting We will leave the attack details for another blog, but understanding the normal AS-REQ and AS-REP flow makes it much easier to understand why this attack is possible. --- Ticket Granting Service (TGS) This is one place where the terminology can become confusing. The TGS is not the Service Ticket itself. The Ticket Granting Service (TGS) is a service provided by the KDC. Its job is to issue Service Tickets. The basic flow is: Once the client already has a valid TGT and Client/TGS Session Key, it can request a Service Ticket for a specific service. For example, suppose madhav wants to access an MSSQL server. The simplified process looks like this: The important distinction is: TGS = the service that issues Service Tickets. Service Ticket = the ticket used to authenticate to a specific service. --- Service Ticket (ST) A Service Ticket is a Kerberos ticket used by a client to authenticate to a specific service. The client first obtains a TGT and then uses that TGT to request a Service Ticket from the TGS. For example: A Service Ticket is issued for a particular service principal. For example: The Service Ticket is protected using the Kerberos key of the account associated with the target SPN. The client presents the ticket to the target service. Because the target service has access to the corresponding Kerberos key, it can decrypt and validate its portion of the ticket. This is another important concept to remember: TGT is pr