Microsoft is planning to introduce a security update in July 2019 that will alter the way Kerberos delegation across forest trusts work. If ignored, this update could negatively impact applications that rely on unconstrained delegation across a forest trust.
There is a security concern in the default configuration for forest trusts that has caused Microsoft to announce this change. By default, an attacker who gains control of an application in a trusting forest could impersonate user accounts to access other services if the application uses unconstrained Kerberos delegation. Unconstrained Kerberos delegation is already considered a high security risk, but it is necessary for some applications to function. If an attacker in a trusting forest gains Domain Admin rights, it would be possible for them to configure a rogue application to use unconstrained delegation, convince users in the trusted forest to use that application, and then use the user's Kerberos ticket to access other services as that user.
Starting in Windows Server 2012, there is a new option to disable unconstrained Kerberos delegation across a forest trust - EnableTGTDelegation. Setting this to NO mitigates the above security concern by blocking Kerberos delegation across an incoming forest trust. However, the option is set to YES by default which is insecure because the delegation is allowed.
For example, let's pretend you control the Contoso forest and have an incoming (or bi-directional) trust with the Fabrikam forest. Your users access applications in the Fabrikam forest using this trust. If an attacker in the Fabrikam forest gets control of an application that uses unconstrained delegation and can convince your Contoso users to access that application, the attacker would gain a TGT (ticket-granting ticket) which allows them to authenticate to any service as the users who accessed the attacker's original application. The TGT is a sort of master-key that allows authentication via Kerberos to any service for the user that the TGT is created for. However if EnableTGTDelegation is set to no, the delegation and TGT are blocked which mitigates the security issue.
As a result of the above vulnerability, Microsoft is releasing 3 updates between now and July 2019 to enhance security. Those changes are:
- March 2019 - Patches released for Server 2008 and Server 2008 R2 backport the EnableTGTDelegation option to block unconstrained Kerberos delegation on an incoming trust. There are no changes to default functionality in these patches - they simply enable the EnableTGTDelegation option on the older OSes.
- May 2019 - Updates to Server 2008 and later will set EnableTGTDelegation to NO for new trusts making them secure by not allowing unconstrained Kerberos delegation across the trusts. Existing trusts will be unaffected.
- July 2019 - Updates to Server 2008 and later will enforce the secure configuration by disallowing unconstrained Kerberos delegation across existing trusts. If unconstrained delegation is required, the setting can be overridden to avoid causing issues in applications. If the setting is not overridden, applications that use unconstrained delegation may experience issues
The July 2019 updates will change the behavior by setting the default value of EnableTGTDelegation to NO which disallows unconstrained delegation across the trust. If any cross-forest applications rely on unconstrained delegation, they will stop functioning unless action is taken. Here are the recommended steps to help avoid unexpected issues:
- Determine if any applications rely on unconstrained delegation. There is a PowerShell script on the related KB article that can help with this. That article also contains a way to review security event logs for potential usage of unconstrained delegation.
- Reconfigure any required applications to use the more secure resource-based delegation.
- If the applications cannot be reconfigured prior to July 2019, temporarily set the EnableTGTDelegation flag on the trust to YES to continue allowing the insecure method after the July updates are applied.
- This is only recommended as a stop-gap while the affected applications are re-configured. This is an insecure solution that bypasses the new security measures.
- Once all the applications have been configured to not rely on unconstrained delegation, set the EnableTGTDelegation flag to NO on the trust.