Category Archives: ADFS

Using Pinpoint DNS to route AD FS authentication traffic

AD FS, ADFS, Azure, DNS, IaaS, , , , , ,

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.

AD FS – Old Habits (idpinitiatedsignon.aspx)

AD FS 2.0, AD FS 2016, AD FS 3.0, AD FS R2, AD FS VNext, ADFS, Windows Server 2012 R2, Windows Server 2016, , , , , , ,

Usually after building an AD FS/WAP farm I test locally from the Internet and the Intranet using (to-date) a fairly reliable source of verification that the service is up and running. I’m referring to, of course, the IdP sign-in page (../adfs/ls/idpinitiatedsignon.aspx). This offers a simple way of validating login via AD FS.

With Windows Server 2016, this page is no longer surfaced “out-of-the-box”.. if you want to do a SAML 2.0  IdP-initiated sign-on, this functionality will need to be enabled. Otherwise, connecting to the obligatory sign-in page, will produce an error similar to the following:

2016-06-10_18-06-00

Testing from the Web Application Proxy itself directly,  pointing to the AD FS farm, we may see an HTTP 503 Service Not Available error.

Via Powershell, it can be switched back on:

set-adfsproperties -EnableIdpInitiatedSignon $True

Now, before we get too hasty,  knowing that we can turn it back on versus actually turning it back on are two different things 🙂 If it’s directly required, IdP-driven sign-on is a feature of your federation setup, then you may have no choice. For example, certain SaaS/Cloud applications simply don’t support SP-initiated workflow.

For some organizations I’ve worked for though, this page is seen as insidious because it reveals the relying parties configured on your AD FS farm anonymously.

AD FS 2.0

2016-06-16_18-57-06

AD FS 2012 R2

2016-06-16_18-58-34

Going back to AD FS 2.0, customers are often unwilling to float this data anonymously via the sign-in page and want to hide the RP enabled trusts visible on the page, sometimes re-writing the code behind to do so or even hiding it from the browser via obfuscation.

Whatever your view, it’s off by default in Windows Server 2016. Those of a paranoid bent may now breathe …………. in….. out….in… out…. there you go 🙂

 

 

Blogging @ Route443

AD FS, ADFS, Azure, Azure AD, Identity and Access, Route443, Uncategorized, XenApp, XenDesktop

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”