Unconstrained Delegation
May 18, 2025.
Did you know that an administrator only needs to connect once to a misconfigured machine to lose control of the entire domain? Today, we’ll discuss a critical configuration in Active Directory environments: Unconstrained Delegation.
Before diving deep into the topic, it’s essential to have a solid understanding of Kerberos authentication and some key Active Directory concepts.
For this, I highly recommend the following article, written by an expert in the field: Juan Antonio González Mena.
In Active Directory environments, there are mechanisms that allow certain services to act on behalf of users; this is known as delegation. It’s common to see this in scenarios where, for example, a web service needs to access a database as if it were the logged-in user.
However, as many might suspect, not all delegation configurations are equally secure 🫣. One of the most dangerous is the topic we’ll discuss today. The problem with this configuration is that it is excessively permissive, allowing a service to freely access other services on behalf of any user who authenticates to it, without any restrictions.
In this article, we will analyze how it works and why it poses a serious risk in corporate environments. The approach will be purely theoretical.
How does it work this configuration?
To begin explaining the topic in depth, I will rely on an image that, in my opinion, is pure gold for perfectly understanding what we are talking about.
It shows a user authenticating against the Domain Controller using Kerberos. What interests us is what happens once the user successfully receives a Service Ticket (TGS) to authenticate against Service A — which is the one with the vulnerable configuration 😈.
Once a user — let’s assume an administrator to illustrate the worst-case scenario — authenticates to Service A, their Ticket Granting Ticket (TGT) is handed over to the service, which stores it in the LSASS process. This means the administrator’s TGT is stored within Service A. If an attacker gains access to this service, they can extract that TGT using tools like Rubeus or Mimikatz.
With the administrator’s TGT in our possession, the next step is to request a Ticket Granting Service (TGS) ticket to access another service using the stolen TGT. Once we obtain the TGS for the target service (Service B), we can authenticate to it with administrator privileges.
In short, a seemingly insignificant configuration like Unconstrained Delegation can become an open door for an attacker who, with minimal access to a misconfigured service, can compromise the entire domain. That’s why it’s crucial to avoid unconstrained delegation and implement safer alternatives such as Constrained Delegation or, even better, protocol-specific delegation.
I hope this brief article has helped you better understand this configuration. 🫡
Last updated