Have you ever counted how many times you type in your password to authenticate yourself? Whether it is in the morning to log in to your account and start working or when you have to authenticate yourself with a third-party provider (Azure, SharePoint, ServiceNow)? Luckily, we can use Microsoft Windows Server Active Directory Federation Services (ADFS) to reduce the number of times we have to authenticate ourselves.
ADFS are a well-known role of Windows Server systems. It has been used by IT Administrators in many enterprises to leverage secure logon internally and externally. The setup of ADFS is a straightforward process. The different components (the ADFS role and the Web Application Proxy (WAP) role) are available as a role and a feature in the server management wizard. In order to comply with high availability requirements, you need to set up a minimum of 2 instances for each component.
When setting up the environment on premise, we have to factor in all the required basic resources: computer, memory, network and storage. Next to this, we need to make sure that the ADFS environment remains reachable at all times. In other words, you’ll need two geographically dispersed data centers in case of a natural disaster. This requirement is obviously very expensive and also difficult to attain. Not all companies have indeed multiple data centers in different regions.
As a Managed Services Provider, ASP has the necessary infrastructure to support an ADFS environment which remains reachable at all times. However, while adopting a “Cloud-First” strategy, we want to leverage the agility, scalability and cost-efficiency of cloud data centers the same way our customers do. In order to have a fully redundant ADFS infrastructure that remains available at all times, we decided to do a Cloud-Based approach to our ADFS infrastructure and to deploy the infrastructure in Azure.
Our cloud based ADFS setup consists of two parts. In the first part, two replica domain controllers in an Availability Set* in a production subnet. The second part consists of two WAP servers in an Availability Set in a DMZ subnet. Both Availability Sets have a load balancer in front of them to distribute the load. The Availability Set has the default fault and upgrade domains to ensure availability.
*An Availability Set is a logical grouping of Virtual Machine’s with the same functionality. By grouping them, the Azure platform distributes the placement of those Virtual Machine’s across the underlying infrastructure. Should there be a planned maintenance event to the Azure platform or an underlying hardware/infrastructure fault, the use of Availability Sets ensures that at least one Virtual Machine remains running.
Fault and upgrade domains are part of the Availability Set. This means that each Availability Set has a fault domain and an upgrade domain. In the Azure platform a rack of computers is identified as a fault domain. By using multiple fault domains, you spread the Virtual Machine’s over multiple racks, thus reducing the risk of service interruption due to hardware or infrastructure fault. By default there are 3 fault domains.
An upgrade domain is a logical unit of a deployment (in our case the ADFS deployment). When an upgrade is performed on a deployment it is carried out against one upgrade domain at a time. The steps are stopping the instance(s) in the first upgrade domain, upgrade, bring the instances back online followed by repeating the process for the other upgrade domains. By default there are 5 upgrade domains.
Built like this, the ADFS infrastructure is available both internally and externally. Internally via an internal IP and externally via a DNS name.
Below is a high level design of the setup:
As indicated above, we have an Expressroute connection between our on-premise datacenter and the Azure Cloud, resulting in a hybrid datacenter. This ensures us a high speed, secure and private connection for traffic between on-premise and the cloud, not only for us but also our customers who use Azure.
For more info on our Expressroute, please check our blogpost here.
By deploying it to the Azure Cloud, we have the possibility to spread the placement of the Virtual Machine’s over several regions, including one in the Netherlands (Western Europe) plus one in Ireland (Northern Europe), eliminating the risks of regional disasters.
In short, using a cloud-first approach has provided us with a setup that is always available, easy to set up and deploy and cost efficient.
For more information you can contact us.