Skip to content

AD-DEL-002: Constrained delegation with protocol transition

medium   Delegation   MITRE ATT&CK T1558, T1134   Reads: LDAP

Enabled accounts use constrained delegation with protocol transition, so they can impersonate any user to their delegation targets without that user's credentials.

Also known as: protocol-transition

Why it matters

Trust this user/computer for delegation to specified services only, Use any authentication protocol sets TRUSTED_TO_AUTH_FOR_DELEGATION. The account can then ask the KDC for a service ticket to itself on behalf of any user (S4U2Self), and because of this flag that ticket is forwardable, so it can trade it for a ticket to every SPN in its msDS-AllowedToDelegateTo list (S4U2Proxy).

Whoever controls the account (its password, its key, or SYSTEM on the computer) therefore becomes any user they choose on the target services, domain admins included, unless the user is marked sensitive and cannot be delegated or is in Protected Users. The service part of the ticket is not protected either: a ticket for cifs/fs01 can be rewritten to host/fs01 or http/fs01 on the same host, so the whole target host is exposed, not only the listed service.

How ad-doctor detects it

From the LDAP snapshot: every enabled account with the TRUSTED_TO_AUTH_FOR_DELEGATION bit (0x1000000) in userAccountControl. Each object names the account and the SPNs it may delegate to, from msDS-AllowedToDelegateTo:

svc_iis -> cifs/fs01.adlab.test

When the flag is set but the list is empty, the target shows as ?.

Attributes and probes read
  • userAccountControl
  • msDS-AllowedToDelegateTo

Severity

Always medium. The reach is limited to the SPNs in msDS-AllowedToDelegateTo; when those include a domain controller service or krbtgt, AD-DEL-004 reports the same account as high.

False positives and limits

  • Designed protocol transition. Web front ends that authenticate users with forms, certificates or NTLM and then reach a back end as the user legitimately need it. Keep the target list as short as possible, treat the account as being as sensitive as its targets, and record the decision in an accepted-risk file.

Fix

  1. List the accounts and their targets (read-only):

    Get-ADObject -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=16777216)' `
    -Properties sAMAccountName, 'msDS-AllowedToDelegateTo' |
    Select-Object sAMAccountName,
        @{n = 'Targets'; e = { $_.'msDS-AllowedToDelegateTo' -join ', ' }}

  2. Use Kerberos-only constrained delegation where clients already authenticate with Kerberos. This removes protocol transition and keeps the target list:

    Set-ADAccountControl svc_iis -TrustedToAuthForDelegation $false -WhatIf

  3. Trim msDS-AllowedToDelegateTo to the SPNs the service actually uses.

  4. Protect privileged accounts from impersonation: Account is sensitive and cannot be delegated (AD-PRIV-002) or Protected Users (AD-PRIV-010).

  5. Protect the delegating account like its targets: a gMSA or a long random password, and no interactive logons.

Verify

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-DEL-002

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-DEL-002"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

References

Microsoft and vendors

Specifications

Research

MITRE ATT&CK

Available since 0.1.0.