So we’ve seen how a trust is setup, and how we can manipulate the domain controllers involved, can we do the same for authentication traffic? The answer would be yes, but why is it a yes, and how is the main question.
While many believe WINS or LMHOSTS can help us on external (non-forest) trusts, we dive into a packet capture that has captured the opening of a fileshare on a remote forest.
For this demo, I have installed a resource server in the forestroot domain, and a RIVER client on the OCEANFLOOR domain.
So I was wondering the following, how do all the domain controllers know that the trust is established, since (see previous post) we cannot accurately say which domain controller is being used..
When we have the same problem with user passwords, the PDC gives the vote whether the password (just changed) for the user is valid. The same seems to apply for Trusts. When running a trace while creating the trust on a “regular” domain controller and not the PDC, we can find out how that is accomplished. For this, I have installed a domain controller called MICHDC01 which is on the (newly created) LAKES site.
In part of the the forest authentication blog post, we’ve seen that a particular path is used depending on Kerberos or NTLM authentication. We’ve also seen that domain controllers rely on other domain controllers of the forest to find the right domain (and thus object in the AD). The question now is, which domain controller of the other forest is used to authenticate the user? What happens during a trust creation, do we really need the PDC emulator? Will LMHOSTS still help us, like it did in the old days?
Those questions we will answer in this series of authentication across trusts part 2, 3 etc..