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.
How useful was this post?
Click on a star to rate it!
Average rating / 5. Vote count:
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