Configuring Geo-Redundancy for AD FS on-premises with Azure Traffic Manager

Reading Time: 8 minutes

Hybrid Identity

Last week, I showed you how to perform a simple Hybrid Identity implementation with AD FS on-premises. While this scenario is easy and fast to deploy, it also has a couple of downsides. One of them is the risk of ‘AD FS Unavailability’ and the inability to authenticate to cloud resources when the on-premises environment is unreachable from the Internet.

My weapon of choice to mitigate that risk is Azure Traffic Manager.

In this blog post I share how I see Azure Traffic Manager play its role in making Active Directory Federation Services (AD FS) on Windows Server 2016 and Windows Server version 1709 highly available through geo-redundancy and, thus, failing over between multiple locations if need be.


Introduction to Azure Traffic Manager

Traffic Manager LogoAzure Traffic Manager is a Azure-based user traffic load-balancing solution. It can direct user traffic between and/or to IP-addresses associated with endpoints for Azure Virtual Machines, Azure (cloud and app) services, and on-premises networks.

Traffic Manager uses the Domain Name System (DNS) to direct client requests to the most appropriate endpoint in its configuration, based on the traffic-routing method of your choice and the health of the endpoints. It provides automatic failover.

The four ways Azure Traffic Manager helps AD FS

Azure Traffic Manager is capable of helping make Active Directory Federation Services (AD FS) on multiple locations highly available in all of its four routing methods. Let’s look at these methods using real-life examples:

  1. Failover / Priority
    Your organization has deployed AD FS in both Azure IaaS and on-premises. Traffic Manager allows you to direct user authentication traffic from Internet-based clients to your organizations’ Azure Infrastructure-as-a-Service-based AD FS implementation, only if the on-premises AD FS implementation fails or becomes unreachable from the Internet.
  2. Performance
    Your organization has multiple offices worldwide with corresponding datacenters. Traffic Manager can direct user authentication traffic from Internet-based clients to endpoints in different geographic locations. Azure Traffic Manager directs them to the "closest" endpoint in terms of the lowest network latency.
  3. Geographic
    Your organization has deployed AD FS in multiple Azure regions. Like the ‘Performance’ method, Traffic Manager can direct user authentication traffic from Internet-based clients to endpoints in different geographic locations. This time it’s not based on the lowest latency, but the actual geographic location.
  4. Weighted / Round-Robin
    You have multiple AD FS deployments, but they vary in compute power and bandwidth. Traffic Manager can distribute user authentication traffic from Internet-based based to any combination of Azure and non-Azure endpoints using weights your organization defines. You could use this method to direct 20% of the traffic to the on-premises AD FS implementation on your first datacenter, 20% to your other datacenter and the rest of the traffic to your organizations Azure Infrastructure-as-a-Service-based AD FS implementation.

While all four traffic manager methods have their pros and cons, my customers mainly prefer the Priority method. They chose to implement AD FS initially, because they need to be in reach of the auditing data to prove they are in control of the authentication mechanisms. The choice for on-premises AD FS comes from the wish to take advantage of the x-ms-client-ip, insidecorporatenetwork claimtypes and/or automatic Workplace and/or Azure AD Join, based on domain membership.

However, recently, I configured the Performance routing method for a customer, so we’ll use it for this example, because it’s way more exiting. Here’s an overview


Before you begin


Building on top of the simple Hybrid Identity implementation where I showed you how to implement AD FS, the end result of this blogpost looks like this:

The georedundant AD FS deployment scenario using Azure Traffic Manager (click for larger image)


Microsoft’s Hybrid Identity Required Ports and Protocols document doesn’t list the requirement to allow TCP 80 (HTTP) for Web Application Proxies.

In addition to the network traffic depicted in that document, we need to take care of  the ability of our Web Application Proxies to communicate plain HTTP towards the Internet (or at least the Azure Traffic Manager probing IP address ranges).

Name resolution

Normally, we’d point DNS to the external IP address of the load balancer on the edge of the perimeter network featuring the Web Application Proxies. However, since Azure Traffic Manager leverages DNS, we’ll need to create a CNAME record for our sts.domain.tld AD FS Farm name in external DNS Zones towards Azure Traffic Manager. For instance, we’ll create a CNAME record for sts.domain.tld to

