Let's examine the authentication and authorization mechanisms that form the foundation of security in Active Directory environments, the Kerberos protocol at their core, and the attack surface targeting this protocol through real-world scenarios. An end-to-end guide covering KDC, TGT, Service Ticket, AS-REP Roasting, Kerberoasting, delegation models, and Kerberos hardening steps.
Authentication
Authentication is a fundamental security process aimed at verifying the validity of the identity claimed by a user, system, or service. This process constitutes the first step of access control mechanisms and ensures that only verified entities can access system resources.
Authentication vs Authorization
Security in Active Directory environments is essentially built on two main concepts: Authentication and Authorization. These two processes ensure that users log into the system securely and access only the resources they are authorized for. In enterprise structures, Active Directory and the Kerberos protocol integrated with it lie at the center of these mechanisms.
Authentication is the process of verifying whether a user, device, or service truly possesses the identity it claims. In an Active Directory environment, this process is typically performed via Kerberos. When a user performs domain logon, instead of proving their identity directly to the services they want to access, they apply to a central structure, the Domain Controller. The Kerberos service running on the Domain Controller verifies the user's identity and issues them a session ticket (ticket). This way, the user does not have to resend their password for every operation, and password circulation across the network is prevented.
Once authentication is complete, authorization comes into play. Authorization determines which resources a verified user can access and which operations they can perform. In an Active Directory environment, these decisions are typically made based on the groups the user belongs to, their role, and the security policies defined in the system. For example, a user may log into the system but only have permission to view specific folders; a more privileged user, on the other hand, may perform administrative operations on the same system.
Authentication Protocols
- NTLM (NT LAN Manager)
- Kerberos
What is Kerberos?
The main purpose of the Kerberos protocol is to securely verify the identity of users and services on the network, while preventing sensitive information such as passwords from being transmitted in clear text across the network.
Kerberos prevents users from sending their passwords directly to servers. Instead, the user obtains a ticket from a central verification system, the KDC (Key Distribution Center), and uses this ticket to access services. Thus, the password never travels across the network, and the risk of credential theft is significantly reduced. Kerberos is a ticket-based authentication system operating through a "trusted third party" and based on symmetric cryptography.
Kerberos Components
The Kerberos protocol consists of 3 main components:
- Client
- Server
- Key Distribution Center (KDC)
Client
The Client is the party that initiates the Kerberos authentication process. It represents the user or device that wants to access the system.
Server
The Server is the resource that is being accessed. It can be a file server, web server, database, or any service. It is the target service protected by Kerberos.
Key Distribution Center (KDC)
It is the most critical component of Kerberos and the central authentication authority. In an Active Directory environment, the KDC runs on the Domain Controller. It consists of 2 sub-components:
- Authentication Server (AS): Checks whether the user specified in the authentication request from the client exists and is active in Active Directory.
- Ticket Granting Server (TGS): Enables clients using the TGT issued by the AS to obtain tickets for the services they wish to access. It checks whether the service requested by the client is defined with a valid SPN (e.g., CIFS, MSSQL, HTTP) and generates a Service Ticket.
Core Components of Kerberos Architecture
KDC Database: It is the central identity database maintained on the KDC. All user accounts, service accounts, SPN information, and the secret keys corresponding to each user/service reside here. This information is used to generate and verify tickets.
SPN (Service Principal Name): It is the unique identifier of a service within Kerberos. Any user within the domain can request a service ticket for any SPN. Since the ticket contains the hash of the corresponding service account, an attacker may attempt to crack this hash offline.
PAC (Privilege Attribute Certificate): It contains the user's credentials along with their privileges, group memberships, and other authorization data. It is present in both the TGT and the service ticket. The KDC only generates the ticket; the authorization decision is made by the target service. This situation can open the door to attacks such as PAC manipulation — particularly Golden Ticket.
Mutual Authentication: This is mutual identity verification. Not only does the client prove itself to the server, but the server also verifies its identity to the client. This bidirectional verification provides strong protection against Man-in-the-Middle attacks — one of the key features that distinguishes Kerberos from NTLM.
Single Sign-On (SSO): Once the user logs in, they can access different services without re-entering their password. The TGT obtained during the user's initial logon is stored in the client's memory and used in all subsequent service requests. This also introduces a critical risk: if an attacker obtains the TGT, they can perform Pass-the-Ticket or Golden Ticket attacks.
krbtgt account: It is responsible for signing all TGTs within the domain. The hash of the krbtgt account is the key used to encrypt TGTs. If this hash is obtained by an attacker, the attacker can forge TGTs at will — this is the basis of the Golden Ticket attack. Therefore, periodically changing the krbtgt password in a two-stage manner is a critical safeguard.
Kerberos Protocol Steps
- KRB_AS_REQ: The client requests a TGT (Ticket Granting Ticket) from the KDC.
- KRB_AS_REP: The KDC sends the TGT and the TGS session key to the client.
- KRB_TGS_REQ: The client uses the TGT it holds to request a Service Ticket for a specific service.
- KRB_TGS_REP: The KDC sends the Service Ticket for the requested service to the client.
- KRB_AP_REQ: The client uses the received Service Ticket to request access to the target service.
- KRB_AP_REP: The service sends a mutual authentication response by verifying its identity to the client (optional).
1. KRB_AS_REQ: Client → KDC
The user sends a KRB_AS_REQ request to Active Directory to authenticate. This request contains the username, and the timestamp is encrypted with the key derived from the user's password. The request is sent to the Authentication Service (AS) component of the KDC.
Request contents:
- PA-ENC-TIMESTAMP: Encrypted timestamp — authentication
- PA-PAC-REQUEST: PAC request (user's privileges)
- Cname: Username — the principal logging in
ETYPE
The etype list in the AS-REQ message specifies the encryption algorithms supported by the client. The presence of weak algorithms (particularly RC4 and DES) in this list makes offline password-cracking attacks such as Kerberoasting feasible if the KDC selects these algorithms.
Pre-authentication
The client sends the initial request without pre-auth. If Do not require Kerberos preauthentication is disabled, an error is returned (KRB5KDC_ERR_PREAUTH_REQUIRED) and the client adds a timestamp in the second request.
The most critical vulnerability at this stage is accounts with pre-authentication disabled. If a user account has the Do not require Kerberos preauthentication option enabled, an attacker can send an AS-REQ on behalf of the user and receive an AS-REP response. This gives rise to the risk of AS-REP Roasting.
What is AS-REP Roasting?
AS-REP Roasting is an attack carried out by exploiting a vulnerability that occurs in the first phase of Kerberos authentication (AS → Authentication Service). It is only possible on user accounts where the "Do not require Kerberos preauthentication" setting is ENABLED.
Pre-auth ENABLED: In the first step of the Kerberos flow, the user sends a request to the KDC during the AS phase. The most important feature of this request is that it contains a timestamp encrypted with a key derived from the user's own password. This is the cryptographic way of saying "I know the password" without sending the password directly. The KDC attempts to decrypt this encrypted data; if it can decrypt it, authentication is considered successful and a TGT is returned.
Pre-auth DISABLED: This security layer is completely removed. The user is not required to send the encrypted timestamp when sending a request to the AS. The KDC cannot verify whether the user actually possesses the password; nonetheless, an AS-REP response is generated as required by the system configuration. The contents of this response (particularly the session key) are encrypted with the key derived from the user's password. If an attacker captures this packet, they can crack the encrypted data offline. If it must remain disabled, strong passwords must be used.
2. KRB_AS_REP: KDC → Client
The TGS-REQ message is the stage where the client uses the previously obtained TGT to request a service ticket for a specific service. The PA-TGS-REQ field in this message contains the authenticator that proves the client possesses the session key bound to the TGT. The target service (sname) and supported encryption types (etype) are determined at this stage; Kerberoasting attacks emerge during this process.
The most critical point at this stage is the krbtgt account. The security of TGTs depends on the key of the krbtgt account. If the krbtgt hash is obtained, the attacker can forge TGTs.
3. KRB_TGS_REQ and KRB_TGS_REP
The client uses the TGT it holds to request a Service Ticket for the target service. After the TGS component of the KDC verifies that the SPN of the requested service is valid, it generates a Service Ticket encrypted with the hash of the target service and sends it to the client.
Kerberoasting
An attacker with a valid domain user account can request a Service Ticket for any SPN. Since the returned ticket is encrypted with the hash of the target service account, the attacker attempts to crack this ticket offline to obtain the service account's password. Service accounts supporting RC4 are particularly vulnerable to this attack.
4. KRB_AP_REQ / KRB_AP_REP — Service Access
The client presents the received Service Ticket to the target service (KRB_AP_REQ). The target service verifies the ticket with its own secret key and, optionally, authenticates itself to the client (KRB_AP_REP — mutual authentication).
NTLM and Downgrade Risks
NTLM is a legacy authentication protocol that operates alongside Kerberos. Unless a Kerberos-enforced environment is established, downgrade attacks over NTLM, NTLM Relay, and Pass-the-Hash techniques continue to be effective.
NTLM Hardening Policy Settings
1. Network security: LAN Manager authentication level
Send NTLMv2 response only. Refuse LM & NTLM — the recommended option.
2. Network security: Restrict NTLM: Audit NTLM authentication — set to Enable to view NTLM fallback logs.
3. Network security: Restrict NTLM: Incoming NTLM traffic — set to Deny to block NTLM.
4. Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers — set to Deny to terminate NTLM usage.
Double Hop Problem and Delegation
The double hop problem is the issue where a user's credentials cannot, by default, be forwarded from the first server to the second server. A typical example: User → Web server → SQL server.
Solution: Delegation. Kerberos delegation mechanisms enable services to access other services on behalf of the user. Through delegation, services can access other services by obtaining Kerberos tickets on behalf of the user. However, misconfigured delegation — particularly Unconstrained Delegation — can allow attackers to steal tickets, impersonate users, and achieve privilege escalation through lateral movement.
Delegation Types
1. Unconstrained Delegation
Unconstrained Delegation is the broadest delegation model, allowing the server to obtain the TGTs of users connecting to it. When a user (especially a highly privileged user) connects to a server with this configuration, the user's Kerberos ticket is held in memory. If this system is compromised, the attacker can obtain these tickets and access other systems on behalf of the user. Particularly when a domain administrator connects to such a server, privilege escalation and lateral movement become possible using the obtained ticket.
2. Constrained Delegation
Constrained Delegation is a more controlled model and allows a service to access only specific target services on behalf of the user. It operates with Kerberos's S4U (Service for User) mechanisms, S4U2Self and S4U2Proxy. The service first obtains a ticket on behalf of the user (S4U2Self), then uses this ticket to request access only for the permitted services (S4U2Proxy).
If an account with this privilege is compromised, the attacker can use this mechanism to impersonate privileged users and gain access to the permitted services.
3. Resource-Based Constrained Delegation (RBCD)
In the RBCD model, control is given to the resource (target) side. The target system determines which accounts can act on its behalf. When this structure is misconfigured — particularly through abuse of the msDS-AllowedToActOnBehalfOfOtherIdentity attribute — it can enable attackers to perform privilege escalation.
While in traditional constrained delegation the source side defines which service can access where, in RBCD this control is given to the target side. If misconfigured ACL permissions exist on the target system, even a low-privileged user can modify this attribute and add themselves as an authorized principal. This makes RBCD a frequently used technique in modern AD attacks.
Since this mechanism operates entirely over Kerberos, it can bypass measures taken against NTLM-based attacks. Moreover, since Kerberos traffic is often considered "normal," detecting these activities is difficult — only standard ticket requests (e.g., 4769) appear in Event logs.
Trust Relationships in Kerberos
In Kerberos architecture, trust relationships are the fundamental structures that enable authentication to be performed securely across different security boundaries. In large-scale enterprise environments, when a single domain or realm is not sufficient, these trust mechanisms make it possible for users to access different systems.
- Inter-domain trust
- Cross-realm authentication
- Transitive / non-transitive trust
Inter-domain Trust
It is the trust relationship established between different domains and allows users to access resources in another domain. It operates through trust relationships and cryptographic keys shared between domain controllers. In parent-child domain structures, this trust relationship is created automatically by default.
Cross-realm Authentication
It is the mechanism that enables authentication between different Kerberos realms. The user first obtains a TGT from their own realm, then a referral TGT is obtained using this TGT for the target realm. The referral process directs the client to the KDC of the target realm. In the final stage, the user completes the access by obtaining the necessary service ticket from the target realm.
Transitive Trust
It means that a domain implicitly trusts a third domain that is trusted by another domain it trusts. In AD Forest structures, such trust relationships are transitive by default. This convenience also poses a serious security risk: the compromise of any domain in the chain can lay the groundwork for attacks that propagate throughout the entire trust relationship.
Non-transitive Trust
It is a trust model that is valid only between two domains and does not extend to other domains. The trust is valid only between the two defined parties and is not automatically transferred to a third domain. It is preferred in environments with high security requirements.
Kerberos Hardening
Maximum Lifetime for Service Ticket
The maximum validity period of the service ticket directly affects the attacker's access duration in the event of a potential security breach. Short lifetimes allow privilege changes to be applied more quickly; however, excessively short lifetimes may increase KDC load.
Enforce User Logon Restrictions
When enabled, the KDC re-checks the user's current privileges and logon restrictions on every service ticket request. If disabled, even if privileges previously granted to the user have been revoked, they may remain valid for the duration of the ticket — a serious vulnerability in privilege revocation scenarios.
Maximum Lifetime for User Ticket (TGT)
The longer the TGT's validity period, the longer the attacker's operational window if it is obtained. A serious risk in Golden Ticket or Pass-the-Ticket attacks.
Maximum Tolerance for Computer Clock Synchronization
Kerberos uses timestamps to prevent replay attacks. If the tolerance is set too high, the replay window widens; if set too low, authentication errors increase.
Maximum Lifetime for User Ticket Renewal
The TGT renewal lifetime determines the persistence risk. A compromised TGT can be renewed throughout the renewal period and provide long-term access.
Cryptographic Settings (Encryption Type Hardening)
When weak or legacy algorithms (particularly DES and RC4) are left active, Kerberoasting becomes easier. Using only AES128 and AES256 is recommended.
Service Account Security
Service accounts are among the most frequently targeted components in Kerberos attacks. The use of gMSA (Group Managed Service Account), automatic password rotation, and the principle of least privilege significantly enhance service account security.
Account Lockout Policies
They limit brute-force and password spraying attacks. A threshold that is too low leads to service disruptions, while a threshold that is too high leads to brute force risk; it should be supported with monitoring.
Ticket Forwarding and Delegation Settings
Unconstrained delegation enables the attacker to harvest TGTs. Constrained delegation, and particularly RBCD, offer a more controlled model. Delegation usage should be kept to a minimum.
Disable NTLM (Kerberos Enforced Environment)
When NTLM is left enabled, even a Kerberos environment becomes vulnerable to downgrade attacks. Gradual disabling of NTLM is recommended.
Protected Users Group
It ensures that highly privileged accounts are protected with additional security layers. NTLM, weak encryption, and delegation are prohibited; TGT lifetimes are shortened; credential caching is prevented.
Authentication Policies & Silos
They control which accounts can log on to which machines. Administrator accounts can only be used on specific management workstations — reducing the risk of lateral movement.
Pre-Authentication Enforcement
Accounts with pre-auth disabled are exposed to AS-REP Roasting. Pre-auth must be enforced on all accounts and audited regularly.
KRBTGT Account and Password Rotation
If the KRBTGT password remains unchanged, Golden Ticket attacks can remain valid for a long time. A double reset, at least twice a year and 24 hours apart, should be applied.
PAC (Privilege Attribute Certificate) Validation
The PAC field carries the user's group memberships. If validation is not performed, the risk of privilege manipulation arises. PAC validation must not be disabled.
Audit Policy
Kerberos log records can be used to detect attacks such as Kerberoasting, password spraying, Golden Ticket, and delegation abuse. Abnormal TGT lifetimes, excessive numbers of service ticket requests, pre-auth failures, and unauthorized delegation behaviors should be monitored by security operations.
Some Critical Event IDs
This article is based on hands-on work conducted on Kerberos flows and the attack surface in real Active Directory environments.
