Allowed To Delegate


The Source security principal is allowed to perform Kerberos Constrained Delegation (KCD) with protocol transition on the Target computer. This means that it can impersonate any user when it authenticates with Kerberos to any service running on the Target computer.

Therefore, it often leads to a total compromise of the Target computer.


Attackers who compromise the Source security principal can use dedicated hacker tools such as Rubeus to exploit legitimate Kerberos protocol extensions (S4U2self and S4U2proxy) in order to forge Kerberos service tickets and impersonate the targeted user. Attackers are likely to choose to impersonate a privileged user to obtain privileged access.

Once attackers forge the service ticket, they can use any native administration tool or specialized hacker tool compatible with Kerberos to execute remotely arbitrary commands.

A successful exploitation attempt must meet the following constraints:

  • The Source security principal must be enabled for protocol transition (ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION in UserAccountControl / "Use any authentication protocol" in the Delegation GUI). More precisely, the attack could work without protocol transition ("Use Kerberos only" in the Delegation GUI), but attackers must first coerce a Kerberos authentication from the targeted user to the Source security principal, which makes the attack harder. Therefore, Tenable Identity Exposure does not create an attack relation in this case.

  • The Source and Target security principals must have a ServicePrincipalName. Tenable Identity Exposure does not create this attack relation without this condition.

  • The account targeted for spoofing must neither be marked "is sensitive and cannot be delegated" (ADS_UF_NOT_DELEGATED in UserAccountControl) nor be a member of the "Protected Users" group because Active Directory protects such accounts from delegation attacks

On the contrary, the Target computer where delegation is allowed is designated by a Service Principal Name (SPN) and thus contains a specific service such as SMB with "cifs/", HTTP with "http/", etc. However, attackers can actually target any other SPN and service running under the same Target account using a "sname substitution attack". Therefore, this is not a limitation.


If the Source security principal does not need permission to perform Kerberos Constrained Delegation (KCD) on the Target computer, then you must remove it. You must make the modification on the Source side, as opposed to an "Allowed to act" delegation attack relation.

To remove the Source security principal:

  1. In "Active Directory Users and Computers" administration GUI, go to the Source object's Properties > Delegation tab.

  2. Remove the Service Principal Name corresponding to the Target.

  1. If you do not want any delegation from this Source, remove all SPNs and select "Do not trust this computer for delegation".

Alternatively, you can use PowerShell to modify the content of the Source's "msDS-AllowedToDelegateTo" attribute.

  • For example, in Powershell, run this command to replace all values:

Set-ADObject -Identity "CN=Source,OU=corp,DC=example,DC=net" -Replace @{ "msDS-AllowedToDelegateTo" = @("cifs/") }
  • If you do not want any delegation from this Source, run the following command to clear the attribute:

Set-ADObject -Identity "CN=Source,OU=corp,DC=example,DC=net" -Clear "msDS-AllowedToDelegateTo"

It is also possible to reduce the risk while not completely closing this attack path by disabling protocol transition. This requires that all security principals connect to the Source using only Kerberos instead of NTLM.

To disable protocol transition:

  1. In "Active Directory Users and Computers" administration GUI, go to the Source object's Properties > Delegation tab.

  2. Select "Use Kerberos only" instead of "Use any authentication protocol".

Alternatively, you can run the following command in PowerShell to disable protocol transition:

Set-ADAccountControl -Identity "CN=Source,OU=corp,DC=example,DC=net" -TrustedToAuthForDelegation $false

Finally, as a general recommendation, in order to limit the exposure of sensitive privileged accounts to such delegation attacks, Tenable Identity Exposure recommends that you mark them as "Is sensitive and cannot be delegated" (ADS_UF_NOT_DELEGATED) or add them to the "Protected Users" group after careful verification of the associated operational impacts.

See also