Category Archives: AD FS

Using Pinpoint DNS to route AD FS authentication traffic

In this post, we’ll look at pinpoint zones in DNS and how they can be used to route AD FS traffic more favorably for authentication.

In larger AD FS setups with thousands of users,  enterprises may be using a global farm spanning multiple regions. In the absence of global site load balancing, pinning users to a particular region for authentication is not trivial, and begs the question: How do I respond with different IP addresses from a single hostname?

Let’s look at a hypothetical AD FS scenario using Azure VMs. Our farm is located in Azure region US East and two AD FS farm nodes are configured behind an Azure internal load balanced virtual IP of  172.20.15.5.  On the Internet facing side, we have a pair of Web Application Proxies (WAP) connected to an Azure Internet load balancer (these are not germane to this discussion).

An ExpressRoute connects the corporate New York headquarters of the organization to the Azure network in the US, and a similar connection links up Europe via their London office. An (A) record in DNS adfs.mydomain.com points to the IP address of the Azure load balancer.

Users in Europe, however, are reporting that AD FS logon times are poor when connected to the company network. To improve response time and overall performance, an additional farm in the Azure region UK South is deemed necessary.

From an AD FS perspective, the challenge at this point is how to route internal logon traffic to the new farm.  Remember that the federation service URL in internal DNS currently points to the US East VIP of the Azure load balancer.

The trick is using a pinpoint DNS zone. We create a primary zone in DNS representing the URL of the federation service. By making it a primary zone we are allowing control over which domain controllers the zone is created on and whether it is replicated  (Active Directory Integrated). By localizing it to domain controllers of our choice, say Europe, we can then create an A record in DNS that points to the Europe Azure internal load balancer VIP (172.20.75.5).

Let’s see how that works. On a European domain controller, we create a new primary forward lookup zone (adfs.mydomain.com)

Once that’s done, we create an (A) record in DNS in the adfs.mydomain.com zone. Leave the name blank.

Those clients using this domain controller as their DNS server will now resolve the name to the European load balancer.

On each domain controller where we wish connecting clients to use the European AD FS farm, we repeat this process. Other domain controllers that are using the Active Directory Integrated (ADI) replicated version of this record will continue to resolve to the US East Azure internal load balancer.

Blogging @ Route443

While I continue to post identity and access-related material here, a note to let you know that you can also find posts from myself and other colleagues on a blog over at Route443. This is a new organization recently co-founded and setup to aid and assist companies make better use of nascent technologies, such as cloud, for business advantage. You can find more about the company here.

Here’s a quick summary of what’s been posted so far on the blog.

My colleague, Edwin, set the ball rolling back in March with a post about Azure Identity Protection. He followed this up quickly with a nice piece on the Evolution of Access Control. In April, came a post about Azure AD as an Identity Provider from yours truly. Then last week, another colleague (Dennis) pipped everyone to the post by writing an excellent walk-thru of the new SAML Authentication capability found in the next (7.9) release of Citrix XenDesktop and XenApp. A highly recommended read and a world “first”.

In the coming weeks, we’ll be taking Azure AD out for a test drive…

See you there, oh … and here 🙂

Damian / “Mylo”