Next, we’ll need to configure proper name resolution. Azure Traffic Manager uses DNS records to locate the endpoints, so the external IP addresses for the Web Application Proxies you’d want to integrate with Azure Traffic Manager will need to have a fully-qualified Domain name (FQDN) attached.

My suggestion is to use the same naming convention used for the AD FS farm name, but add a location or region to it. This way, an sts.domain.tld farm name would feature EastUsSTS.domain.tld and WestEuropeSTS.domain.tld endpoints, for example.


Step 1: Configuring the second AD FS server

In contrast to the simple deployment scenario, we’ll deploy more than one Active Directory Federation Services (AD FS) server. We don’t have to worry about the scope of the group Managed Service Account (gMSA), because the AD FS server takes care of that.

Deploy a new server running Windows Server 2016 or Windows Server 1709, join it to the Active Directory domain as adfs2.domain.tld and import the AD FS service communications certificate.

Then, run the following PowerShell one-liners:

Install-WindowsFeature ADFS-Federation

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match "sts.domain.tld"}).Thumbprint

Add-AdfsFarmNode -CertificateThumbprint $thumb -PrimaryComputerName adfs1.domain.tld -GroupServiceAccountIdentifier domain.tld\ADFSgMSA$



Step 2: Configuring the second Web App Proxy

Configuring additional Web Application Proxies to an AD FS Farm is not different than adding the first.

In the scenario of multiple datacenters, however, you might want to pay specific detail to the contents of the HOSTS file on the Web Application Proxies to point them to the closest AD FS server, instead of the AD FS server in the other datacenter.

The following PowerShell one-liner provides a good way to add a line to the HOSTS file using an elevated PowerShell (ISE) session:

Add-Content "C:\windows\system32\drivers\etc\hosts" "`nsts.domain.tld"

Then, import the certificate and run the PowerShell one-liner to add the Web Application Proxy to the AD FS farm:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match "sts.domain.tld"}).Thumbprint

Install-WebApplicationProxy -CertificateThumbprint $thumbFederationServiceName sts.domain.tld

Enter the credentials of a local administrator account on the AD FS Server at the login screen and then, the Web Application Proxy is setup.


Step 3: Configuring both Web App Proxies

For optimum load-balancing, we’ll need proper probes. We need to probe the infrastructure for something that is available only when the infrastructure is up and the functionality (the service) is running properly. A mere ping won’t suffice.

While you’d need to install KB2975719 on Windows Server 2012 R2 to enable the /adfs/probe endpoint, in Active Directory Federation Services (AD FS) on Windows Server 2016, this endpoint is available and enabled, by default.

You won’t see the /adfs/probe/ endpoint in the list of endpoints in AD FS Management (.msc), under Service, Endpoints.

However, the /adfs/probe/ endpoint is not available by default on Web Application Proxies, so we’ll need to perform a manual action to allow it through its Windows Firewall.

To this purpose, create the following Windows Firewall rule using Windows PowerShell on each of the Web Application Proxy servers you want to be probable by Azure Traffic Manager. Log onto each Web Application Proxy with an account with local admin privileges, start an elevated PowerShell (ISE) window and issue the following lines of code:

Import-Module NetSecurity

New-NetFirewallRule -Name Allow_HTTP -DisplayName "AD FS HTTP Services" -Protocol TCP -LocalPort 80 -Profile Any -Action Allow

You should be aware that this rule allows Azure Traffic Manager to probe the status of each of the Web Application Proxies, and, thus, the availability of the connection and running services on these servers, but not the AD FS services on the AD FS Servers. For the purpose of geo-redundancy, however, this should be sufficient.


Step 4: Adding DNS records

Internal DNS

When you want your AD FS farm name to be available for users on-premises, add another DNS A record for the second AD FS server in the internal DNS zone:

Add-DNSServerResourceRecordA -IPv4Adddress -Name sts -ZoneName domain.tld

Since we’re creating A records, Active Directory site awareness takes care of pointing internal clients to the nearest AD FS server.

External DNS

For the external DNS zone, we’ll need the following DNS changes:

