Let's examine the authentication and authorization mechanisms that form the foundation of security in Active Directory environments, the Kerberos protocol at its core, and the attack surface targeting this protocol through real-world scenarios. An end-to-end guide on KDC, TGT, Service Ticket, AS-REP Roasting, Kerberoasting, delegation models, and Kerberos hardening steps.
Authentication:
Authentication is a fundamental security process that aims to verify 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
In Active Directory environments, security is fundamentally built on two main concepts:
Authentication
Authorization.
These two processes ensure that users can securely log in to the system and access only the resources they are authorized for. In enterprise structures, Active Directory and the Kerberos protocol integrated with it sit 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 logs in to the domain, instead of proving their identity directly to the services they want to access, they apply to a central structure called the Domain Controller. The Kerberos service running on the Domain Controller verifies the user's identity and issues them a session ticket. This way, the user does not have to send their password again for every operation, and password circulation across the network is prevented.
After authentication is completed, authorization comes into play. Authorization determines which resources an authenticated 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 in to the system but only have permission to view certain folders. A more privileged user, on the other hand, can perform administrative operations on the same system. This differentiation is provided by the authorization mechanism.
Authentication Protocols
NTLM (NT LAN Manager)
Kerberos
WHAT IS KERBEROS?
Kerberos: The main purpose of the Kerberos protocol is to securely verify the identity of users and services on the network, and while doing so, to prevent sensitive information such as passwords from being transmitted openly over the network.
Kerberos prevents users from sending their passwords directly to servers. Instead, the user obtains a ticket from a central authentication system, the KDC (Key Distribution Center), and uses this ticket to access services. Thus, the password never travels on the network, and the risk of credential theft is significantly reduced. Kerberos is a ticket-based authentication system that works through a "trusted third party" and is 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. The Client represents the user or device that wants to access the system.
Server
The Server is the resource that is being accessed. This can be a file server, web server, database, or any service. The Server is the target service protected by Kerberos.
Key Distribution Center (KDC)
It is the most critical component of Kerberos and is 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)
Ticket Granting Server (TGS)
Authentication Service (AS)
The Authentication Server (AS) is the first stage of the authentication process in the Kerberos architecture. The AS's main duty is to check whether the user specified in the authentication request from the client exists in Active Directory and whether the account is in an active state. At this stage, the validity of the user's authentication data is also verified.
Ticket Granting Service (TGS)
The Ticket Granting Server (TGS) enables clients using the TGT issued by the Authentication Server to obtain tickets for the services they want to access. The TGS's first task is to check whether the service the client requests is defined in Active Directory with a valid Service Principal Name (SPN) (e.g., CIFS, MSSQL, HTTP services). After this check, the TGS produces a Service Ticket (ST) for the client for the relevant service.
Core Components of Kerberos Architecture
KDC Database: The KDC Database is the central identity database maintained on the Key Distribution Center (KDC) in the Kerberos architecture. This database contains all the information necessary for authentication and ticket generation in the Kerberos environment. It contains all user accounts, all service accounts, their Service Principal Name (SPN) information, and the secret keys corresponding to each user and service. This information is used by Kerberos during the creation and verification of tickets.
SPN: (Service Principal Name) It is the unique identity of a service within Kerberos. In the Kerberos architecture, services are identified via the Service Principal Name (SPN). The SPN represents the unique identity of a service within the domain and is typically associated with a service account. The TGS determines which service to issue a ticket for through this SPN. Any user within the domain can request a service ticket for any SPN. (Since this ticket contains the hash of the relevant service account, the attacker tries to crack this hash offline.)
PAC: (Privilege Attribute Certificate) It is the data structure that carries the user's authorization information. The PAC contains the user's credentials along with their permissions, group memberships, and other authorization data. This data structure is present in both the TGT and the service ticket. The KDC only produces the ticket; the authorization decision is made by the target service. This situation can open the door to attacks such as PAC manipulation. Especially in Golden Ticket attacks, high privileges can be obtained by creating a fake PAC.
Mutual Authentication: mutual authentication, that is, two-way identity verification. Thanks to this mechanism, 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 especially against Man-in-the-Middle attacks and is one of the key features that distinguishes Kerberos from one-way authentication mechanisms such as NTLM.
Single Sign-On (SSO)
Once the user logs in to the system once, they can access different services and resources without having to enter their password again. This mechanism works thanks to the Ticket Granting Ticket (TGT) obtained at the user's initial login. The TGT is stored in the client's memory and is used in all subsequent service requests. This situation also creates a critical risk in terms of security. If an attacker compromises the TGT, they can impersonate the user by performing attacks such as Pass-the-Ticket or Golden Ticket.
krbtgt account: This account is responsible for signing all Ticket Granting Tickets within the domain. The krbtgt account's hash is the key used to encrypt the TGTs. If this hash is compromised by an attacker, the attacker can generate fake TGTs at will. This situation forms the basis of the Golden Ticket attack and provides the attacker with almost unlimited authority over the domain. For this reason, periodically and in a two-stage manner changing the krbtgt account's password is a critical security measure.
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 requests a ticket (Service Ticket) for a specific service using the TGT it holds.
- KRB_TGS_REP: The KDC sends the Service Ticket (TGS) 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 verifies its identity to the client and sends a mutual authentication response (optional).
Let's Examine Each Step
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 at this stage is sent to the KDC's Authentication Service (AS) component. Let's examine the request content.
PA-ENC-TIMESTAMP = Encrypted timestamp = Authentication
PA-PAC-REQUEST = PAC request (user's authority)
Cname = Username = Logged-in principal
ETYPE
The etype list in the Kerberos AS-REQ message specifies the encryption algorithms supported by the client. The presence of weak algorithms (especially RC4 and DES) in this list makes offline password cracking attacks such as Kerberoasting possible if the KDC selects these algorithms.
Do not require Kerberos preauthentication
The client sends the first request without pre-auth. If "Do not require Kerberos preauthentication" is disabled, we receive an Error (KRB5KDC_ERR_PREAUTH_REQUIRED), and the client adds a timestamp in the second request.
Do not require Kerberos preauthentication setting
The most critical vulnerability at this stage is accounts with pre-authentication disabled. If the "Do not require Kerberos preauthentication" setting is enabled on a user account, the attacker can send an AS-REQ on behalf of the user and receive an AS-REP response. This situation creates the risk of AS-REP Roasting.
What is AS-REP Roasting?
AS-REP Roasting is an attack that exploits a vulnerability that occurs at the first stage (AS → Authentication Service) of Kerberos authentication. This attack is only possible on user accounts where the "Do not require Kerberos preauthentication" setting is ENABLED (i.e., preauth is disabled).
Pre-auth: ENABLED
When pre-authentication is enabled, the user sends a request to the KDC at the first step of the Kerberos flow, i.e., the AS (Authentication Service) stage. 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 tries to decrypt this encrypted data. If it succeeds, it is understood that the user has the correct password and authentication is considered successful. The KDC then sends an AS-REP message to the user, and this message contains the TGT (Ticket Granting Ticket). IN OTHER WORDS, the KDC verifies the user's identity before issuing the TGT.
Pre-auth DISABLED
When pre-authentication is disabled, this security layer is completely removed. The user no longer has to send an encrypted timestamp when sending a request to the AS. In this case, the KDC cannot verify whether the user actually possesses the password. Despite this, due to the system configuration, the KDC produces and sends an AS-REP response on behalf of the user. The critical feature of this response is that its content (especially the session key portion) is encrypted with the user's password-derived key. In other words, the KDC produces an encrypted response without performing verification.
As a result, when pre-authentication is disabled, the AS returns an AS-REP without verifying the user. If the attacker captures this packet, they can crack the encrypted data inside offline. (If it must remain disabled, strong passwords should be used.)
2. KRB_AS_REP->KDC -> Client
The TGS-REQ message is the stage where the client requests a service ticket for a specific service using the TGT it previously obtained. 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, and attacks such as Kerberoasting emerge during this process.
The most critical point at this stage is the krbtgt account. Because the security of the TGTs depends on the krbtgt account's key. If the krbtgt hash is compromised, the attacker can produce fake TGTs.
Let's examine the request content
Kdc-options
The kdc-options field contains important flags that determine the behavior of tickets. By looking at these flags, we can gain insight into delegation usage in the system, how long tickets are valid, and authorization processes.
Forwardable: True = Ticket can be carried to other services (unconstrained / constrained delegation attacks)
Forwarded: False = Ticket has not been forwarded from elsewhere
Renewable: True = Ticket can be renewed even after its lifetime expires
Proxiable / proxy: False = No proxy delegation
3. KRB_TGS_REQ ->Client -> KDC
At this stage, the client requests a Service Ticket for a specific service using the TGT it holds. The most important vulnerability at this stage is the risk of Kerberoasting. Even a normal authenticated user within the domain can request a TGS for service accounts assigned an SPN. The KDC produces a service ticket and a portion of this ticket is encrypted with the service account's key. Tickets of service accounts with weak passwords can be cracked offline.
Let's examine the request content
TGS-REQ = I have logged in, now I want to access this service. Give me a ticket for it.
Sname = Target service
Till = Requested ticket duration
Etype = Encryption types that can be used
4. KRB_TGS_REP->KDC -> Client
At this stage, the KDC returns a Service Ticket to the client for the target service. The client will present this ticket to the target service. The ticket is encrypted with the target service's key.
The TGS-REP message contains the service ticket created for the service requested by the client and is one of the most critical stages in the Kerberos security model. The encrypted ticket data in this message is protected with the target service's key and cannot be read by the client.
The Kerberoasting vulnerability emerges exactly at this step. Because the TGS produces and delivers tickets for the requested service to any domain user without checking whether they have authorization.
TGS-REP
The data that the attacker can crack the password from is generated here
What is Kerberoasting?
In the Kerberos architecture, the TGS (Ticket Granting Service) stage is the point where the distinction between authentication and authorization is most clearly seen. The user applies to the KDC with the TGT they previously obtained and requests a Service Ticket (TGS) for a specific service. The fundamental check the KDC performs at this stage is: "Is this TGT valid and is the person making this request really the owner of this TGT?"
However, there is a critical point: the TGS does not check access authorization for the service. That is, the KDC does not verify whether the user is actually authorized to access that service. This check is later performed by the service itself. The KDC's job is only to produce a ticket based on a valid authentication result.
The critical feature of this ticket is this: a portion within the ticket is encrypted with a password-derived key belonging to the target service's account. That is, the KDC actually gives the attacker this data: encrypted data belonging to this service account, encrypted with its password.
This data is not the password directly, but it can be subjected to brute-force or dictionary attacks offline. The attacker takes this ticket, analyzes it on their own machine, and tries different password guesses to crack the password. This process is called offline cracking, and its most dangerous aspect is that it does not require any interaction with the domain controller. That is, at this stage, the attacker's activities often become difficult to detect. If the service account has a weak password or old encryption algorithms are used, the attacker can obtain the password in a short time. Even more critical is that this service account has high privileges. For example, if the service account is a member of the Domain Admin group, when this account is compromised the attacker can directly obtain domain control.
…
Why Kerberoasting Is Possible
Kerberos TGS, in most cases, produces a service ticket without verifying service access authorization.
Any authenticated domain user can request a TGS for services that have an SPN.
The service ticket within the TGS is encrypted using the service account's NT hash/key.
The attacker tries to crack the obtained ticket offline to compromise the service account's password.
Kerberos Encryption Algorithms
In Active Directory environments, we know that the Kerberos protocol secures authentication processes with a ticket-based structure. For the encryption of these tickets, we use the RC4, AES128, and AES256 algorithms.
The encryption algorithms used in Kerberos directly affect system security. In modern environments, only AES-based algorithms should be used. Active weak algorithms pave the way for password cracking and privilege escalation attacks.
DES (Data Encryption Standard)
DES is the encryption algorithm used in older versions of Kerberos. It is not considered secure today because it has a 56-bit key structure. Due to its low key length, it is vulnerable to brute-force attacks.
RC4-HMAC
RC4-HMAC has been widely used in Active Directory environments for many years. It works based on NTLM hash and has especially been preferred for backward compatibility. However, it is frequently targeted in Kerberoasting attacks. Especially when weak service account passwords are used, it poses a serious security risk.
AES128-CTS-HMAC-SHA1–96
AES128 is one of the more modern and secure encryption methods of Kerberos. It uses the AES-128 algorithm and provides much stronger security than RC4. It is supported on Windows Server 2008 and later systems.
AES256-CTS-HMAC-SHA1–96
AES256 is one of the most secure Kerberos encryption algorithms recommended today in Active Directory environments. It uses AES-256 encryption and, thanks to its strong key structure, is highly resistant to brute-force and cryptographic attacks.
Kerberos etype: Encryption Type
etype 23 -> RC4-HMAC
etype 17 -> AES128
etype 18 -> AES256
- AES256 and AES128 algorithms should be kept enabled
- RC4 support should be disabled if possible
- DES algorithms should be completely disabled
- Supported algorithms should be restricted via domain policy
Kerberos AES Compatibility and Encryption Management in Trust Structures:
In order for Kerberos traffic to flow properly between a domain and another domain with which a Trust relationship is established, it is essential that both parties agree on a common encryption algorithm.
In case of incompatibility, Kerberos tickets cannot be generated and the system may fall back to the less secure NTLM protocol, or access may be completely cut off.
The encryption types supported by the trusted party are determined by the msDS-SupportedEncryptionTypes attribute. If this value is not defined, the system tries to use only RC4 for the sake of backward compatibility.
Check via UI
Active Directory Users and Computers -> Advanced Features -> Properties-> Attribute Editor
Check via PowerShell
24 -> AES128 + AES256 28 -> RC4 + AES 4 -> only RC4 0 -> Attribute is not set explicitly. The system reverts to default behavior. Default: RC4 can be used, fallback may occur even if AES exists.
The msDS-SupportedEncryptionTypes attribute being not set causes Active Directory to exhibit default (legacy) behavior for this Trust relationship. By default, the system gravitates toward the RC4-HMAC algorithm.
-Risk: RC4 is considered insecure. It is much more vulnerable to attacks such as brute-force or Kerberoasting compared to AES.
-Current Windows 10/11 and Server 2019/2022 versions may reject RC4 due to security policies. This leads to unexpected authentication errors in resource access between the two domains.
Ticket Attacks
Golden Ticket
The krbtgt account's hash is compromised and a fake TGT (Ticket Granting Ticket) is created with this hash. The attacker can impersonate any user they want (for example, Domain Admin) and gain access to all services within the domain. Dependency on the domain controller is minimal, and it is generally used for persistence access.
Silver Ticket
A service account's (for example CIFS, HTTP, MSSQL) hash is compromised and a fake service ticket specific to that service is produced. This way, only access to the target service is provided. Since it does not require communication with the domain controller, it is more difficult to detect and operates more "silently".
Diamond Ticket
The attacker first obtains a valid Kerberos TGT, then modifies the content of this ticket (especially the privileges/PAC information) to make it more highly privileged. Since they manipulate the existing ticket rather than producing one entirely fake, it appears more realistic and is harder to detect.
Pass the hash
Pass-the-Hash is when an attacker authenticates without knowing the user's password, using only the NTLM hash. Normally, a user enters a password when logging in to the system. In the NTLM protocol, this password is converted to a hash, and verification is performed via this hash. If the attacker compromises this hash, they can connect to other systems directly with this hash without having to crack the password. This technique works entirely with NTLM-based authentication. That is, it is valid in environments where NTLM is used, not Kerberos.
✓ NTLM usage should be disabled as much as possible ✓ NTLMv1 must definitely be disabled ✓ Only NTLMv2 usage should be permitted
Pass the ticket
Pass-the-Ticket is a technique used in Kerberos environments. Here, the attacker compromises a user's Kerberos ticket (TGT or service ticket) and accesses the system as that user using this ticket. In Kerberos, authentication is performed with tickets, not with passwords. If the attacker obtains this ticket, they can provide direct access without needing the user password or hash.
✓ AES encryption should be used in Kerberos, RC4 should be disabled ✓ Kerberos pre-authentication should be made mandatory ✓ Kerberos ticket lifetimes (TGT lifetime) should be reduced
NTLM Fallback Scenario
NTLM fallback is the situation where, even when Kerberos is the primary authentication mechanism in an environment, the system automatically reverts to the NTLM protocol when Kerberos authentication cannot be performed for various reasons.
NTLM Fallback Scenarios
Kerberos uses the Service Principal Name (SPN) to identify services, and this SPN is generally resolved via hostname. If the client invokes the target system with an IP address, or if DNS resolution fails, the SPN match cannot be made. In this case, a Kerberos ticket cannot be generated and the system falls back to NTLM.
Missing or incorrect SPN configuration also causes Kerberos to become inactive. If the SPN of a service is not properly defined in Active Directory, the Key Distribution Center (KDC) cannot determine for which account to produce the service ticket. In this case, Kerberos fails and authentication takes place over NTLM. Especially in services such as IIS and MSSQL, SPN errors are among the most common causes of NTLM fallback.
Missing or incorrect trust relationships in systems running between different domains can also cause this situation. If there is no appropriate trust relationship between the client and the target service, or if the authentication path cannot be established properly, a ticket cannot be obtained via Kerberos. In this case, the system uses NTLM as an alternative. This situation arises especially in misconfigured inter-domain trust scenarios.
The time sensitivity of Kerberos is also an important factor. The protocol relies on time synchronization in order to prevent replay attacks, and when the time difference between the client and the domain controller exceeds a certain tolerance, authentication is rejected. In such a case, Kerberos fails and the system may fall back to NTLM.
The application or service in use not supporting Kerberos or being misconfigured also leads to NTLM usage. Especially legacy applications cannot initiate the Kerberos negotiation process or only support NTLM. This leads directly to authentication via NTLM.
Group Policy settings or security configurations may restrict Kerberos usage or leave NTLM enabled. In this case, when Kerberos fails, NTLM is automatically engaged.
Let's Examine NTLM Policies
Computer Configuration-> Policies-> Windows Settings-> Security Settings-> Local Policies-> Security Options
1. Policy
[Network security: LAN Manager authentication level]
Send LM & NTLM response -> Fallback risk
Send NTLMv2 response only. Refuse LM & NTLM -> Trusted
2. Policy
[Network security: Restrict NTLM: Audit NTLM authentication]
Enable -> To see NTLM fallback logs
3. Policy
[Network security: Restrict NTLM: Incoming NTLM traffic]
Allow -> NTLM is unrestricted (fallback occurs)
Deny -> NTLM is blocked
4. Policy
[Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers ]
Allow -> fallback may occur
Deny -> cuts off NTLM usage
What is the Double Hop Problem?
The double hop problem is the problem where a user's credentials cannot be forwarded from the first server to the second server by default.
Example from multi-layered structures: (user -> web server -> SQL server)
Solution: Delegation
What is Delegation
Kerberos delegation mechanisms enable services to access other services on behalf of the user.
Thanks to delegation, services can access other services by obtaining Kerberos tickets on behalf of the user. However, misconfigured delegation, especially Unconstrained Delegation, can lead attackers to steal tickets, perform user impersonation, and escalate privileges through lateral movement.
Delegation Types
1. Unconstrained Delegation
Unconstrained delegation is the oldest and riskiest method. In this model, a service can access any service by obtaining the user's TGT. If this service is compromised, the attacker can obtain users' TGTs and carry out serious privilege escalation and lateral movement.
2. Constrained Delegation
It was developed to reduce the risk and only permits limited access to specific services.
3. Resource-Based Constrained Delegation (RBCD)
In this model, control is given to the resource side. The target system determines which accounts can perform operations on its behalf. However, this structure too, when misconfigured, can allow attackers to escalate privileges, especially through misuse of the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
---
1. Unconstrained Delegation
Unconstrained Delegation: Unconstrained Delegation is the broadest delegation model in the Kerberos architecture that allows a system to obtain the TGT (Ticket Granting Ticket) tickets of users who connect 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. Especially when the domain administrator connects to such a server, privilege escalation and lateral movement within the domain become possible with the obtained ticket.
2. Constrained Delegation
Constrained Delegation is a more controlled model and permits a service to access only specific target services on behalf of the user.
This configuration works 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 to the permitted services (S4U2Proxy).
However, if an account with this authority is compromised, the attacker can use this mechanism to impersonate privileged users and obtain authority over the permitted services.
Although it is more secure than unconstrained delegation, when misconfigured it constitutes an attack vector that can provide access to critical systems.
3.Resource-Based Constrained Delegation
In the configuration we performed
THENOOB computer → target (resource) system
CLIENT01 computer → principal granted delegation authority
As a result of this configuration, the CLIENT01 system can request service tickets on behalf of specific users using Kerberos delegation mechanisms (S4U2Self and S4U2Proxy) and access services on THENOOB through these tickets. In this process, the user password is not used; authentication is performed entirely through the Kerberos ticket mechanism.
The main reason this situation is critical from a security perspective
is that this authority directly provides impersonation capability. If the system holding the delegation authority (for example, CLIENT01) is compromised by an attacker, the attacker can produce Kerberos tickets on behalf of different users through this system and access target systems. At this point, the attacker's success depends on the characteristics of the targeted user. For example, if a highly privileged user (such as Domain Admin) is impersonated, this directly results in privilege escalation and lateral movement.
Another reason why RBCD is particularly dangerous
is that control, unlike the classic delegation model, resides on the target system. While in traditional constrained delegation which service can access where is defined on the source side, in RBCD this control is given to the target side. This situation, if there are misconfigured Access Control List (ACL) permissions on the target system, can lead even a low-privileged user to modify this attribute and add themselves as an authorized principal. This makes RBCD a frequently used technique in modern Active Directory attacks.
Since this mechanism works entirely over the Kerberos protocol, it can bypass measures taken against NTLM-based attacks. Moreover, since Kerberos traffic is often considered "normal", the detection of such activities may be more difficult. In event logs, only standard ticket requests (for example 4769) are seen, and this situation is often not flagged as an anomaly.
Trust Relationships in Kerberos
In the Kerberos architecture, trust relationships are the fundamental structures that enable authentication to be carried out sustainably and securely across different security boundaries. Especially in large-scale enterprise environments, when a single domain or realm is not sufficient, users' ability to access different systems is made possible thanks to these trust mechanisms.
inter-domain trust
Cross-realm authentication
transitive/non-transitive trust
Inter-domain Trust
Inter-domain trust is the trust relationship established between different domains and enables users to access resources in another domain. This structure works through trust relationships and cryptographic keys shared between domain controllers. After a user authenticates in their own domain, when they want to access a target domain, they are routed thanks to this trust relationship and obtain the necessary service ticket. 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.
Each realm is an independent security area with its own Key Distribution Center (KDC). When a user in one realm wants to access a service in another realm, they cannot directly obtain a service ticket from the target realm. Instead, there is a previously established trust relationship between the two realms.
The user first obtains a Ticket Granting Ticket (TGT) from their own realm, then uses this TGT to obtain a referral TGT for the target realm. This referral process directs the client to the target realm's KDC. In the final stage, the user completes access by obtaining the necessary service ticket from the target realm. This structure is used to provide secure access between different organizations or federated systems. However, if one realm is compromised, the risk of pivoting to other realms through the trust relationship may arise.
Transitive Trust
One of the most critical features of trust relationships is transitivity. Transitive trust means that a domain indirectly trusts a third domain that another trusted domain trusts. For example, if a domain trusts another domain, and that domain trusts a third domain, this trust relationship expands in a chained manner. This approach facilitates management especially in large organizations because separate trust definitions are not needed for each domain. In Active Directory Forest structures, such trust relationships are transitive by default. However, this convenience also creates a serious security risk. The compromise of any domain in the chain can pave the way for attacks that propagate along the entire trust relationship.
Non-transitive Trust
In contrast, non-transitive trust is a trust model that is only valid between two domains and does not extend to other domains. This structure provides more controlled access by keeping the trust relationship limited. Trust is only valid between the two parties defined and is not automatically transferred to a third domain. This approach is preferred in environments with high security requirements because it narrows the attack surface. However, it requires more configuration from a management standpoint and is more limited in terms of flexibility compared to transitive trust.
Kerberos Hardening
Maximum Lifetime for Service Ticket
The maximum validity period of this ticket directly affects the attacker's access duration in the case of a potential security breach. If the service ticket duration is configured to be long, even if the user account is disabled or their permissions are changed, the attacker can continue to access the service using the existing ticket. This creates critical risk especially in lateral movement scenarios.
Shorter service ticket durations enable permission changes to be applied more quickly and limit the operational usage duration of compromised credentials. However, very short durations may increase KDC load. Configuration should be done by observing the balance between security and performance.
Enforce User Logon Restrictions
When this setting is enabled, the KDC re-checks the user's current permissions and logon restrictions on every service ticket request. This mechanism provides dynamic verification instead of static authorization.
If this setting is disabled, permissions previously granted to the user may remain valid for the duration of the ticket even if they have been revoked. This creates a serious vulnerability especially in privilege revocation scenarios.
Maximum Lifetime for User Ticket (TGT)
The Ticket Granting Ticket (TGT) is the main authentication token that enables the user to obtain new service tickets within the domain. The longer the TGT's validity duration, the longer the attacker's operation duration in case of compromise. Long TGT durations pose serious risk especially in Golden Ticket or Pass-the-Ticket attacks. Even if the user account is disabled, new service tickets can be obtained for a certain duration with a valid TGT.
While short TGT durations increase security, overly aggressive shortening can create additional load on the KDC. For this reason, the duration should be carefully determined.
Maximum Tolerance for Computer Clock Synchronization
Kerberos uses a timestamp mechanism to prevent replay attacks. For this reason, it is mandatory that the client and Domain Controller clocks are synchronized.
If the time tolerance is set too high, the window in which replay attacks can be applied widens. If set too low, authentication errors may increase in the production environment.
Maximum Lifetime for User Ticket Renewal
The renewability duration of the TGT affects a user's continuous session experience. However, from a security perspective, this duration also determines the persistence risk. A compromised TGT can be renewed throughout the renewal duration and provide long-term access. This situation is used in persistence techniques.
The renewal duration should be carefully determined. Long-term renewability provides an advantage for attackers.
Cryptographic Settings (Encryption Type Hardening)
When weak or old algorithms (especially DES and RC4) are left enabled, Kerberoasting and offline password cracking attacks become easier.
It is recommended that only AES128 and AES256 algorithms be used. Disabling RC4 reduces the risk of NTLM hash-based cracking.
Service Account Security
Service accounts are the most frequently targeted components in Kerberos attacks. Especially manually created service accounts whose passwords have not been changed for a long time and which hold broad privileges carry high risk. Service accounts with weak passwords can be easily compromised with Kerberoasting. SPN misconfigurations also increase the attack surface.
The use of Group Managed Service Accounts (gMSA), automatic password rotation, and the principle of minimum privilege significantly increase service account security. Service accounts should be positioned in accordance with the Tier model.
Account Lockout Policies
Account lockout policies play a critical role in limiting brute-force and password spraying attacks. However, if this policy is misconfigured, attackers can create Denial of Service.
A very low threshold value may cause service interruptions. A very high threshold value, on the other hand, increases brute force risk.
Lockout policies alone are not sufficient; they should be supported with monitoring.
Ticket Forwarding and Delegation Settings
The delegation mechanism enables a service to perform authentication on behalf of another service. However, misconfigured delegation can result in domain compromise.
Unconstrained delegation allows the attacker to collect TGTs and move freely within the domain.
Constrained delegation and especially Resource-Based Constrained Delegation (RBCD) offer a more controlled and secure model.
➔ The use of delegation should be minimized.
Disable NTLM (Kerberos Enforced Environment)
When NTLM is left enabled, even the Kerberos environment becomes open to downgrade attacks. NTLM relay and Pass-the-Hash techniques are still widely used.
Unless a Kerberos enforced architecture is built, systems can be infiltrated via NTLM.
The gradual disabling of NTLM and the use of Kerberos only is recommended.
Protected Users Group
The Protected Users group ensures that highly privileged accounts are protected with additional security layers. For accounts included in this group, NTLM, weak encryption, and delegation are prohibited.
In addition, TGT durations are shortened and credential caching is prevented. These features provide major security advantages, especially for Domain Admin and Tier-0 accounts.
Including highly privileged accounts in this group reduces credential theft risk.
Authentication Policies & Silos
Authentication Policies and Authentication Silos control which accounts can log on to which machines. This structure is the technical implementation of the tiered administration model.
Thanks to this mechanism, administrator accounts can only be used on specific administration workstations. This way, credentials are not exposed on low-security systems. This configuration reduces lateral movement risk.
Pre-Authentication Enforcement
The Kerberos pre-authentication mechanism prevents an AS-REP from being obtained without the user's password information. If pre-auth is disabled on an account, it becomes open to the AS-REP Roasting attack.
Pre-auth must be mandatory on all user accounts. Pre-auth disabled accounts should be regularly audited.
KRBTGT Account and Password Rotation
Since the KRBTGT account is the critical account that signs all TGTs within the domain, if this account's password is left unchanged, Golden Ticket attacks may remain valid for a long time.
If the KRBTGT hash has been obtained by an attacker, fake TGTs produced remain valid unless the password is changed.
- KRBTGT password should be changed periodically
- Applying a double reset after an incident (changing the password twice)
This operation should be carefully planned in order to avoid replication problems. At least 2 times a year (24 hours apart)
PAC (Privilege Attribute Certificate) Validation
The PAC field within a Kerberos ticket carries the user's group memberships. If PAC validation is not performed, the risk of privilege manipulation arises.
In modern Windows versions, PAC validation is enabled by default, but it should be checked on legacy systems.
PAC validation should not be disabled.
Audit Policy
Kerberos-related 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 performed on Kerberos flows and attack surface in real Active Directory environments.
