Doing Active Directory Migrations is always tricky, certainly on applications. I’ve recently came across an application that performs an (uche 200x) based simple-LDAP bind to validate credentials. Now, we could rewrite the entire application to use SAML, OpenIDConect, Kerberos, Headers or whatever. But that’s not always possible. But how do we manage applications that do […]
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..