Intro
Unconstrained delegation is a setting in Active Directory that allows a computer to impersonate a user and perform actions on their behalf. This feature is enabled by default on domain controllers in Active Directory.
Concept Explained
Imagine you have a big library with lots of books. Some of the books are really special and can only be checked out by certain people.
When a person wants to check out one of these special books, they have to show their library card to the librarian. The librarian then uses their computer to access the information about the person and the book to make sure everything is okay.
Now, imagine that the librarian has a friend who also works at the library, and the librarian wants to help their friend out by checking out the special book for them. To do this, the librarian has to tell their friend their password so they can access the information about the person and the book.
This is like enabling unconstrained delegation in Active Directory. When a user authenticates to a system, the domain controller places a copy of the user’s TGT into the service ticket. The resource server that the user is accessing then opens the service ticket, retrieves the user’s TGT, and places it into the LSASS process in memory. This allows the resource server to impersonate the user and perform actions on their behalf.
Blue TEam Perspective
Unconstrained delegation is enabled by default on domain controllers to facilitate specific tasks, such as Kerberos authentication, which require the capability to forward user credentials to other services within the network.
However, enabling unconstrained delegation, especially on non-domain controller hosts, poses a security risk and does not provide any substantial benefits. These hosts do not typically require the ability to impersonate multiple clients or forward user credentials, and as such, there is no need to enable unconstrained delegation on them. This is not to say you shouldn’t attempt to remove unconstrained delegation on your domain controllers, but it does cause increased overhead on your admins to manage this. Domain controllers are expected to have a higher level of security compared to typical servers and computers, which reduces the potential risk.
If constrained delegation is used, it will become necessary for administrators to manually configure delegation for each individual service in the network. This involves specifying a service account to use when acting on behalf of the user for each service and knowing the authentication methods. The manual configuration process can be time-consuming, particularly if new services are frequently added, removed, or updated across the environment. However, if the necessary resources are available to manage this effectively, it can have a positive outcome overall.
Microsoft has a great write-up on configuring Kerberos constrained delegation for web enrollment proxy pages here as an example which would provide additional information in this context to how it works.
Red Team Perspective
It’s important to consider the potential consequences if an attacker were to successfully gain access to a host configured with unconstrained delegation. In such a scenario, the attacker would immediately have access to all Ticket Granting Tickets (TGTs) of all users who have authenticated on that host.
An attacker that compromises a host configured with unconstrained delegation would immediately have access to all Ticket Granting Tickets (TGTs) of all users who have authenticated on that host.
Pentestlab has published a comprehensive blog on the exploitation of unconstrained delegation from an adversarial perspective. The blog provides valuable insights into the practical aspects of securing these settings and highlights the importance of implementing appropriate safeguards. I strongly recommend reading the blog for a deeper understanding of the topic and implications of having hosts set to use unconstrained delegation.
Script
This script will identify all hosts in an Active Directory domain that have unconstrained or constrained delegation enabled. If configured with constrained delegation, it will identify what it is allowed to delegate to. Results output to a csv file called C:\temp\AD_Delegations_$(Get-Date -Format yyyy-MM-dd).csv.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
# Check if the Active Directory module is already imported
if (!(Get-Module -Name ActiveDirectory)) {
# Import the Active Directory module
Import-Module -Name ActiveDirectory
}
# Get the current date and set days ago
$currentDate = Get-Date
$DaysAgo = $currentDate.AddDays(-30)
# Exclusion list for approved/known hosts (set this if you make this a scheduled report and want to exclude known hosts)
$excludeComputers = @("0123456789abcdefghijklmnopqrstuvwxyz", "123456789abcdefghijklmnopqrstuvwxyz")
# Get a list of all computer objects in the domain that were last logged on within the last $DaysAgo days
$computers = Get-ADComputer -Filter * -Properties LastLogonDate, Description | Where-Object {$_.LastLogonDate -gt $DaysAgo}
# Line to exclude DC OU from results as necessary (your OU name may vary)
# $computers = Get-ADComputer -Filter * -Properties LastLogonDate, Description | Where-Object {$_.LastLogonDate -gt $DaysAgo} | Where-Object {$_.DistinguishedName -notlike "*,OU=Domain Controllers,*"}
# Create an empty array to store the results
$results = @()
# Loop through each computer object
$computers | ForEach-Object {
# Check if the computer is in the exclusion list
if ($excludeComputers -notcontains $_.Name) {
# Check if the computer has Unconstrained Delegation enabled
$delegation = Get-ADComputer $_.Name -Properties TrustedForDelegation, msDS-AllowedToDelegateTo
# If the computer has Unconstrained or Constrained Delegation
if ($delegation.TrustedForDelegation -eq "True" -or $delegation.'msDS-AllowedToDelegateTo') {
# Get the list of SPNs that are allowed to delegate user authentication to the account
$spns = $delegation.'msDS-AllowedToDelegateTo'
# Check if the account is set to unconstrained or constrained delegation
if ($spns) {
$delegationType = "Constrained"
$allowedToDelegateTo = $spns -join ","
} else {
$delegationType = "Unconstrained"
$allowedToDelegateTo = $null
}
# Add the computer details to the results array
$results += New-Object PSObject -Property @{
ComputerName = $_.Name
DelegationType = $delegationType
AllowedToDelegateTo = $allowedToDelegateTo
ObjectClass = $_.ObjectClass
LastLogonDate = $_.LastLogonDate
SID = $_.SID
DistinguishedName = $_.DistinguishedName
ObjectGUID = $_.ObjectGUID
Name = $_.Name
SamAccountName = $_.SamAccountName
DNSHostName = $_.DNSHostName
UserPrincipalName = $_.UserPrincipalName
}
}
}
}
$attachment = "C:\temp\AD_Delegations_$(Get-Date -Format yyyy-MM-dd).csv"
# Write the results to a CSV file
$results | Select-Object ComputerName, DelegationType, AllowedToDelegateTo, ObjectClass, LastLogonDate, SID, DistinguishedName, ObjectGUID, Name, SamAccountName, DNSHostName, Description, UserPrincipalName | Export-Csv $attachment -NoTypeInformationConclusion
In Active Directory, it is crucial to understand the potential security risks associated with unconstrained delegation and to take appropriate measures to mitigate these risks. One way to do this is by implementing constrained delegation where it is feasible, as this provides a higher level of security than unconstrained delegation. It is recommended to perform a thorough audit of hosts that have this setting enabled, as this will help identify any additional areas for potential abuse in the Active Directory environment.