R3d Buck3T
Published in

R3d Buck3T


Attacking Kerberos Constrained Delegation

Trust this user/computer for delegation to specified services only

Delegation is the act of giving someone authority or responsibility to do something on behalf of someone else. In the Active Directory, delegation is a feature that enables specific accounts (user or computer) to impersonate other accounts to access particular services on the network.

There are three (3) known types of delegations allowed with Kerberos: Unconstrained, Constrained, and Resource-based constrained delegations. For this article, we will focus on the Constrained delegation. We will learn to abuse this type of delegation during a penetration testing engagement and chain it with other attacks such as DCSync to obtain the domain controller hashes.

The attack demonstration steps will be on the Pentester Academy Active Directory Lab by Nikhil Mittal associated with the CRTP course. Below is the breakdown of the key concepts we will discuss in this article.

Key Concepts

Constrained Delegation Overview

Constrained delegation allows the account with the “Trust this user/computer for delegation to specified services only” enabled to impersonate ANY user to access specific services listed in the allowable delegation list.

As seen below in Figures 1 and 2, delegation properties are set for specific service types and hosts (Service Principal Names - SPNs) for user or computer accounts.

Figure 1 — shows the configuration of a constrained delegation for a user (source: Microsoft).
Figure 2— shows the configuration of a constrained delegation for a computer (source: iredteam).

This type of delegation gives a massive responsibility to the front-end services to authenticate the user. In this case, the user doesn’t authenticate to the Kerberos domain controller (KDC) directly. Instead, it will authenticate to the service first, then the service impersonates the user to access the requested resource.

Kerberos Protocol does this type of delegation with two (2) extensions:

  • Service for User to Self (S4U2Self) — Kerberos protocol transition extension.
  • Service for User to Proxy (S4U2Proxy) — Kerberos Constrained Delegation extension.

Authentication Flow

To understand the authentication flow, let’s take an example of a user authenticating to a constrained delegated account like a web service account that only allows delegation to SQL services. The authentication flow would consist of six (6) main steps.

  1. A user authenticates to the web service with username only (no password needed).

2. The web service sends a request to the KDC impersonating the user to request a Forwardable TGT — (Figure 3).

3. The KDC checks whether the web service account is allowed for delegation and whether the user is active and not blocked. Then, the KDC sends the TGT ticket to the web service if everything is verified accordingly — (Figure 3).

📍This step uses the Service for User To Self (S4U2self) extension that allows a service to obtain a forwardable TGT on behalf of a user.

Figure 3 — shows the web server impersonates Tim and receives a TGT ticket for the KDC.

4- The web service caches the Forwardable TGT locally and sends it back to the KDC to request a service ticket (TGS) for a SQL service — (Figure 4).

5- If the SQL service is allowed in the delegation list of SPNs, the KDC will grant the SQL TGS ticket — (Figure 4).

📍This step uses the Service for User to Proxy (S4U2proxy) extension allows the service to obtain a TGS of a second service on behalf of a user.

Figure 4 — shows the web server received SQL TGS from the KDC.

6- Once the web server gets the ticket, it will send it to the SQL server to request access to its data and retrieve the information needed for the user — (Figure 5).

Figure 5 — shows the webserver accessing the SQL servers and retrieving the data back to the user.

🚩Attack Requirements

  • A user or computer account with the delegation option enabled — “Trust This user/computer for delegation to specified services only”.
  • Local admin privileges on the delegated compromised host. If you compromised the server as a regular user, you would need to escalate to admin to abuse this delegation feature.

🛠️ Used Tools

Attack Demonstration

This attack assumes that the attacker already has access to the delegated machine with admin privileges. Access is usually obtained through service account Kerberoasting or OverPass the hash with dumped hashes compromised from other machines. Here is the breakdown of the needed steps:

◼️ Identifying the delegated hosts.

◼️ Requesting forwardable TGT tickets from the domain controller with the delegated account.

◼️ Requesting service tickets with the obtained forwardable TGT tickets.

◼️ Accessing the requested services.

We start looking for the constrained delegation accounts by checking the msDS-AllowedToDelegateTo attribute in the accounts details. The attribute lists the services allowed for delegation. These accounts can be enumerated with the PowerView Dev script or Active Directory module.

With PowerView Dev, we can run Get-DomainUser –TrustedToAuth 2>$null to get the constrained user accounts and Get-DomainComputer –TrustedToAuth 2>$null to get the computer accounts.

