As outlined in the MS Technet article, the “Kerberos Authentication Process Over Forest Trusts” works as follows:
1.User1 logs on to Workstation1 using credentials from […] [childx.rootx.tld]. The user then attempts to access a shared resource on FileServer1 located in the […] [childy.rooty.tld]forest.
2.Workstation1 contacts the Kerberos Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 SPN.
3.ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the […] [rootx.tld] forest contain this SPN. Because a global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match.
[Important: The needed information regarding name suffixes is stored in the “msDS-TrustForestTrustInfo” attribute of the corresponding TDO. The TDO is stored in Active Directory in the “System” container.
This attribute is only maintained in cases of a forest trust. When the TDO represents an external trust, this attribute is empty and contains no information. As a result, Kerberos authentication fails at this point when executed over an external trust.
To examine the information of the “msDS-TrustForestTrustInfo” attribute, the following command can be used:
netdom trust childx.rootx.tld /domain:childy.rooty.tld /NAMESUFFIXES:childx.rootx.tld
In the case of a external Trust, this command will return no information, but instead the message: “The trust is not a forest trust”.]
Once a match is found, the global catalog provides a routing hint back to ChildDC1. Routing hints help direct authentication requests toward the destination forest, and are only used when all traditional authentication channels (local domain controller and then global catalog) fail to locate a SPN.
4.ChildDC1 sends a referral for its parent domain back to Workstation1.
5.Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of the […] [rooty.tld] forest.
6.Workstation1 contacts ForestRootDC2 in the […] [rooty.tld] forest for a service ticket to the requested service.
7.ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.
8.ForestRootDC2 then sends the referral to usa.corp.wingtiptoys.com back to Workstation1.
9.Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.
10.Once Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads User1’s security credentials and constructs an access token accordingly.
To make Kerberos working over an external Trust, the missing information of the TDO objects “msDS-TrustForestTrustInfo” attribute must be provided manually to the KDC configuration, which can be done using the following GPO settings:
Computer Configuration\Policies\Administrative Templates\System\Kerberos\[KDC]:
Use forest search order
By configuring this setting, a list of forests to be searched can be added using the the FQDNs of the corresponding forrest.
Note: This procedure applies only to a Windows Server 2008/R2 environment.
Additional Reading and References
Please see also the MS post “Conditions for Kerberos to be used over an External Trust” and the post “Kerberos Authentication Over An External Trust – Is It Possible? (Part 6)“.
For testing the authentication method used when accessing a web page, the tool „DelegConfig“ can help.