Today I’m going to write about Active Directory Federation Services. ADFS provides authentication and single sign on (SSO) experiences for cloud based services and apps. With most infrastructure components ADFS can be easily deployed either on-premises or in cloud compute hosting service like Azure. I say Azure as it’s from Microsoft and we’re dealing with a Microsoft authentication server (ADFS) so it only makes sense to reference that.
Part of the main reason to implement ADFS is for the single sign on experience users can get with Windows Integrated Authentication available in domain joined Windows PC’s and Internet Explorer. As Windows continues workplace market dominance with a share of over 80% (reference), its easy to see why ADFS and SSO is a very tempting proposition.
When deploying ADFS servers there’s numerous considerations and options available. I won’t go into too much detail about servers, ADFS farms or ADFS Web Application Proxies, but, there are two main pillars that I want to highlight before I make the main point of this post.
On-premises ADFS deployments are very easy and straight forward. By that I mean SSO can be configuring seamlessly for internal domain joined workstations. There’s not external networking involved and with simple group policy applied to machines, SSO is deployed steadfast.
The second option though is a public cloud like Azure. When ADFS is deployed in Azure, for example, theres additional components and requirements like either a VPN or Express Route and additional server components like domain controllers etc.
The ADFS “gotcha”
An important cloud compute hosted ADFS design “gotcha” is network connectivity. Network Connectivity! Site to site VPN’s are all well and good for connecting to Azure to start an infrastructure design. However, it’s not the end goal of a design. I’ll cut to the chase and keep this simple: when a VPN goes down and your DNS internally points to the internal VIP of either the internal load balancer in front of the ADFS server farm, or the ADFS server itself, users cannot authenticate.
Moreover, doing away with internal DNS pointing to the internal VIP for ADFS and always using the external VIP of the ADFS WAP’s will lead to a considerable question: are users okay with entering credentials into ADFS once a day, or is SSO an absolute must with no user interaction with ADFS internally.
Windows Integrated Authentication needs to be able to connect the ADFS server directly for that functionality to work. Without getting to technical, the reason being is that ADFS Web Application Proxies are not able to pass through all the required traffic to initiate a Win Int Auth logon.
The solution and why to use Express Route
The solution is dedicated network connectivity and appropriate internal DNS. Site to site VPNs are subject to no SLA. Connectivity is not guaranteed and there’s a multitude of factors that can cause a drop out of disconnection. Guaranteed SLA and performance is achieved through dedicated connections to the cloud.
Express Route is that dedicated connection and with good network design allows for Azure to be a simple extension of the on-premises infrastructure. This isn’t the only benefit and solution for this “gotcha”, but in this instance I’ll keep it fairly short and simple.
User expectations are tricky to meet. At the end of the day everyone is a user. When designing a cloud hosted ADFS farm or solution it’s important to take into account authenticating to ADFS via “an internal network connection” or “an external network connection” which will achieve different results.