Figure 6 — shows the web_svc has constrained has delegation feature enabled for CIFS only.
Figure 7 — shows the web_svc has constrained has delegation feature enabled for CIFS only.

We can achieve the same output with the AD module by running the Get-ADObject cmdlet and filtering for the msds-allowtodelegate property.

Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo
Figure 8 — shows the services listed in the msDS-AllowedToDelegateTo attribute.

The above outputs show that two (2) accounts allow delegation to specific services. One is a user account, “websvc,” which enables the delegation to the CIFS services on the MSSQL server, and the other is a computer account, “dcorp-adminsrv,” allowing the delegation for the Time service on the domain controller.

The danger here is that if an attacker gains control of these delegated accounts, they can request alternate services to what is allowed and perform additional attacks. In our case, we can alternate the CIFS and TIME services with LDAP or WMI and dump credentials remotely, as we will in the later steps.

The next step is to request Forwardable TGTs from KDC for our delegated accounts, we can use either Rubeus or Kekeo for this step. I am going to use Rubeus for this article.

For Rubeus, we use the asktgt module to request the TGT tickets for the “websvc” and “dcorp-adminsrv” accounts. This step uses the S4U2self extension that allows a service to obtain a forwardable TGT on behalf of a user.

rubeus.exe asktgt /user:userName /domain:DomainName /ntlm:Hash /outfile:FileName.tgt
Figure 9 — shows obtaining the TGT ticket for the websvc account.
Figure 10 — indicates getting the TGT ticket for the adminsrv account.

After obtaining the TGT tickets from the domain controller, we can now request service tickets for the allowed services, i.e., CIFS and TIME, or alternate services like LDAP or WMI.

To request service tickets (TGS) for the allowed services, we will use the s4u module in Rubeus and the obtained TGT tickets in the previous step. The msdsspn value is the value of the msDS-AllowedToDelegateTo attribute we found earlier in the enumeration steps.

The SPN for the websvc account is “CIFS/dcorp-mssql”, and for the dcorp-adminsrv is “TIME/dcorp-DC ‘’. The impersonated user is Administrator.

.\Rubeus.exe s4u /ticket:TGT_Ticket /msdsspn:"service/HOST" /impersonateuser:Administrator /ptt
Figure 11- shows obtaining the CIFS TGS ticket for the websvc account.

To verify our access to the service, let’s try accessing the directories on the MSSQL service and see if we can list them. As seen, we have successfully listed the directories on the server with the obtained TGS ticket.

Figure 12 — shows listing the directory contents of the MSSQL server with the new issues TGS ticket.

We mentioned earlier that we could also alternate the allowed services with other services and perform additional attacks like remotely dumping machine’s credentials.

To do that, we can use the s4u module in Rubeus, pass it the delegated SPN “msdsspn,” and the service we want to alternate to “altservice.” In our case, we can alternate the time service on the domain controller with LDAP to perform the DCSync attack.

.\Rubeus.exe s4u /ticket:adminsrv.tgt /msdsspn:"TIME/dcorp-DC" /impersonateuser:Administrator  /altservice:LDAP /ptt
Figure 13 — shows obtaining an LDAP service ticket as an alternative to the Time service.

Running Klist shows us the LDAP ticket created for the impersonated user “Administrator,” and with that, we can perform the DCsync attack and obtain the krbtgt hash.

Figure 14 — show the LDAP service ticket.
Figure 15- shows performing the DCSync attack and gaining the krbtgt hash of the dc.

As seen above, we successfully retrieved the krbtgt hash; no additional permissions were required to perform this attack other than the LDAP service ticket.


  • To mitigate against the abuse of delegated accounts, we can ensure that the privileged accounts are configured to “Account is sensitive and cannot be delegated” within the Active Directory or added to the Protected User group to prevent delegation.
  • If delegation is needed for specific accounts, they should be secured with firewall rules that only serve the purpose and delegation to the required service and limit any other privileged access that might not be necessary.
  • Also, ensure the delegated accounts use strong passwords to protect them against attacks like Kerberoasting.

That’s all for this article; we learned about constrained delegation and how to abuse it in an Active Directory environment to gain access to other services than the allowed ones and leverage that access to perform different attacks.

Thanks for reading !!

🔔 All of the used commands can be found at R3d-Buck3T — (Active Directory — Privilege Escalation — Constrained Delegation)



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nairuz Abulhul

Nairuz Abulhul

I spend 70% of the time reading security stuff and 30% trying to make it work !!! aka Pentester >>Security Researcher