Changes to Ticket-Granting Ticket (TGT) Delegation Across Trusts in Windows Server (CIS edition)
Published Apr 11 2019 12:18 PM 16.9K Views


UPDATE (2/3/2021): KB4519979 changed the output behavior so that it now appears as one would expect it to appear. The wording in this content has been updated to reflect the fact that the netdom and PS/get-adtrust commands will now return true when delegation is enabled, and false when delegation is disabled.


Hello Everyone! Allen Sudbring here, Premier Field Engineer at Microsoft. Today I'm putting a post out to get some critical information to everyone who supports Windows Server and Active Directory Domain Services.

If you haven’t seen the KB article that this post references I encourage you to check out its content, I promise it’s important!

KB4490425 - Updates to TGT delegation across incoming trusts in Windows Server


With the introduction of Windows Server 2012, a new feature was added to Active Directory Domain Services that enforced the forest boundary for Kerberos unconstrained delegation. This allowed an administrator of a trusted forest to configure whether TGTs can be delegated to a service in the trusting forest. Unfortunately, an unsafe, default configuration exists within this feature when creating an inbound trust that could allow an attacker in the trusting forest to request the delegation of a TGT for an identity from the trusted forest.


So what does this all mean?


Let's back up a little bit and do a brief explanation on Kerberos delegation.

There are three kinds of Kerberos delegation in Active Directory:

  • Unconstrained
    When a Domain Administrator configures a service’s account to be trusted for unconstrained delegation, that service has the ability to impersonate any user account to any other service. This is the most insecure delegation option, because a service could impersonate any user to any other service it likes. For a regular user account, not so bad, but for a Domain Admin or an Enterprise Admin, a rogue service could request information from the domain or change user account or group permissions in the name of the privileged account. For this reason, unconstrained Kerberos delegation is a high security risk.

  • Constrained
    First introduced with Windows Server 2003, constrained delegation allows an administrator to limit the services to which an impersonated account can connect to. Constrained delegation is difficult to configure and requires unique SPN's to be registered as well as Domain Admin rights to implement. Constrained delegation cannot cross domain or forest boundaries.

  • Resource-based Constrained
    First introduced with Windows Server 2012, Resource-based constrained delegation improved on the constrained delegation introduced with Windows Server 2003. It eliminated the need for SPNs by switching to security descriptors. This removed the need for Domain Admin rights to implement and allowed server administrators of backend services to control which service principals can request Kerberos tickets for another user. Resource based allows delegation across domain and forest boundaries.

For more information on Kerberos delegation, refer to this documentation:

Kerberos Constrained Delegation Overview


All currently supported versions of Windows Server that are utilized for Active Directory Domain controllers have this vulnerability:

  • Windows Server 2008

  • Windows Server 2008 R2

  • Windows Server 2012

  • Windows Server 2012 R2

  • Windows Server 2016

  • Windows Server 2019


Let’s say you are responsible for the Contoso forest and you have a partner who owns the Fabrikam forest whose resources your users use. How could an attacker in Fabrikam take advantage of this vulnerability?


First, they need to have the ability to configure a service they own to be trusted for unconstrained delegation. By default, this requires domain administrator privilege in the forest.

Next, they need to get your user to authenticate their rogue service in your partner’s Fabrikam forest.

Now they have your user’s TGT which they can use to authenticate to any service as that user.


Technical Overview of the Vulnerability

As a consequence of this vulnerability an attacker who has control of a forest with an inbound trust to another forest can request a TGT for a user in the trusted forest by enabling unconstrained delegation on a service principal in the trusting forest. The attacker would need to convince the user to authenticate to the resource in the trusting forest thereby allowing the attacker to request a delegated TGT.

To mitigate this vulnerability, a netdom command can be executed that will disable TGT delegation.

EnableTGTDelegation flag is enabled on Windows Server 2008 and Windows Server 2008 R2 devices after installing the March 12, 2019 updates. Windows Server 2012 and higher, the EnableTGTDelegation flag is in the operating system out of the box.

TGT delegation across an incoming trust can be disabled by setting the EnableTGTDelegation flag to No on the trust using netdom.



