When setting up an Active Directory forest trust for a client, I ran into a couple interesting questions. Happily I was able to address them by replicating the conditions in a lab, so for those of you that don’t have the luxury or the time I’m going to document them here. The first has to do with replacing an external trust with a forest trust and what the impact will be. The second has to do with implementing Selective Authentication and the administrative impact of that decision.
The two organizations, let’s call them Contoso and TailSpin, already had a two-way external trust configured between the forest root of TailSpin and a child domain of Contoso. What they wanted to do was create a two-way forest trust between Contoso and TailSpin. But what about users that were already using the external trust? Would they continue to follow that trust path, or would they move onto the forest trust path. My initial reaction was that they would continue to use the external trust in the same way that two child domains in the same forest can use a shortcut trust to avoid walking the referral ladder up and down the forest. Rather than go with my gut feeling, I instead set up the environment in a lab, and I was glad I did. It was a simple setup with three domain controllers and two client PCs. I set up the initial external trust between my mock TailSpin forest root domain and a mock Contoso child domain. Using the client PCs I verified that the trust was working and using packet captures that the authentication referral went like this:
TailSpin Client -> TailSpin DC -> Consto child DC -> resource on Contoso client
That’s exactly what I would expect. Note that each arrow is actually a referral back to the TailSpin client on where they should go next.
After testing that, I created my forest trust and ran the same test with packet captures. The referral now went like this:
TailSpin Client -> TailSpin DC -> Consto root DC -> Contoso child DC -> resource on Contoso client
My conclusion… the forest trust supersedes the external trust. If you ever wanted some really exciting reading, you could check out this TechNet page that breaks down the authentication referral process. As far as I can tell, when the local DC cannot find a SPN that matches the resource request it checks its trust list for a namespace match. It should find both the external and forest trust in there, but I am guessing that the forest trust wins in precedence. In effect the external trust is now not doing anything, and it can be removed safely.
Stay tuned for part 2 of this post where I get into the world of Selective Authentication!
Update: My coworker Mike Serrano just happened to run into the same issues I did with Selective Authentication in the same span of time. Rather than rehash his findings, you can read his post about it here.
Director, Cloud Solutions and Microsoft MVP: Cloud (Azure/Azure Stack) & DC Mgmt