In the previous F5 posts we did, we always used a single forest, single domain setup. Obviously, this is not always the case, certainly when cross-forest migrations are being performed. Even in these situations we could leverage F5 and AAD’s federation capabilities to provide an SSO experience. Requirements: 2 Forests with a forest trust (two-way) […]
So, I got a question the other day on using ADFS in combination with some 3rd party applications in a very large AD environment. Basically the problem statement was: “ we don’t want to use UPN and we don’t want to use domain\username. Users should be able to login using either (only) their employeeID or […]
When creating a forest trust, each domain within the trusted forest becomes trusted. While this is sometimes not desired it is possible to limit the scope by implementing selective-authentication. It is possible to only allow authentication between those domains you want by granting the allowed to authenticate right to only those domains objects.
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..
Anyone installed a forest trust before.. probably else you would not be reading this post.. how does authentication work in a forest trust?
Well there are two authentication mechanisms in Windows NTLM and Kerberos, both can be used in a forest trust, and both work differently. Setting it up brought me the following authentication schema..
So the problem:
All mailboxes of the users are migrated to a central Exchange server, comming from various Exchange 5.5/2003/2003 mailservers (contact me if you want to know how 🙂 ) . and mailboxes where cloned.. now the client needs to be pointed to the new exchange server else Outlook will not work. The challenge, how do you change your mapi profile.
We had 4 scenario’s
1: The domain is NT4 no trust or no domain at all!
2: The domain the user is in, has a trust with the Exchange domain
3 The domain the user is in is a Windows 2000/2003/2008 domain no trust
4: The user is in the domain