Thank-you for your work on a fantastic AD security auditing tool.
The T-TGTDelegation test added in the v2.7.0.0 release for checking TGT delegation across forest trusts uses test logic which is naive, resulting in false positives in common configurations. This isn't altogether surprising, as the changes that Microsoft has implemented to address the underlying issue are poorly documented, and some official management tools even give incorrect or misleading output.
This is going to be a long post to explain the relevant background to ultimately arrive at the suggested test change and mitigation guidance. Bear with me!
Relevant TDO trust attributes
The trust flags of interest stored in the trustAttributes attribute of TDO objects are:
0x200
: CROSS_ORGANIZATION_NO_TGT_DELEGATION
0x800
: CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION
The 0x200
flag and associated feature (Enforcement for Forest Boundary for Kerberos Full Delegation) was introduced in Windows Server 2012 but backported to Windows Server 2008 and 2008 R2 as part of the March 2019 security updates.
The 0x800
flag does not appear to be documented publicly, including in Microsoft's Open Specifications documentation for the trustAttributes attribute. I believe it was added by the May 2019 security updates to all supported Windows Server releases but haven't confirmed this. Of note, this means no current Windows Server release has awareness of this flag without applying the relevant security updates.
TGT delegation across forest trusts behaviour
This is where it gets complicated as the behaviour is dictated not just by the configured trustAttributes flags but also the security updates installed on the DC responding to a cross-forest request.
Prior to March 2019 security updates
TGT delegation across forest trusts is allowed by default. It can be disabled on Windows Server 2012 or newer by setting the CROSS_ORGANIZATION_NO_TGT_DELEGATION
flag (a non-default configuration).
After March 2019 security updates
As above, but can now be disabled on Windows Server 2008 and 2008 R2.
After May 2019 security updates
Newly created forest trusts default to disabling TGT delegation. However, this does not mean the CROSS_ORGANIZATION_NO_TGT_DELEGATION
flag is set in the TDO's trustAttributes. I'm guessing some other attribute of the TDO is used to determine if the new default behaviour should be used. Perhaps by checking the whenCreated
attribute?
After July 2019 security updates
All forest trusts default to disabling TGT delegation. This effectively means that unless the CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION
flag has been set in the TDO's trustAttributes then TGT delegation across the trust will be blocked.
Suggested detection approach
The current approach is checking that the CROSS_ORGANIZATION_NO_TGT_DELEGATION
flag is set for each TDO object in the target domain, but as the above shows, this isn't entirely accurate.
I'd suggest the following approach to more accurately communicate the current configuration:
- If the
CROSS_ORGANIZATION_NO_TGT_DELEGATION
flag is set on the TDO the issue is effectively mitigated, provided all DCs are running Windows Server 2012 or newer. If Windows Server 2008 or 2008 R2 DCs are present they must have the March 2019 security updates.
- If the
CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION
flag is set on the TDO the domain is vulnerable. DCs with the relevant updates to understand this flag will allow TGT delegation while DCs which don't will use the previous default behaviour of allowing it anyway.
- If neither flag is set, which I'd expect to be the default on the vast majority of domains, the domain's vulnerability comes down to whether the latest security updates are installed on all DCs (and the DCs are running supported Windows Server releases). This is a "maybe" state, in that if you have good security patching processes you're fine, but if you have any DCs which are not updated with at least the May 2019 security updates you're in trouble.
Changing the relevant TDO trust attributes
This is where it gets outright silly and needlessly confusing.
netdom
Assume a TDO without either of the referenced flags set. If you check the TGT delegation status on a patched system you'll see something like this:
netdom trust trusting_domain /domain:trusted_domain /EnableTgtDelegation
TGT Delegation is enabled.
OK, that's actually wrong, but let's try disabling it anyway:
netdom trust trusting_domain /domain:trusted_domain /EnableTgtDelegation:No
TGT delegation is already disabled.
So in contrast to Microsoft's own documentation, the only way to explicitly set the CROSS_ORGANIZATION_NO_TGT_DELEGATION
flag via netdom
is to temporarily enable TGT delegation and then immediately disable it. This will set the flag as you'd expect on the TDO.
PowerShell
There's no Set-ADTrust
cmdlet but you can enumerate the configuration of existing trusts:
Get-ADTrust -Identity domain.com | select -Property TGTDelegation
Name TGTDelegation
---- -------------
domain.name True
But we just disabled TGT delegation? Turns out, the underlying cmdlet is checking for the CROSS_ORGANIZATION_NO_TGT_DELEGATION
flag not realising it's an "inverted" flag. If it's set, the TGTDelegation property gets set to True.
Further, the ActiveDirectory module has no awareness of the new CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION
, and so will incorrectly report TGT delegation is not enabled when it is.
Post the July 2019 security updates, if either of the TGT behaviour flags are set on an enumerated TDO, the ActiveDirectory module will tell you the exact opposite of the actual configuration. Prior to the July 2019 security updates it would always be wrong, so I guess this is an improvement overall.
ADSI
The only reliable and secure way to be sure the ideal fix (setting the CROSS_ORGANIZATION_NO_TGT_DELEGATION
flag on each TDO) is implemented is to do so by directly checking the trustAttributes value using ADSI or similar. Ideally it could also be set if needed via ADSI, but I was unable to do so with the directory server always rejecting the update. Maybe updates to TDO settings must be performed via the LSA interface which netdom
uses?
Suggested mitigation advice
The advice should be updated to note the bugs in netdom
. The only reliable way to set the CROSS_ORGANIZATION_NO_TGT_DELEGATION
flag on TDOs which I've found is by toggling TGT delegation on and off with netdom
. Inspecting the current value of trustAttributes for a given TDO will determine if toggling the TGT delegation setting with netdom
is necessary.