Benefits of load balancing Microsoft ADFS
Load balancing Microsoft ADFS provides High Availability (HA), scalability, and improved performance:
- High Availability (HA): Load balancing ensures that the ADFS service remains continuously available even if one or more servers fail.
- Failure Detection and Failover: The load balancer constantly monitors the health of each ADFS server. If a server becomes unresponsive (e.g., due to hardware failure, operating system crash, or ADFS service stoppage), the load balancer automatically stops sending traffic to the unhealthy server and redirects all new requests to the remaining healthy servers. This mechanism provides fault tolerance, preventing a single point of failure and ensuring uninterrupted access to applications for users.
- Scalability: Load balancing allows ADFS infrastructure to meet growing service demand without service disruption. As the number of users or federated applications grows, the load on the ADFS servers increases. A load balancer distributes incoming authentication requests across all servers in the farm, preventing any single server from becoming overloaded. New ADFS or Web Application Proxy (WAP) servers can be added to the farm and integrated into the load balancer pool with minimal to no downtime. This allows the infrastructure to scale horizontally as the organization expands.
- Improved performance: Optimizing the distribution of work, load balancing ensures a better and more consistent user experience. Load balancing algorithms (like “Least Connections” or “Round Robin”) distribute client traffic efficiently among the servers, leading to balanced resource use (CPU, memory) across the farm. Preventing individual servers from being overwhelmed results in faster response times for authentication requests and a significant reduction in overall service latency for users performing single sign-on.
About Microsoft ADFS (Active Directory Federation Services)
Microsoft ADFS (Active Directory Federation Services) provides secure SSO (Single Sign-On) and identity federation within an ADFS deployed environment. In its simplest form, it can be used to provide authentication against Active Directory for claims-aware applications such as Office 365, Outlook on the web, or Sharepoint to name but a few Web SSO.
Using standards-based identity federation allows trust relationships between federated third parties such as partner organisations or applications hosted within cloud environments. Whenever authentication is required across organisational boundaries (between otherwise autonomous security domains) a federation trust can be created Federated Web SSO.
Microsoft’s Enterprise solutions are at the heart of businesses everywhere. Loadbalancer.org is officially certified for all of Microsoft’s key applications which you can find here. More details on the Microsoft ADFS components, how it works, and prerequisites for load balancing can be found in our deployment guide, available to view below.
Why Loadbalancer.org for Microsoft ADFS?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance Microsoft ADFS
The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For Microsoft ADFS, Layer 7 Reverse Proxy is recommended. This mode offers high performance and is simple to configure since it requires no mode-specific configuration changes to the load balanced ADFS Servers.
Layer 4 DR mode, NAT mode and SNAT mode can also be used if preferred. For DR mode you’ll need to solve the ARP problem on each ADFS server. For NAT mode the default gateway of the ADFS servers must be the load balancer.
Port requirements
The following table shows the Ports that are load balanced:
| Ref. | Protocols | Use |
|---|---|---|
| 443 | TCP/HTTPS | ADFS communications |
| 49443 | TCP | Used for certificate authentication in ADFS v3.0 and later |
Load balancing deployment concept
You can deploy Federation Servers within your LAN or leverage the ADFS Proxy role within your DMZ allowing secure deployment alongside your applications. A load balancer can be deployed in front of either Federation Server or Federation Server Proxies providing both scalability and high availability to ADFS deployments.
Protocols
| Protocol | Role | Ports | Load balancing methods |
|---|---|---|---|
| TCP/HTTPS | WEB SSO | 443 | Layer 7 TCP Mode |
About Layer 7 Reverse Proxy
Layer 7 Reverse Proxy uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods.
Layer 7 is typically chosen when enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.
Because Layer 7 Reverse Proxy is a full proxy, any server in the cluster can be on any accessible subnet, including across the Internet or WAN.
Layer 7 Reverse Proxy is not transparent by default i.e. the Real Servers will not see the source IP address of the client, they will see the load balancer’s own IP address by default, or any other local appliance IP address if preferred (e.g. the VIP address). This can be configured per Layer 7 VIP.
If required, the load balancer can be configured to provide the actual client IP address to the Real Servers in two ways:
- Either by inserting a header that contains the client’s source IP address, or
- By modifying the Source Address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client.
Layer 7 Reverse Proxy mode can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth0 is normally used for the internal network and eth1 is used for the external network, although this is not mandatory.
No mode-specific configuration changes to the load balanced Real Servers are required.
Port translation is possible with Layer 7 Reverse Proxy e.g. VIP:80 → RIP:8080 is supported. You should not use the same RIP:PORT combination for Layer 7 Reverse Proxy VIPs and Layer 4 SNAT mode VIPs because the required firewall rules conflict.
