Previous posts: Part One: Single Sign-On Versus Same Sign-On with Office 365 and Active Directory Domain Services

Part Two: Single Sign-On Versus Same Sign-On with Office 365 and Active Directory Domain Services

Let’s talk about the columns three and four of the Office 365 Login User Experience Matrix found below.

Active Directory Federation Services (“AD FS”) is most often mentioned as the solution for single sign-on. Authentication federation works because one service/resource provider trusts another identity provider to complete the authentication on their behalf. The lingua franca for federated identities on the Internet is the Security Assertion Markup Language (SAML) which is an XML-based, open standard. Active Directory Federation Services can interpret SAML which makes it an excellent bridge between the tens of thousands of SaaS (and other) applications and Active Directory Domain Services. As a role within Windows Server, AD FS is licensed by purchasing a Windows Server license and for most of you will be covered by your existing client access licenses (CALs). 

SSO Office 365 6.5
Office 365 Login User Experience Matrix

While I won’t bore you with the nitty-gritty details of how it works, as you can see in the image below, there are 11 exchanges that take place before the user from one organization (Datam Corp) is logged into the website being hosted by another organization (Trey Research). Fortunately, this all occurs within seconds from the time the user using their AD DS domain-joined computer first attempts to access Trey Research’s web server.

SSO Office 365 6.5 2

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.

SSO Office365 6.5 3

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.

SSO Office 365 6.5 4


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., 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.

SSO Office365 6.5 5

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.

SSO Office 365 6.5 6 

Option 4 – Highly Available AD FS in a Single On-Premises Site with Microsoft Azure for Disaster Recovery

The last deployment option provides both high availability for AD FS in a single on-premises site while enabling disaster recovery in Azure.

There are two primary means by which Azure can provide disaster recovery. The first is simply to build shadow servers in Azure that mirror those that are on-premises. This is the configuration I illustrated below. One of its nice attributes is that – with the exception of the DC – all of the other VMs can be turned off so you aren’t charged (depending on how you’ve licensed Azure). The second is to use Microsoft’s Azure Site Recovery, which is a SaaS that provides an orchestrated recovery of on-premises physical or virtual servers. Currently, ASR provides support for Hyper-V with VMware support in preview (which is analogous to a non-production beta) and, if your budget permits, it is a very good option.

In the shadow VM configuration, during a short term outage (an hour to a few days) when your on-premises data center’s AD FS infrastructure has failed, you will need to manually reconfigure your DNS registrar’s A Record address, change the settings in the Office 365 management portal to recognize the new infrastructure, as well as “turn on” the VMs for the AD FS Server, AD FS Proxy Server and the Directory Synchronization Server. A long-term, on-premises data center outage would require all of the short term steps plus switching to a new AD FS configuration database, decommissioning the on-premises DirSync server, etc.


SSO Office 365 6.5 7


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:

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.

One thought on “Part Three: Single Sign-On Versus Same Sign-On with Office 365 and Active Directory Domain Services

  • I never found Single Sign-on as interesting as you make it in this post. “…There are 11 exchanges that take place before the user from one organization (Datam Corp) is logged into the website being hosted by another organization (Trey Research)” The graph is mind blowing too. Thanks for the great article. I’m going back to read part 1 and 2 now.

Comments are closed.