Changes to Ticket-Granting Ticket (TGT) Delegation Across Trusts in Windows Server (AskPFEPlat edition)

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 fabrikam.com domain.

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 fabrikam.com /domain:contoso.com /EnableTGTDelegation:No

• This flag should be set in the trusted domain (such as contoso.com) for each trusting domain (such as fabrikam.com). After the flag is set, the trusted domain will no longer allow TGTs to be delegated to the trusting domatin.
• 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.
  • IMPORTANT – A known issue with this update has been discovered in relation to intra-domain scenarios and Windows Server 2008/2008R2. Authentication requests for accounts configured for unconstrained Kerberos delegation will incorrectly fail in intra-domain scenarios after the Kerberos ticket expires due to an issue that occurs after the March 2019 updates.The following updates are affected by this issue:
    • Windows Server 2008 SP2
      • March 12, 2019 — KB4489880 (Monthly Rollup)
      • March 12, 2019 — KB4489876 (Security-only update)
      • March 19, 2019 — KB4489887 (Preview of Monthly Rollup)
    • Windows Server 2008 R2
      • March 12, 2019 — KB4489878 (Monthly Rollup)
      • March 12, 2019 — KB4489885 (Security-only update)
      • March 19, 2019 — KB4489892 (Preview of Monthly Rollup)

  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 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 domain 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 fabrikam.com /domain:contoso.com 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.

Important Resources and Links

• KB4490425 – Updates to TGT delegation across incoming trusts in Windows Server
• ADV190006 – Guidance to mitigate unconstrained delegation vulnerabilities
• Kerberos Constrained Delegation Overview
• Get rid of accounts that use Kerberos Unconstrained Delegation
• Understanding Kerberos Delegation in Windows Server Active Directory
• Hunting in Active Directory: Unconstrained Delegation & Forests Trusts

Acknowledgements

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