In the final of a three part series I will discuss some of the Windows Server roles that you may not have had much experience with in the past in the SMB space to give an idea of why the virtualisation requirements can vary drastically depending on the customer's requirements instead of the usual conversation around the size of the customer being the driving factor. In Part 1 I covered those reasons that many are already familiar with, such as RDS, which on it's own can have a number of VM pre-requisites. In Part 2 I wrote about the kinds of capabilities you can leverage on-premises with Microsoft's Enterprise Mobility Suite and the VM requirements that could generate. Today the focus will be on the teaser I finished with in Part 2, Active Directory Federation Services (ADFS).
If you primarily deal with customers in the Microsoft SMB (up to 250 seats) space, the chances are you probably haven't had to work with ADFS, but the stat I shared in the last post was that for larger organisations 36% of the authentications to Office 365 are via ADFS. With ADFS you are authenticating users against your local Active Directory, even when they are trying to sign in to services such as Office 365. There are a variety of reasons why you may want to do this, but for SMB customers the overhead of deploying and maintaining probably don't make them worthwhile. Here's an ADFS architecture diagram…
What you will notice here is the deployment of two ADFS Proxy Servers on the network perimeter, two ADFS servers inside of the network, alongside the existing Domain Controller and Azure Active Directory Connect server for directory synchronisation. While you can get away with a working deployment where you reduce each instance to one, and can co-locate some of the roles, you won't meet the high availability requirement that ADFS needs in a real world deployment.
This post isn't going to cover ADFS in depth, so here's a summary of why you may choose ADFS versus password sync.