Active Directory Federation Services has two different types of servers: the AD FS Server and the AD FS Proxy Server. The AD FS server sits inside the organization on the internal network and communicates directly with your AD DS domain controllers. The AD FS Proxy Server lives in your perimeter’s DMZ and serves the role of authenticating users who are not on the corporate network. It does this by hosting a web service (Internet Information Services depending on the Windows Server version) which displays a login screen. This occurs because – unlike a Kerberos ticket being passed on a corporate network from a domain-joined computer – the cached AD DS credentials cannot be passed.
Beginning with Windows Server 2012 R2, the AD FS Proxy Server was included in a new role called the Web Application Proxy (WAP). In addition to the WAP providing AD FS Proxy functionality, it also is a reverse proxy for publishing specific internal applications (as opposed to a VPN where every app is accessible) that use SSL, while providing defense in depth by terminating the traffic and initiating a new request to the application(s).
It is important to remember that when AD FS is chosen for Office 365 that AAD Sync still plays a significant role in synchronizing AD DS user accounts and group objects into Azure AD. AD FS simply eliminates AAD Sync’s password hash synchronization.
There are several options for deploying Active Directory Federation Services which I’ve outlined in the following sections and illustrations. You’ll notice that for each server (e.g., AD FS Server) there is always a second, identical server. The second (or third, fourth, etc.) are called a farm and provide high availability, which is a best practice. If having four total AD FS servers is too costly, I recommend relying only on AAD Sync with password hash synchronization which will provide 24×7 uptime and a very good user experience.
Option 1 – Highly Available AD FS in a Single On-Premises Site
One very popular option is to implement a highly available Active Directory Federation Services infrastructure in one of your data centers. Your single data center will have the following servers: one AAD Sync server, two AD FS Servers in a farm and two WAP/AD FS Proxy servers. The WAP/Proxy server can utilize Windows network load balancing which ships in all editions of Windows Server 2012 R2 and the Enterprise/Data center editions of Windows Server 2008 R2. The free Windows Internal Database (WID), which ships in Windows Server can be used for AD FS’ configuration database, but Microsoft SQL Server can also be utilized if you need the scale or you have existing instances of it available.
Option 2 – Highly Available AD FS in Two of Your Data Centers
If you have two or more (possibly geographically dispersed) data centers, another highly available AD FS deployment option is to split each of the two AD FS server roles between each data center. Each data center needs:
- One AD FS Server
- One WAP/AD FS Proxy Server
- One global network load balance (NLB) appliance
- One SQL Server Enterprise Edition server
Since Windows network load balancing does not support spanning sites, each data center will have use the global NLBs to present one IP address registered as an A Record (e.g., federation.contoso.com) registered with a DNS Registrar over the Internet to the Software-as-a-Service provider. One data center will host the AAD Sync server, which does not support being in a farm for high availability. Fortunately, a new AAD Sync server can be brought online in a short period of time.
If disaster recovery is sufficient, then the Global NLBs can be eliminated by relying on a manual change to the DNS record, as well as using the Windows Internal Database instead of SQL Server.
Option 3 – Highly Available AD FS in Microsoft Azure Virtual Machines
Since Microsoft Azure brought their Infrastructure-as-a-Service (a.k.a., virtual machines) online, we’ve helped a number of customers design and configure AD FS to run in those virtual machines. Azure virtual machines have a feature called Availability Sets, which are required to get the 99.95 percent uptime service level agreement (SLA). Azure automatically takes two or more virtual machines (VMs) in an Availability Set and places them in an Update Domain (UD) and a Fault Domain (DM). In the simplest terms, when Azure automated scheduled maintenance occurs, the VMs an Availability Set will never be taken offline at the same time. So, just as we’d paired AD FS servers that were on-premises for HA, we’ll put those servers in an Availability Set. As a best practice, it is recommended that two domain controllers be added, which are an extension of your on-premises forest/domain. AD FS, plus the DCs, plus AAD Sync provide a cloud-based authentication platform that enables your users to get to email, SharePoint and/or Lync even in the event that you had a total failure of your on-premises data center (or lost Internet network connectivity if the users worked remotely where there was an Internet connection). Microsoft recommends having two paired domain controllers for each AD DS domain.
As illustrated below, the domain controllers for one AD DS domain in addition to the federation infrastructure required to interoperate with Office 365 necessitates seven Microsoft Azure virtual machines.
Clearly, there are many options and choices available to you to meet your organizations’ size, user requirements and budget, so I’m happy to answer any questions in the comments field.
Curious to learn even more about Single Sign-On versus Same Sign-On? Here are a few other posts my CDW colleagues have written on the subject:
- Beyond Office 365 – Identity and Security in Azure
- What is Same Sign On Anyway?
- How to Deal with Multiple Logins
As always, CDW is here to help every step of the way. Check out our Solutions and Services page for more information about how we can help you maximize the return on your I.T. investments.