Today I’m going to write about Active Directory Federation Services (AD FS). AD FS provides authentication and single sign on (SSO) experiences for cloud based services and apps. With most infrastructure components AD FS 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 (AD FS) so it only makes sense to reference that.
Part of the main reason to implement AD FS 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 AD FS servers there’s numerous considerations and options available. I won’t go into too much detail about servers, AD FS farms or AD FS 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 AD FS 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, there’s additional components and requirements like either a VPN or Express Route and additional server components like domain controllers etc.
An important cloud compute hosted AD FS 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 AD FS server farm, or the AD FS server itself, users cannot authenticate.
Moreover, doing away with internal DNS pointing to the internal VIP for AD FS and always using the external VIP of the AD FS 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 AD FS internally.
Windows Integrated Authentication needs to be able to connect the AD FS server directly for that functionality to work. Without getting to technical, the reason being is that AD FS Web Application Proxies are not able to pass through all the required traffic to initiate a Win Int Auth logon.
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 AD FS farm or solution it’s important to take into account authenticating to AD FS via “an internal network connection” or “an external network connection” which will achieve different results.