Security Focus: Report on Constrained Delegation


It's a subject that's been written about on numerous occasions. However, there's not much out there on how to understand the extent of constrained delegation in a domain. What is constrained delegation then?

Here's something from a pervious occasion:

"…The feature that allows an application to act on behalf of a user is known as Kerberos Delegation. It has to be explicitly enabled for trusted services on a trusted computer. It can be switched on for a service account running the service or for the computer's Local System account (all services running as Local System). It can be unconstrained, i.e. the application can impersonate the user anywhere else within the forest or across a trust, or it can be constrained, i.e. the application can only impersonate the user to a specific service on a specific computer.

If a trusted computer is compromised, the trusted application could act on behalf of any user that has presented itself to the service to perform malicious activity…"

 


If you have to use Kerberos Delegation, then constrained delegation is the way to go. Delegation is considered to be constrained because the identity (service account / computer account) that is used to request the service ticket must be configured to access a specific service.

That's the context. Now to use PowerShell to understand where you have constrained delegation configured in a domain.

$Findings = Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo

if ($Findings) {

$Findings | Export-Clixml -Path .\ALLOWED_TO_DELEGATE_TO.xml

}

 

I'm exporting to XML so I can view any objects that have multiple entries in the msDS-AllowedToDelegateTo property.

 

And… the great thing about exporting to XML is that you can re-import the contents as identical objects (minus the methods).

 

Comments (0)

Skip to main content