Geo redundant ADFS for O365

  • Last Post 26 May 2016
Anthony.Vandenbossche posted this 23 May 2016

Hi All,   I am looking into the scenario below for a customer, concerning ADFS on Azure in combination with Traffic Manager.   In every Azure region that the customer is active (Europe, Asia, America) we deploy an ADFS server for (on Azure). This is done with separate vNets connected through VPN, making replication between ADFS farm nodes possible, WID seems to be the best option as a database backed (as SQL would require Mirroring – and separate ADFS farms - , which I am not sure can manage 3 nodes). In this scenario there is 1 ADFS Farm for containing 3 servers, in 3 different Azure Regions. On top of this setup we want to use Azure Traffic Manager for Geo-Loadbalancing (DNS), where the LB type would be shortest path (sending people from the Europe Region, to the Europe ADFS Server).   Aidan Finn ( worked out something like the image below. Note that this setup lacks Geo Loadbalancing to mitigate the need of DNS changes.  

Is this a feasible scenario?    


Mvg,   Anthony Van den bossche
System Engineer

Order By: Standard | Newest | Votes
joe posted this 23 May 2016

This is the type of thing I've spent a lot of time on with our platform here although there are a few differences: - Not cloud hosted yet (although once you get your VPC/networking stuff done there, is probably isn't really different). We'll likely shift some of the hosting to the cloud  - Use SQL as backend because WID won't scale to our load and this is definitely the hard part! - Use AWS Route53 for traffic management rather than Azure traffic manager but that should be very similar - Only use a "hot failover" model as we need full capacity in both nodes in case of a full outage (HA more important than balancing) and also because both of our deployments are in the US and we don't actually see much measured performance improvement for the end users with geo-balancing with the amount of network traffic that ADFS typically has for the browser
So, the bottom line is that you should be able to make something like this work. You may need to be careful with how you implement the DNS stuff because you run some risk of breaking Kerberos authentication from the browser with some patterns. If you want to do SQL, you can as well but it will be much more complex. We use Always On for HA in our ADFS environment but found that we struggled to make the multi-subnet model for SQL Always On really reliable in our network so we moved to a model of separate clusters and a "DR" approach where we use replication to copy data to the backup node. Ours is also set up so that the secondary data center will use SQL from the primary data center if it is available so that way if R53 fails over to the secondary node due to a front end failure but the backend is still up, the secondary front end servers can still talk to the original SQL backend.
if WID works for you, you probably will have this part much easier.
Do you have specific questions?
Joe K.


Anthony.Vandenbossche posted this 24 May 2016

Hi Joe,


Thanks for the prompt reply! The questions I have are mostly concerning the Azure Traffic Manager part. Will it be able to Load Balance Internal and External traffic? Will

the Load Balancing method – Performance – work as expected etc.


Performance: Select Performance when you have endpoints

in different geographic locations and you want requesting clients to use the "closest" endpoint in terms of the lowest latency. For more information, see Performance

traffic routing method


ADFS questions were indeed if an Active Active setup is feasible. The solution you suggest is in effect a DR solution, which is fine as well. However

our client wishes to have Load Balancing and thus active services in all regions. I got the GO from the client to setup a POC, so I will reply on this thread as soon as possible. We will try to use WID indeed, so replication can occur over VPN’s between Azure

vNets. I think that in your setup, you can also have an Active Active setup (DR is not the only option), where you have separate ADFS farms under the same banner, using their own SQL install (with Transactional Replication between them)?




Anthony Van den bossche

System Engineer



+32 (0)2 801 54 59


+32 (0)476 83 80 23

Description: Description: C:\Users\BJTAF40\AppData\Roaming\Microsoft\Signatures\realdolmen_logo.gif

This e-mail message and any attachment are intended for the sole use of the recipient(s) named above and may contain information which

is confidential and/or protected by intellectual property rights. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s)

is prohibited. If you have received this e-mail in error, please notify the sender either by telephone (+32 2 801 55 55) or by e-mail and delete the material from any computer. Please note that neither RealDolmen nor the sender accept any responsibility for

viruses and it is your responsibility to scan or otherwise check this email and any attachments. RealDolmen is nor responsible for the correct and complete transfer of the contents of the sent e-mail, neither for the receipt on due time.



joe posted this 24 May 2016

I think the question on load balancing both internal and external traffic depends primarily on what type of client behavior you want and whether you want all clients to hit the external facing IP addresses (presumably through the ADFS proxy) or if you want internal traffic to bypass the proxy. I can imagine that you might be able to trick this into working by having your internal DNS point to an alternate host name in Traffic Manager configuration that resolves internal IP addresses rather than external ones. However, it might be difficult to integrate a health check feature against the internal IPs. I can say for certain that I've not tried this particular configuration with Route 53 and have no experience at all with Traffic Manager. I know Route 53 allows you to use IP addresses that don't belong to AWS although they charge a little more for this.In our setup we treat all traffic as "external" as we do not wish to treat clients on the internal network differently than the external network but that's likely an unusual policy decision for many orgs. :)
Our solution is indeed heavily focused on DR but you are correct that we can run Active/Active with ours if we want. In our topology, the traffic in the secondary data center would hit SQL in the primary data center via WAN connectivity in our normal run scenario. There are a few reasons we don't do this but they might not apply to you: 
We wish to have full peak capacity in both data centers in case of a full failure of one data center or even a need to take down a data center for maintenanceSince both nodes are in the US, the clients don't get a whole lot of performance benefit due to improved latency and bandwidth when using one node or the otherSince the secondary data center ADFS farm hits the primary DC SQL farm in the normal run mode and this goes of the WAN, those transactions are always a bit slower than connections in the primary data center. Since there isn't much benefit on the other side of the network equation for the client, it doesn't make sense to force some clients to get a naturally slower login experience on the backend side. 
I hope this helps more!
Joe K.


Parzival posted this 26 May 2016


I actually wrote a small architecture article on ADFS on Azure (or any cloud).. 

feedback always welcome :)


ADFS on Azure « Studio Graphic Blog

Azure Active Directory and thus any relying party on that service (such as Office 365) has two different modes for (your) custom domains that are added to it.