Cybercrime is a growing concern in today’s society, this problem is only expected to worsen, especially with the increasing risk posed to mobile devices. In response to this, security experts are constantly seeking new strategies to enhance cybersecurity. One such strategy is the use of Kerberos, a network security protocol that authenticates service requests between trusted hosts on untrusted networks. Developed by MIT, Kerberos is now the default authorization technology used by Microsoft Windows, with implementations for other operating systems as well. This protocol, named after the mythical three-headed dog, ensures secure authentication and ticket-granting through shared secret cryptography, protecting against eavesdropping and replay attacks.
What is Kerberos Delegation?
Kerberos delegation has a long history, dating back to Windows Server 2000. However, many engineers working with Active Directory are often unfamiliar with the various implementations of Kerberos delegation, their purposes, and the potential for misuse. It is common for individuals to mistakenly equate Kerberos delegation with delegated permissions. The practical application of Kerberos delegation is to facilitate an application’s access to resources stored on a different server. For example, a web server may need to access resources, such as a SQL database, hosted elsewhere for a website. Instead of granting the web server’s service account direct access to the database, the service account can be delegated to the SQL server service. When a user logs into the website, the service account will request access to the SQL server service on behalf of the user. This allows the user to access the content in the database they have been authorized for, without needing to provision any access for the web server’s service account itself.
Types of Kerberos Delegation
Over the years, several variations of Kerberos delegation have emerged. The initial implementation, known as unconstrained delegation, was introduced in Windows Server 2000. However, more secure versions of delegation, namely constrained delegation and resource-based constrained delegation, have since been developed. The following sections will delve into each type of delegation in greater detail. To set up delegation on a computer or user account, navigate to the Delegation tab in Active Directory Users and Computers. It is important to note that user accounts must have a servicePrincipalName (SPN) assigned. The first option in the tab enables configuration of an account to explicitly disallow trust for delegation. This setting is commonly applied to sensitive or administrative accounts that should never be used for delegation. The second option permits unconstrained delegation for an account, while the third option facilitates configuration for constrained delegation.
Unconstrained Delegation
This is the original implementation of delegation, and it is also the least secure. When “unconstrained delegation” is enabled, the “TRUSTED_FOR_DELEGATION” flag is added to the userAccountControl attribute of the object. This allows the object to store the ticket-granting ticket (TGT) in memory when it authenticates to a host with unconstrained delegation enabled. Consequently, the host can later impersonate that user if necessary. Consider a scenario where a privileged account authenticates to a host with unconstrained delegation enabled. This account can access any service configured within the domain as the privileged user. To make matters worse, what if there were methods to automatically force privileged accounts to authenticate to your host? By exploiting the “printer bug”, you can force a domain controller to authenticate to your host, thereby leaving the TGT for that account in memory.
Constrained Delegation
Introduced in Windows Server 2003, this feature enables the configuration of services that an account can be delegated to, thereby limiting potential exposure in the event of a compromise. It should be noted that constrained delegation does not function across different forests.
When constrained delegation is applied to an account, two operations take place:
- The userAccountControl attribute is updated with the “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION” flag.
- The msDS-AllowedToDelegateTo attribute is populated with the specified SPN on the delegation tab.
Exploiting constrained delegation differs from exploiting unconstrained delegation. One possible method of abuse involves gaining access to the plaintext password or NTLM hash of a user account configured for constrained delegation. By using a tool like Kekeo, attackers can request a TGT (Ticket Granting Ticket) for the compromised account, execute a TGS (Ticket Granting Service) request for any user (excluding those labeled as ‘Sensitive’), and then inject the ticket to gain access to the requested service as that user.
Resource-Based Constrained Delegation
Introduced in Windows Server 2012, the resource-based constrained delegation feature changes the way in which you can set up constrained delegation across trusts. Instead of determining which object can delegate to a specific service, the resource that hosts the service now determines which objects are allowed to delegate to it. From an administrative perspective, this enables the owner of the resource to have control over who can access it. For example, instead of specifying that the WebServer service account can delegate to the SQL Service account in order to access the database, you can now specify that the SQL server service account has permissions to delegate access to it by the WebServer service account. To configure resource-based constrained delegation, you must populate the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target resource with the security identifier (SID) of the authorized object that is allowed to delegate to it. This configuration can only be done using PowerShell, as there is no graphical user interface (GUI) component available in Active Directory Users and Computers, and the Attribute Editor page does not allow manual modification of this attribute.
How Lepide Helps
The Lepide Data Security Platform can identify and mitigate various vulnerabilities that may exist in your Active Directory, such as excessive permissions, “shadow” admins, stale accounts, and weak passwords. It also allows you to control AD configurations and permissions, enforce strong password policies, and prevent credential theft. The platform is able to detect and respond to advanced threats, such as Ransomware, enabling you to stop bad actors before they complete their mission. In the event of a security breach, the platform can automate a response that can instantly contain the breach, minimizing any potential damage to your business.
If you’d like to see how the Lepide Data Security Platform can help to secure your Active Directory, schedule a demo with one of our engineers or start your free trial today.
Important Group Policy Settings & Best Practices to Prevent Security Breaches
15 Most Common Cyber Attack Types and How to Prevent Them
Why Active Directory Account Getting Locked Out Frequently – Causes