netdom.exe trust / /EnableTGTDelegation:No



  • This flag should be set in the trusted forest root domain (such as for each trusting forest (such as After the flag is set, the trusted forest will no longer allow TGTs to be delegated to the trusting forest.

  • The secure state is No.

  • Any application or service that relies on unconstrained delegation across forests will fail.

Starting with the March 2019 security updates, this ability was backported to Windows Server 2008 and 2008 R2. Below is the following timeline that Microsoft has announced to address this vulnerability:

  • March 12, 2019
    Ability to disable TGT delegation added to Windows Server 2008 and 2008 R2.

    The following workaround guidance is recommended if the update has been installed:


  • May 14, 2019
    An update will be released that will change the default behavior of EnableTGTDelegation to add a safe default configuration. If delegation is required across trusts, this flag should be set to Yes before the July 2019 updates are installed. After this update, any newly created trusts will have the new default of EnableTGTDelegation trust flag set to No.

  • July 9, 2019
    An update will be released that will force the trust flag on existing trusts and disable TGT delegation by default. Any trust that has been configured to continue using delegation after May 14, 2019 will not be affected.

The July 2019 update cycle is the one that could cause issues in an existing environment. After those month's updates are installed, any existing forest trusts will have TGT delegation disabled by default. This could cause applications and services to fail that require unconstrained delegation across a trust. Because of the possibility of this issue affecting customers, it is recommended that you start evaluating applications and accounts that might be affected by this change as soon as possible.


To help determine if any applications or accounts are using the unsafe delegation, use the following resources:

  • PowerShell

    • A quick command can be run against a trust from PowerShell that will determine if the flag is set on an inbound trust. Run this command from the forest that has the inbound trust:

      Get-ADTrust -Filter {Direction -eq "Inbound"} | ft Name,TGTDelegation

After installation of KB4519979, the value returned from the above command is:

FALSE - A return of false means that the delegation is disabled and is in the safe state.

TRUE - A return of true indicates that the delegation is enabled and is in the unsafe state.


Prior to the installation of KB4519979, the value returned from the above command is counterintuitive and is backwards from what you might expect:

FALSE - A return of false means that the delegation is enabled and is in the unsafe state.

TRUE - A return of true indicates that the delegation is disabled and is in the safe state.


    • A script has been created that can scan forests that have incoming trusts that allow TGT delegation.

    • Refer to this support article for the PowerShell code:
      KB4490425 - Updates to TGT delegation across incoming trusts in Windows Server

    • Copy and Paste the code from the support article into a file named Get-RiskyServiceAccountsByTrust.ps1

    • There are two options switches that the script can be executed with:

      • -Collect will output any principals that have unconstrained delegation.

        Get-RiskyServiceAccountByTrust.ps1 -Collect
      • -Collect -Scanall will output security principals that have unconstrained delegation and search across trusts that do not allow TGT delegation

        Get-RiskyServiceAccountByTrust.ps1 -Collect -ScanAll

      Example of Output:

  • Event Viewer/Event Logs

    • In an Active Directory domain when a Kerberos ticket is issued, the domain controller logs security events. These events contain information about the target domain and can be utilized to determine whether unconstrained delegation is being used across incoming trusts.

      • Check for events that contain a TargetDomainName value that matches the trusted forest name.

      • Check for events that contain a TicketOptions value that contains the ok_as_delegate flag (0x00040000)


Next Steps

  • Update any Windows Server 2008 or 2008 R2 domain controllers with the March 2019 security updates as soon as possible. View known issues above before proceeding.

  • Determine the applications and accounts that could be affected now, and if there aren't any, and a trust is in place, disable the delegation as soon as possible to be in a safe configuration.

    netdom.exe trust / /EnableTGTDelegation:No
  • Applications that rely on unconstrained delegation should be configured to use resource-constrained delegation. See Kerberos Constrained Delegation Overview for more information.

  • Once you have set the applications to resource-based constrained delegation, set the flag to No.

  • If it's determined that applications or accounts do exist that require this delegation in the environment, then set the flag to Yes, BEFORE the July 2019 updates. This is not recommended and should be avoided.




I would like to thank the following people for helping pull this post together and provide content:

  • Alan La Pietra - Microsoft

  • David Loder - Microsoft

  • Steve Syfuhs - Microsoft

  • Brandon Wilson – Microsoft

  • Michiko Short - Microsoft

  • Paul Miller - Microsoft

Version history
Last update:
‎Feb 03 2021 12:38 PM
Updated by: