Find and Block Unconstrained Delegation in Active Directory

Kerberos unconstrained delegation was introduced in Windows Server 2000. It was designed to let webservers, receiving authentication requests from users, to impersonate those accounts when updating records on backend database servers. Another way to think of unconstrained delegation is as a mechanism where a user sends its credentials to a service and then the service accesses resources on the user’s behalf. When services impersonate user accounts in this way, it is sometimes known as performing a ‘double-hop’.

Unconstrained delegation is enabled by Domain Admins, and users that have the SeEnableDelegationPrivilege right, by checking ‘Trust this computer for delegation to any service (Kerberos only)’ on the Delegation tab of computer accounts in the Active Directory Users and Computers (ADUC) management console.

User accounts, managed service accounts (MSA), and group managed service accounts (gMSA) can also be configured for unconstrained delegation. But the Delegation tab in ADUC is not exposed by default for these object types. User accounts must be assigned a Service Principal Name (SPN) before the Delegation tab appears in the ADUC Properties dialog. Advanced Features must also be checked in the View menu. Delegation attributes for MSAs and gMSAs must be set manually in the Attribute Editor tab in the Properties dialog.

Users with the SeEnableDelegationPrivilege NT right, which is displayed as ‘Enable computer and user accounts to be trusted for delegation’ in security policy, also need write access to account objects to update their msDS-AllowedToDelegateTo, userAccountControl, and/or servicePrincipalName attribute values.

Other types of delegation in Active Directory

Service accounts enabled for unconstrained delegation pose a major security risk because it is possible to collect Kerberos Ticket Granting Tickets (TGT) from users connecting to those computers. Once a hacker has a user’s TGT, it can be used to log in to other systems. Tools like Mimikatz can extract TGTs from memory on systems where unconstrained delegation is enabled if Mimikatz is running with local administrator privileges.

Constrained delegation

Constrained delegation, if delegation must be used, is a much safer alternative as it restricts delegation to specific services. Constrained delegation is configured by selecting ‘Trust this user for delegation to specified services only’ on the Delegation tab in the ADUC Properties dialog and then selecting one or more services.

Resource-based constrained delegation

A third type of delegation, called resource-based constrained delegation (RBCD), is configured using PowerShell. RBCD lets the administrator owning the resource being accessed control delegation. Unlike the other types of delegation, RBCD relies on attributes set on the resource service, opposed to the service that is trusted for delegation.

While RBCD is the most secure type of delegation, it can still be used by hackers to move laterally across a network and elevate privileges if AD security best practices are not followed in your environment. For more information on RBCD, check out Microsoft’s website.

Delegation across Active Directory forest trusts

Services accounts enabled for unconstrained delegation use impersonation to authenticate against any other service in the same AD forest. After applying the July 9^th 2019 update for Windows Server, unconstrained delegation is disabled by default across new and existing forest trusts. Changes to the default delegation behavior across forest trusts arrived in a series of updates in 2019.

You can get more information about the updates and how they change default trust delegation settings on Microsoft’s website here.

Find unconstrained delegation in Active Directory

On the same support page, Microsoft has a PowerShell script (Get-RiskyServiceAccountsByTrust.ps1) that you can use to find service accounts and forest trusts configured for unconstrained delegation.

Preventing unconstrained delegation attacks

Using the Get-RiskyServiceAccountsByTrust.ps1 script provided by Microsoft is one way to shine a light on service accounts configured for unconstrained delegation. Furthermore, following a few other security best practices can also help prevent risky configurations in AD:

1. On the Account tab in an account’s Properties dialog in ADUC, check ‘Account is sensitive and connect be delegated’ for accounts with privileged access to AD.
2. If it doesn’t create compatibility issues, add accounts with privileged access in AD to the Protected Users Members of this group cannot be used for constrained or unconstrained delegation. For more information about the Protected Users group, see this article on Petri.
3. Make sure that you restrict who can manage sensitive AD objects. Be careful who can change object attribute values, modify group membership, and reset account passwords.
4. Don’t use privileged AD accounts to manage AD from devices that aren’t specifically secured for that purpose.

 

5. Delegate privileges so that IT staff can perform everyday AD management tasks without needing privileged access to AD.
6. Remove local administrator rights wherever possible on end-user devices.
7. Use Windows Defender Credential Guard to protect domain accounts.