As is often the case with Active Directory, some of the worst security gaps are caused by misconfigurations that leave open doors for potential cyber threats. One common setting that cybercriminals love to exploit is unconstrained delegation.
What is unconstrained delegation, and why is unconstrained delegation a security risk? Delegation is the action of allowing a computer to save a user’s Kerberos authentication tickets, then use those tickets to impersonate the user and act on that user’s behalf. Unconstrained delegation is a configuration setting that many multi-tiered web applications require to function. But the setting has security implications, as a computer that stores the Kerberos ticket information for a bunch of users would be an obvious target for attackers. If the attackers can grab those tickets, they can act with the identity and privilege of those users.
If this setting is so risky, why do administrators configure servers with unconstrained delegation instead of traditional constrained delegation? Probably because in early versions of the Active Directory environment, it was the only form of delegation supported, and it’s also the easiest to configure, requiring only a single checkbox. And if configuring unconstrained delegation makes the application work, it’s all good, right? But there is, in fact, an excellent reason to revisit this setting. Removing unconstrained delegation eliminates a weak link in a chain of trusted authentication that could cause significant damage if it is abused.
Related reading
Roots of unconstrained delegation
The roots of this potential security risk can be traced back 20 years. Microsoft introduced Kerberos unconstrained delegation in Windows Server 2000 to allow services to access other services on behalf of an authenticated user so they would not have to reauthenticate. For example, if a user has authenticated to a web server, that web server can then impersonate the user and access back-end databases without the user having to re-enter their credentials. When unconstrained delegation is enabled on an account, it can impersonate the user to any service in the same domain.
While this functionality made life easier for users (and admins), it also presented an obvious risk. If a server with unconstrained delegation enabled was under the control of threat actors, they could abuse this trust to gain widespread access throughout the environment. Microsoft sought to mitigate this risk by introducing constrained delegation in Windows Server 2003, which allowed domain administrators to restrict what services a particular server could access.
With the release of Windows Server 2012, Microsoft gave service administrators the power to decide whether front-end services could access back-end resources. Before this change, only a domain administrator could control delegation privileges, leaving service administrators with no easy way to know what front-end services could access the resource they owned and, therefore, what potential attack paths might be open. Known as resource based constrained delegation (RBCD), this approach to Active Directory delegation is the hardest to abuse.
By comparison, unconstrained delegation is the least secure. If attackers can abuse an unsecure Kerberos delegation, they can mask all manner of malicious activity by mimicking a legitimate user. A threat actor with access to a web server with this configuration could steal the user’s Ticket Granting Ticket (TGT), which is stored in the server’s memory, and use it to impersonate that user and leverage their access privileges or improve access through privilege escalation. This reality makes unconstrained delegation an ideal mechanism for lateral movement throughout the environment. A TGT belonging to a domain administrator, for example, could give the attacker access to any service of their choice—or to potentially access a KRBTGT account and launch a Golden Ticket attack.
An attacker can use the Active Directory PowerShell module cmdlet Get-ADComputer to find computers with this setting enabled and then go to work. They can use Mimikatz, for example, to extract every service ticket in the system’s memory. The negative implications of this are clear.
Improve AD security by disabling unconstrained delegation
The good news is you can close the security gap created by unconstrained delegation by simply disabling this setting. For unconstrained delegation to take effect, domain administrators must enable it for accounts by checking “Trust this computer for delegation to any service (Kerberos only)” under the Delegation tab in the ADUC management console.
Given the high stakes of enabling this setting, organizations can improve their security posture by identifying any servers with unconstrained delegation enabled, disabling the setting, and replacing it with constrained delegation for servers that require it. Admin accounts should be set to “Account is sensitive and cannot be delegated,” and high-privilege accounts should be placed in the Protected Users Security Group. Admins can scan for forests with incoming trusts that permit TGT delegation and any security principals that allow unconstrained delegation using the PowerShell scripts. You can also detect unconstrained delegation by examining Windows events. When a Kerberos ticket is issued, an Active Directory domain controller logs security events that contain information about the target domain. You can examine those events to determine whether unconstrained delegation is being used across incoming trusts. Or you can download and run Purple Knight, a free security assessment tool built by Semperis AD experts that scans your AD environment for 80-plus security indicators, including unconstrained delegation.
Disabling unconstrained delegation might cause compatibility issues for some applications that rely on the feature, meaning you’ll have to reconfigure those applications to use constrained delegation or RBCD. As always, organizations need to remember that AD security includes more than just patching code vulnerabilities. Preventing attacks also means taking steps to reduce the attack surface and proactively preventing issues before they arise.
