As mentioned in my last blog post, Centrify recently shipped its Centrify for Office 365 solution. Centrify for Office 365 is an easy-to-deploy, Azure-based service that offers the industry’s most comprehensive solution for Active Directory-based single sign-on, user provisioning and mobile management. In this blog post I want to discuss the core identity scenarios that exist for Office 365 in order to set up future blog posts in which I compare what Microsoft provides with Active Directory Federation Services (ADFS) to Centrify’s approach to Office 365 federated identity.
So what are the ways in which you can set up identity for and user authentication to Office 365? As shown in this slide from Microsoft there are three core scenarios…
#1 is the “Cloud Identity” scenario that simply maintains your Office 365 identities inside Windows Azure Active Directory (WAAD — the underlying multi-tenanted / cloud-based directory service that Microsoft cloud apps like Office 365 and InTune utilizes) and have users sign on with their WAAD account directly into Office 365. Basically this is the “never the twain shall meet” approach between your corporate AD (i.e. your on-premise directory) and WAAD (i.e. a cloud base directory), and this scenario results in IT managing yet another identity store within their organization while end users have one login for AD and a separate login for WAAD/Office 365.
#2 is the “Directory and Password Sync” scenario that in effect does a one way sync (via a utility called “DirSync”) of your on-premise AD directory with WAAD (and with a new enhancements to DirSync it gives you “same sign-on” via password hash sync). With this approach you end up having your users re-enter their username/password over and over again (but at least it is the same password…)
#3 is the “Federated Identity” scenario that enables users to use their AD credentials to login to Office 365. This means the corporate AD authenticates your Office 365 users, and AD stores and controls the password policy. If a user is on-premise (i.e. already has logged in to Windows or via a Centrify-enabled system like a Mac or Linux system — meaning they already have the Kerberos credential from AD) then the authentication happens silently so no typing of any passwords to launch Outlook etc.
Clearly the third scenario is the preferred scenario as users have true single sign-on (or silent authentication aka “Zero Sign On“) and IT controls the password policies and can use AD as the means to control who can authenticate etc.
So what’s available for “federated identity” for Office 365? Centrify provides its solution for Office 365 single sign-on and federated identity, while Microsoft has historically provided Active Directory Federation Services (ADFS) as a potential solution for federated identity of Office 365.
I talked at a high-level in my prior blog post about Centrify for Office 365, but let now spell out at a high level what ADFS is about, in order to set up future blog posts that do a more detail comparison.
ADFS is a software-based solution that utilizes a claims-based access control authorization model to implement federated identity. As discussed in this recent Microsoft whitepaper, historically to enable ADFS you would have to deploy a lot of hardware and go about poking holes in firewalls, etc. This web page shows a typical on-premise ADFS deployment, with servers in and out of the DMZ. I won’t go into the guts of the ADFS architecture, but the web page I linked to in the sentence above walks you through it.
As the aforementioned whitepaper discusses, to get Federated Identity for Office 365 utilizing ADFS you will have to deploy at least a minimum of 5 servers on-premise (they actually recommend more). This is what Microsoft calls “Scenario 1” in that whitepaper in which all Office 365 SSO integration components are deployed on-premises and on dedicated hardware/servers. (Not to be confused with the higher level scenarios I spelled out earlier, basically what Microsoft is saying that within the Federated Identity scenario it offers a set of sub-scenarios). But as the whitepaper acknowledges, deploying “ADFS requires additional expertise, introduces complexity, and has higher operational costs” mainly in the form of additional servers and maintenance of ADFS.
Hence Microsoft now has tested out and documented alternative scenarios in this whitepaper (“Scenario 2” and “Scenario 3” – again these are sub-scenarios of the Federated Identity approach to Office 365 identity) for ADFS in which you deploy all or some of the ADFS servers in an Azure data center as virtual machines, i.e. shift some of the servers from on-premise to the cloud. But this still requires some on-premise hardware in the form 1 or 2 VPN routers that tie your environment to your virtual machines, as well as an additional minimum of 7 to 13 virtual machines in the cloud and/or on-premise.
Clearly whenever a company is trying to move to a cloud-based approach for email and collaboration, part of the goal is to reduce on-premise software and hardware. Thus having requirements that in order to say migrate off 2 Exchange servers to cloud-based email that to get AD-based SSO (which is what users got before with on-premise Exchange — and will expect similar functionality moving forward) customers now find themselves having to replace those 2 Exchange servers with a minimum of 5+ on-premise servers and/or up to 2 on-premise servers and 13 virtual machines in the cloud, and spend many tens of thousands for additional hardware/software/maintenance/installation. For some this may not be an appealing proposition, especially if you have not previously invested in ADFS.
Hence there is clearly an opportunity here for a simpler cloud-based approach (vs. hardware-based and/or virtual machines-based approach) to federated identity for Office 365, and I will drill down in the particulars of how Centrify differentiates with ADFS in my next few blog posts.
I will close this blog post with saying that Centrify has been working with ADFS for a number of years, and we were in fact the first vendor to support ADFS on non-Microsoft web servers back in 2005, and we look forward to areas of further collaboration with Microsoft around ADFS. Centrify does not see ADFS as a direct competitor per se, in part because ADFS is not a chargeable product from Microsoft. We really see ourselves as offering a completely different approach than the hardware-based approach you get with ADFS and one that should be considered by companies looking to address their federated identity needs for Office 365. So stay tuned for my next few blogs posts on how Centrify and ADFS compare and contrast, and net net based on your needs you can decide which one approach is better.