what is delegation?
In Active Directory (AD), delegation refers to the process of granting specific permissions to users or groups so that they can perform certain administrative tasks within the AD environment without having full administrative privileges. This allows organizations to distribute administrative tasks across different individuals or teams, reducing the burden on central administrators and providing more granular control over who can perform which tasks.
Delegation in AD can be done at various levels, including the domain level, organizational unit (OU) level, or even specific objects within the directory. Common tasks that can be delegated include managing user accounts, group memberships, computer objects, Group Policy settings, and more.
Delegation is typically achieved by assigning the appropriate permissions to users or groups using the Active Directory Users and Computers (ADUC) console or through PowerShell commands. It’s important to carefully plan and document delegation strategies to ensure that administrative tasks are appropriately distributed while maintaining security and compliance requirements.
Understanding Different Types of Delegation in Active Directory
- Unconstrained Delegation:
- Unconstrained delegation allows a service to delegate a user’s credentials to any other service on behalf of the user without any restrictions.
- When unconstrained delegation is enabled for a service account in Active Directory, it can impersonate the user’s identity and access any service using the user’s credentials without any limitations.
- While unconstrained delegation provides flexibility, it poses security risks as it allows unrestricted access to a user’s credentials, potentially exposing sensitive information if the service account is compromised.
- Constrained Delegation:
- Constrained delegation allows more control over which services a service can delegate a user’s credentials to.
- With constrained delegation, administrators can specify specific services that a service account is allowed to delegate credentials to, limiting the scope of delegation.
- There are two types of constrained delegation: Kerberos constrained delegation and resource-based constrained delegation.
- Resource-Based Constrained Delegation:
- Resource-based constrained delegation is a newer feature introduced in Windows Server 2012 that provides a more flexible and secure way to delegate authentication to services.
- Unlike Kerberos constrained delegation, which is configured on the service account, resource-based constrained delegation is configured on the computer object representing the service.
- Administrators can specify which users or groups are allowed to delegate credentials to the service, as well as the specific services or resources that the service can access on behalf of the user.
- Resource-based constrained delegation offers finer-grained control over delegation permissions and is recommended for scenarios where more control and security are required.
These types of delegation provide different levels of control and security over the delegation of user credentials in Active Directory, allowing organizations to balance flexibility with security according to their specific requirements.
Let’s examine how an attacker may exploit these three different types of delegations.
First, we look into constraint delegation.
What is Constrained Delegation? Constrained Delegation is a feature in Active Directory that allows a service to impersonate a user’s identity and access resources on their behalf. It enables the delegation of a user’s authentication credentials from one service to another, granting the second service the ability to act on behalf of the user while accessing resources.
How does it work? To understand Constrained Delegation, let’s consider a scenario where User A needs to access resources stored on Server B, but User A’s authentication is managed by Service C. In a traditional setup, Service C would need to handle authentication for User A and then retrieve the requested resources on User A’s behalf, which can be cumbersome and time-consuming.
With Constrained Delegation, however, Service C can delegate the authentication credentials of User A to Server B. Server B, equipped with the delegated credentials, can then impersonate User A and directly access the required resources. This streamlined approach eliminates the need for Service C to act as a middleman for every resource request, improving performance and user experience.
Authentication Flow
- User initiates a request for resource access.
2. The front-end service (Server A) obtains a Ticket-Granting Ticket (TGT) on behalf of the user.
3. Server A requests a Service Ticket from the Key Distribution Center (KDC) for the target service (Server B).
4. Server A delegates the user’s authentication credentials to Server B by attaching the service ticket.
5. Server B receives the delegated credentials, validates the service ticket, and accesses the requested resource on behalf of the user.
This concise representation summarizes the main stages of the Constrained Delegation Authentication Flow, where the front-end service acts as an intermediary, obtaining and delegating the user’s credentials to another service for resource access.
Attack Demonstration
The assumption behind this attack is that the attacker already has admin privileges on the machine that was assigned to them. Access is typically gained using a service account and Kerberoasting or OverPassing the hash with stolen or dumped hashes from other computers. Here is a list of the necessary steps:
1. The delegated hosts’ identification.
2. Asking the domain controller with the delegated account for forwardable TGT tickets.
3. Using the received forwardable TGT tickets to request service tickets.
4. Getting the services you’ve asked for.
By looking at the msDS-AllowedToDelegateTo attribute in the accounts information, we can begin our search for the constrained delegation accounts. The attribute includes a list of the services that can be delegated. The Active Directory module or PowerView Dev script can be used to enumerate these accounts.
Get-DomainUser -TrustedToAuth 2>$null and Get-DomainComputer -TrustedToAuth 2>$null can both be used with PowerView Dev to retrieve limited user and computer accounts, respectively.
We can achieve the same output with the AD module by running the Get-DomainComputer cmdlet and filtering for the msds-allowtodelegate property.
Get-DomainComputer -TrustedToAuth 2>$null
According to the outputs above, accounts permit delegation to particular services. The first is a user account called “websvc,” which permits delegation to the CIFS services on the MSSQL server, and the second is a computer account called “dcorp-adminsrv,” which permits delegation for the Time service on the domain controller.
The risk here is that if an attacker takes over these delegated accounts, they may request services that are not authorised and launch further assaults. In our situation, we have the option to replace the CIFS and TIME services with LDAP or WMI and remotely dump credentials, as we shall do in the following 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.
To request TGT tickets for the “massda.local” and “dc01.massda.local” accounts in Rubeus, we utilise the asktgt module. In order to obtain a forwardable TGT on behalf of a user, a service can do so in this step using the S4U2self extension.
.\Rubeus.exe tgtdeleg
We can now request service tickets for the permitted services, like as CIFS and TIME, or alternative services like LDAP or WMI, after acquiring the TGT tickets from the domain controller.
We will utilise the Rubeus s4u module and the TGT tickets acquired in the previous phase to request service tickets (TGS) for the permitted services. The value of the msDS-AllowedToDelegateTo property, which we discovered earlier in the enumeration steps, is the msdsspn value.
The SPN for the service-adminsrv account is “TIME/servic-DC,” and for the service account it is “CIFS/app-svc.local.” Administrator is the false user.
Ask for TGS using TGT
.\Rubeus.exe s4u /ticket:TGT_Ticket /msdsspn:”service/HOST” /impersonateuser:Administrator /ptt
As we previously discussed, in addition to performing further attacks like remotely dumping the machine’s credentials, we may also swap out the allowed services for alternative ones.
To do this, we may utilise Rubeus’s **s4u** module and feed it the delegated SPN (“msdsspn”) and the service (“altservice”) we wish to switch to. In our situation, the DCSync attack can be carried out by switching between LDAP and the domain controller’s time service.
.\Rubeus.exe asktgt /user:pc-1 /domain:domain.local /ntlm:b4d1c5a9712cdb684c49ead7a9a36d /outfie:pc.tgt
Ask for TGS
.\Rubeus.exe s4u /ticket:pc.tgt /msdsspn:”CIFS/DC-1.domain.local”
/impersonateuser:Administrator /ptt
Running Klist reveals the LDAP ticket generated for the fictitious user “Administrator,” which allows us to do the DCsync attack and retrieve the krbtgt hash.
dir \\DC-1.domain.local\C$
