ADFS in multi forest environments is still a very hot topic based on my day to day experience. Even if I’m concentrating more on cloud application development projects for more than 8 months, I still get a lot of questions from partners, colleagues, customers, IT admins from all around the world regarding this specific scenario. To put this in a little bit more perspective, the questions are usually asked in the context of Azure Active Directory, so the already renowned federated identity scenario. So that’s why I decided to blog about it, hoping to complement the scarce existing documentation.
Before we get started I would like to clarify one thing. Even if I will reference a lot Azure AD, everything I describe here is not restricted to Azure AD as a relying party. In fact, last time I worked on such a scenario, the relying party was AWS. So let’s get started.
The basic scenario is the following: a company has two or more Active Directory forest and one Azure AD. Using Azure AD Connect we can synchronize several forests to the same Azure AD. The question arises on the ADFS design. How many ADFS farms would we need? How would this work? Is this supported?
To start with the last question: yes, this is supported and you can use only one ADFS farm. However, in order for this to work, there are some conditions that need to be met.
- We need a two way trust between the forest where we’ll deploy ADFS and all the other forests.
- We need to make sure that the UPN suffixes in each forest match the registered domain in Azure AD.
- We need to pay attention to the ADFS requirements.
Yes, it is that simple. If these 3 conditions are met, there is no further “specific” configuration that we would need to perform to make this work. The authentication flow is also the usual one. When a request for authentication comes in to Azure AD, it will detect that the user is federated based on the UPN suffix, hence Azure AD will redirect the request to ADFS. During the next step, ADFS will try to validate the user identity with a domain controller in the forest where it is installed. If ADFS doesn’t find a maching user, it will try to contact a domain controller in all the forests that have a two way trust relationship until it finds the user. When the user is found, ADFS goes on and creates the SAML token containing the needed information and so on.
Based on experience, there are a lot of cases where this doesn’t work immediately after the deployment. Also based on my experience, in most of the cases there is a networking issue if this flow breaks at a certain point. ADFS uses the LDAP protocol to communicate with domain controllers and certainly we have to make sure that this communication is not blocked by firewalls or other network devices. So if you encounter problems, first thing to do is to perform a test authentication and take Http and Network traces and to check exactly where the communication is blocked. Most of the times, when the network problem is resolved, everything will work perfectly.
So that’s it! I tried to keep it short and simple, since this is really not complicated at all, even if it looks frightening at first due to the several components of this specific architecture. When we speak about Azure AD we can complicate this scenario a bit, by having several forests and several Azure ADs at the same time, but in the end this is also possible with one ADFS deployment. But I will dig into this in another article.
Cheers.
How useful was this post?
Click on a star to rate it!
Average rating / 5. Vote count:
Dan Patrascu-Baba
Latest posts by Dan Patrascu-Baba (see all)
- Configuration and environments in ASP.NET Core - 25/11/2019
- GraphQL in the .NET ecosystem - 19/11/2019
- A common use case of delegating handlers in ASP.NET API - 12/11/2019
How does ADFS determine what domain controller it will use in a forest (that it’s not installed in)? A problem we are having is that we have acquired a new company that has overlapping IP subnets so we have had to restrict traffic to specific domain controllers in order to create the forest trust. We have a stubzone from the other company – some of the domain controllers in that stubzone aren’t reachable. I’m having issues with ADFS erroring out with a user doesn’t exist type error. so…what determines which dc is used and is there a way to limit which dc’s adfs tries to contact?
First I have to say that it’s more than one year that I am not working with ADFS anymore so I might have forgotten some things and I am surely not up to date with new ADFS features in Windows Server 2016. However, here are my 2 cents based on my previous experience:
1. Usually ADFS connects to the a DC in the same site where the ADFS server is located. Theoretically in this case ADFS communicates only with that specific DC and doesn’t need to communicate with other DCs.
2. If there is a two way trust, the DC in the site were also ADFS is placed should handle authentication of remote users.
3. Additionally there are some things that can be done at network level. For instance, when ADFS tries to connect to a DC it could hit something like a load balancer. Where that traffic should go, can be defined at load balancer leverl. I think similar things are possible via DNS settings, but that’s not really my strong point.
4. Another idea would be to define in the host file on the ADFS server what DC should be used.
Hope you find something helpful here.
Awesome article, short, crisp and simple. appreciate it.