Introducing StealthAUDIT 11.5! Complete your cloud security puzzle. LEARN MORE

Unconstrained Delegation Permissions

Blog >Unconstrained Delegation Permissions

AD Permissions Attack #4: Unconstrained Delegation Permissions

In this series, we’ve explored a few ways to take advantage of weak Access Control Lists (ACLs) to compromise Active Directory accounts and elevate our privileges. In this post, I will dive deeper into a more complex attack against Active Directory and show how permissions are once again critical to protecting yourself from a complete domain compromise. This particular attack leverages the delegation controls that can be applied to user and computer objects within Active Directory. This area of attack (unconstrained delegation permissions) is often overlooked by administrators—but can be extremely effective for an attacker to exploit. Let’s take a look.

What is Delegation?

Delegation is a feature of Active Directory that allows a user or a computer to impersonate another account. This has several practical applications, which Microsoft covers in this blog post.

This feature can be configured through the Delegation tab on a user or computer account. By selecting “Trust this computer for delegation to any service (Kerberos only),” you are enabling “unconstrained delegation”. Alternatively, you can specify a set number of Service Principal Names (SPNs) to restrict exactly what services a user or computer can impersonate, which would be considered “constrained delegation”.

Enabling unconstrained delegation or constrained delegation on an Active Directory user or computer account with permissions and user rights

The ability to manage this setting is controlled by permissions and user rights, which we will be exploring later in the post. 

What’s the Risk of Unconstrained Delegation?

There are several attacks against delegation that can be perpetrated. Once you turn on unconstrained delegation to a computer, any time an account connects to that computer for any reason, their ticket-granting ticket (TGT) is stored in memory so it can be used later by the computer for impersonation. Let’s say you enable this option on a computer you have administrative access to and then get a Domain Admin user to access the computer over the Common Internet File System (CIFS) by accessing a shared folder. Without unconstrained delegation on, only the ticket-granting server (TGS) would be stored in memory on your compromised machine. This ticket gives access only to the CIFS service on your machine so you can’t use it to move laterally. However, with unconstrained delegation enabled, when the privileged user connects to your machine, their TGT will be stored in memory, which can be replayed to move laterally and compromise a domain controller.

TGS ticket captured on a computer without unconstrained delegation enabled

To illustrate, let’s use Mimikatz to export all tickets in memory with the command sekurlsa::tickets /export. Without delegation enabled, when the Administrator user connects to my server, all I get is the TGS ticket and no TGTs: 

TGT ticket captured on a computer with unconstrained delegation enabled to use Kerberos::ptt command to pass-the-ticket and get Domain Admin rights

However, by enabling unconstrained delegation and connecting to the system again, now I get the TGT for the Administrator: 

Now I can use the Kerberos::ptt command to pass-the-ticket and get Domain Admin rights to my domain controller, leading to a complete domain compromise.

There are also several other ways to attack the delegation settings. Some are covered in this blog post by harmj0y and more on unconstrained delegation from Sean Metcalf can be found here.

How Permissions Control Delegation

As with anything in Active Directory, delegation on computers and users can be controlled through permissions. There are two sets of rights needed for a user to be able to manage the delegation controls of an object:

  • SeEnableDelegationPrivilege user right
  • Object permissions to msDS-AllowedToDelegateTo attribute, userAccountControl, and/or servicePrincipalName
Using SeEnableDelegationPrivilege to enable computer and user accounts to be trusted for delegation user right assignment

SeEnableDelegationPrivilege is a user right that is controlled within the Local Security Policy of a domain controller and is managed through Group Policy. This setting is named “Enable computer and user accounts to be trusted for delegation”. It is very important to understand who has been granted this right within Active Directory because all they will need is write access to a computer to turn on delegation and begin to harvest TGTs from any user that connects to the system. 

Besides the SeEnableDelegationPrivilege right, you will need the ability to update msDS-AllowedToDelegateTo and userAccountControl attributes for a computer, which is where these settings are stored.

Discovering Who Can Delegate

Using PowerShell command Get-ADComputer to return all computers with unconstrained delegation

One of the first things you may want to do is find out where unconstrained delegation has already been enabled. To do so, you can use the following PowerShell script that will search for the User Account Control (UAC) value of all computers to see where delegation is turned on without restrictions. 

PowerSploit Get-DomainPolicy command to identify who has the SeEnableDelegationPrivilege right in the Default Domain Controllers Policy

Also, you may want to look at who has been granted the SeEnableDelegationPrivilege right. To do this, you can use PowerSploit and the Get-DomainPolicy command. Below you can see the default Administrators group is there, as well as a domain group Security Identifier (SID). 

Protections from Unconstrained Delegation

It is rare that unconstrained delegation is needed. In most cases, you should be able to turn on constraints to limit the SPNs delegation can work for. Also, placing privileged users in the Protected Users group will prevent them from being used in delegation and keep their TGTs off these computers after they authenticate. The same goes for the Account, which is sensitive and cannot be a delegate option.

This is the final installment in our blog series, 4 Attacks that Exploit Active Directory Permissions and How to Protect Against Them. To view the previous blogs, please click on the links below.

To watch the AD Permissions Attacks webinar, please click here.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:


Featured Asset

Comments (2)

  • Thank you. Thats a really nice article. Well explained.
    Also within the “What’s the Risk of Unconstrained Delegation?” Section you mention without the unconstrained delegation enabled, the TGS (Ticket Granting Server) is stored in memory.

    Shouldnt this be the service granting ticket (SGT) which is what you have shown in your mimikatz screenshot Server : CIFS xxxx

    • Thanks for the comments! In that section I am illustrating without unconstrained delegation enabled on that computer, we capture the service ticket only, which is the CIFS ticket you see. This is commonly referred to as the TGS but the basic concept is this ticket gives access to a user for a specific service on a specific host. With unconstrained delegation enabled, you see the second screenshot where we get the krbtgt ticket which is the TGT and can be used to request new TGS tickets for that user which enables lateral movement so much riskier. Hopefully that helps and if not happy to go deeper into this!

Leave a Reply

Your email address will not be published. Required fields are marked *




© 2022 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.