sts.domain.tld CNAME

EastUsSTS.domain.tld A <ExternalIPAddressinDatacenter1>

WestEuropeSTS.domain.tld A <ExternalIPAddressinDatacenter2>


Step 5: Configuring Azure Traffic Manager

Now, all we need to do is configure Azure Traffic Manager, itself:

  • Log onto the Microsoft Azure Portal.
  • If you have multiple tenants, choose the right tenant by clicking on your name or e-mail address in the top right corner. Select the tenant you want to use from the bottom of the context menu.
  • Click on the green big plus sign in the left navigation menu to add products and services to your tenant.
  • In the Search the Marketplace field, search for Traffic Manager Profile. by beginning to type its name. When Azure suggests it to you, click on it, or use the down cursor to go to it and then press Enter.
  • A new blade appears named Traffic Manager Profile. It contains information on what Traffic Manager does, information on its publisher and help links. Click on the Create button on the bottom of the blade.
  • A new blade appears, labeled Create Traffic Manager profile.

Create a Traffic Manager Profile in the Azure Portal (click for original screenshot)

  • Type and select the following information:
    • Type the DNS name of your Traffic Manager profile, for instance DomainSTS. This will be appended by to become the FQDN your external DNS zone has a CNAME for:
    • Select a Routing method from the drop-down list. We’ll choose Performance.
    • Select a Subscription from the drop-down list.
    • Create a new Azure Resource Manager (ARM) Resource group, or if you already have a resource group for Traffic Manager profiles and other load-balancing/high-availability resource, reuse that, by selecting it from the drop-down list.
    • Select a Resource group location from the drop-down list, when you create a new Resource group, otherwise continue with the next step.
  • Select the Pin to dashboard option for your convenience.
  • Click Create on the bottom of the blade.
  • You will be redirected back to the Azure Portal dashboard, where you’ll see the profile be provisioned. After that, you’ll be taken into the configuration of your freshly created Azure Traffic Manager profile. If not, click it’s tile on the dashboard to continue.
  • In the left navigation blade, click on Configuration under SETTINGS.
  • In the Configuration blade that appears, click on the Path field under Endpoint monitor settings. Change it to /adfs/probe/.

Configure Traffic Manager Endpoint Monitoring in the Azure Portal (click for original screenshot)

  • Click Save on the top of the blade.
  • In the left navigation blade, click on Endpoints.
  • Follow the + Add link on the top of the blade.
  • A new blade appears, labeled Add endpoint.

Add a Traffic Manager Endpoint in the Azure Portal (click for original screenshot)

  • From the Type drop-down list, select External endpoint.
  • Type something meaningful as the name. This makes for a good opportunity to exercise the organization’s naming convention. You might also just opt to type the hostname of the Web Application Proxies.
  • For the Fully-qualified Domain Name (FQDN) enter the DNS name you assigned to the external IP address of the load balancer of Web Application Proxy in the particular location.
  • Select a Location from the drop-down list. This determines the end-user device locations to be directed to this particular endpoint.
  • Click OK.

Now, add any additional endpoints you’d like to include in the Azure Traffic Manager profile, like EastUsSTS.domain.tld. After that, your Endpoints overview should look like this:

Traffic Manager Endpoints in the Azure Portal (click for original screenshot)



Azure Traffic Manager is a cost-effective, relatively easy to set up, robust service in Microsoft’s Azure datacenters to add geo-redundancy to your Active Directory Federation Services (AD FS) implementations.

Further reading

Azure Traffic Manager & ADFS 2012r2
Configure the Web Application Proxy Infrastructure
How to install and configure Web Application Proxy for ADFS
Web Application Proxy Server in 2012 R2
Overview of Traffic Manager

19 Responses to Configuring Geo-Redundancy for AD FS on-premises with Azure Traffic Manager



    Thanks for sharing this article.

    we are considering azure for having high availability in our adfs environment.

    We have recently had downtime in our environment due to network failure. I was wondering if by hosting the primary adfs & wap servers and a DC on azure which connects to our on premise seconday adfs & wap servers via Azure Traffic manager can help resolve the network downtime issue and maintain availability of the ADFS service.

    What do you advise?

    Thanks & Best Regards,


    Step 3:
    Shouldn't the Powershell to add firewall rule be:

    New-NetFirewallRule -Name Allow_HTTP -DisplayName “AD FS HTTP Services” -Protocol TCP -LocalPort 80 -Direction Inbound -Profile Any -Action Allow

    • Hi Russel,

      The New-NetFirewallRule has knowledge of protocols beyond TCP, UDP and ICMP. You can use it to specify well-known protocols like HTTP, HTTPS and SMTP. That way, you don't have to specify it uses port 80. For more smart examples, see the Microsoft documentation on New-NetFirewallRule.


    Sander, for the ADFS servers are you using WID? If so, do you know if this is officially supported by Microsoft? I'm willing to live with the fact the WID database on failover is going to be read only until primary ADFS comes online and forego on SQL geo-clusters.

    • Hi,

      Yes, WID is supported.
      SQL replication is used by AD FS in this scenario.


    So what do you mean by "SQL replication is used by ADFS in this scenario?" Your setup is an extension of your WIDS setup from "the simple Hybrid Identity implementation" is it not? There does not appear to be any SQL involved.

    • Windows Internal Database (WID) is a variant of SQL Server Express 2005–2014 that is included with Windows Server.
      As per the 6th remark on this Microsoft blogpost, WID uses SQL Replication between AD FS Servers.


    That's what I thought you meant, just wanted to clarify. Thanks for your feedback, excellent article.


    As mentioned correctly above, the standard configuration of the WAP probe in Azure TrafficManager only tests the availability of the WAP server, not the AD FS backend.

    I came up with a workaround for this, using an alternative port on the WAP and then forwarding this to the backend probe.
    I described it hereherehere. I've tested it thoroughly and it works well, providing failover both when the WAP or the AD FS backend fails.


    I decided to write the above mentioned workaround in a blog post as I see a lot of people struggling with this:
    Hope you find it useful.


    Hi Sander, great article, thx for sharing.
    As you mention yourself, the WAP probe only informs Traffic Manager of WAP issues, but says nothing about the ADFS backend.
    There's a neat little workaround for this:


    Thanks for your sharing. It’s only for one ADFS farm on different location? Can I put different ADFS farm on different location?

    • Hi Kevin,

      You can setup a different AD FS Farm in another location using the steps outlined in performing a simple Hybrid Identity implementation with AD FS on-premises. However, one big difference between setting up a separate AD FS farm is that the new farm won't be able to participate in handling the relying party trusts (RPTs) for the existing farm. (It needs a different URL and RPTs can only be configured with one URL.)



    Where do you create your diagrams? In visio? where did you get the icon or stencil sets for your diagrams? Are they custom? Your diagrams are really well done.

    • Thank yuou,

      I make my diagrams in PowerPoint, mostly.
      This way, I can reuse the drawings in presentations, with animations.

      The shapes are custom shapes, indeed.


    When it comes to internal DNS routing, is there a way to make sure internal users go to the closest ADFS server? It seems like it would be bad to direct outside traffic to the closest server but then use RR and send internal users to the farthest server.

    • Hi Scott.

      Certainly, but you need Active Directory sites for this and you need to run DNS on Active Directory Domain Controllers.
      In this setup, when you create A (and AAAA) records for your AD FS farm name and point to AD FS servers that are in different AD sites, the device will be directed to the AD FS server in its own AD site, because the IP address will be returned as the first IP address from the DNS server.


    Does this work if the farm uses an external sql server and not WID? Can't find out if I can have different ssl certs for the farm adfs nodes. Or can the WAP servers have different ssl certs instead?

    • Hi Eric,

      You cannot build this using a full-fledged SQL Server for storing the AD FS Configuration and AD FS Artifact Store, unless your active/active SQL Cluster can offer read/write access to the databases from all SQL Server nodes.
      With Windows Internal Database (WID), only the primary AD FS server makes changes and these changes are replicated to all the other WID instances on all AD FS servers.

      All AD FS servers and Web Application Proxy servers need to use the same service communications certificate.
      Web Application Proxy servers can have additional certificates. This is useful when publishing applications.


leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.