Office 365: To Federate or Not to Federate… that is the Question

Yesterday, Microsoft released a new version of their ‘DirSync’ utility (http://technet.microsoft.com/en-us/library/dn246918.aspx) which up until yesterday provided a basic ‘copy’ of your local Active Directory accounts (Active Directory Domain Service or ‘AD DS’) from your premises to the MS Cloud directory (referred to as ‘Azure Active Directory’) for Office 365 (and other Cloud apps such as Team Foundation Service (TFS Online).

This blog is written for those considering moving to Office 365 (or have moved to Office 365) but haven’t identified any other application in the organisation apart from Office 365 that requires Active Directory Federation Services and SAML/WS.Federation application authentication and protocol support.  Many of our customers have been ‘sitting’ on the fence when it comes implementing AD FS purely for Office 365 to achieve user ‘Same Sign On’ authentication.  With this new version of DirSync, Microsoft have allowed organisations to avoid AD FS, but achieve a ‘same username and password’ authentication (as their local domain joined workstations and/or AD DS integrated applications) experience to Office 365.

Up to this point, for those customers wanting to have the same ‘username’ and ‘password’ (a ‘Same Sign On’ experience) for their Office 365 service, they essentially had two options:

• Option #1: Cloud Identity + DirSync – users get a brand new password to remember but keep their existing ‘UPN’ login name (usually their email address ‘e.g. michael.pearn@kloud.com.au’). It was up to users to set their own password using the ‘portal.microsoftonline.com’ website, and ensure that each time they set their AD DS password, they would be disciplined to up-date their Office 365 password via the portal. Password changes could occur in either Azure AD or AD DS and be out of ‘sync’ if a user did not follow the correct procedure or expiration windows were different in either services.  Password complexity rules were maintained in both AD DS and Azure AD, and it was expected administrators set these password rules to be the same so users could have the same password for both services.
• Option #2: Federated Identity + DirSync + AD FS on-premise infrastructure – users keep their existing username (could be sAMAccount name or could be ‘UPN’ value) and their existing Active Directory password. Authentication is always performed on-premise against the AD FS and AD DS infrastructure (and AD DS password complexity rules). The AD FS service is required to be published out to the Internet for external authentication requirements.

It is possible to operate Option #1 without DirSync, however its really only for those organisations that do not have an on-premise AD DS or are very small identity population wise (<50) and users can be manually created/deleted/licensed using the Office 365 portal.

With this new release of ‘DirSync’, Microsoft have updated these options now in regards to authenticating to Office 365 to achieve a ‘Same Sign On’ experience. Essentially Option #1 is updated to now achieve password synchronisation:

• Option #1: Cloud Identity + DirSync – users keep their existing username (‘UPN’ value) and their existing Active Directory password. The users password ‘hash’ is replicated to Azure AD via the new version of DirSync. Microsoft cannot decrypt your password hash in Azure AD so existing security protocols are maintained.  Password complexity, history and expiration are then exclusively managed out of an on-premise AD DS service.
• Option #2: Federated Identity + DirSync + AD FS on-premise infrastructure – users keep their existing username (could be ‘domain\sAMAccount’ name or could be ‘UPN’) and your existing Active Directory password. Authentication remains ‘on-premise’ via AD FS.  Similar to Cloud identity, password complexity, history and expiration is now exclusively managed out of an on-premise AD DS service.

Essentially Options #1 and #2 now provide the exact ‘same sign on’ user experience but with fundamentally different authentication mechanisms and locations of these authentication mechanisms.

Why AD FS isn’t for everyone

Kloud has worked with many customers who have struggled with implementing a brand new AD FS infrastructure if Office 365 was their first ‘SAML’ or ‘WS-Federation’ aware application they’ve ever implemented.

The key difficulties about integrating Microsoft AD FS with Office 365 for our customers included:

• Your users need AD DS accounts – a lot of public sector and universities don’t have AD DS services already, and often reticent to implement a new AD DS directory purely for Office 365 services. Pushing a ‘username’ and ‘password’ from a third party directory or database to an Office 365 Cloud identity is only achievable with a Cloud Identity model so they chose not to look at Federation alternatives. Alternatively, these organisations have looked to 3^rd Party Federation scenarios that can integrate directly with non-MS directories or databases. However as Office 365 supports three key systems (Exchange Online, Lync Online and SharePoint Online) not every system in the portfolio supports every client and access scenario required for Office 365. Microsoft supports Shibboleth as a Federation access service however there are limitations to this support.  Anyone considering a Federated Identity model to work with Office 365, but without a corresponding AD DS and AD FS on-premise infrastructure (or equivalent future MS based solutions involving Azure Federated PaaS services) should test, test & test all access scenarios with their client device base before committing to this access model.
• You need to design and architect your AD FS infrastructure ‘the right way’ and understand DNS and your required authentication mechanisms (e.g. using integrated authentication for domain joined workstations versus forms based authentication for BYOD devices).
• You need to provide high availability of the service or at least an extremely rapid way of restoring services ie. why hang a ‘Cloud’ solution off an on premise authentication service that could fail easily if not architected properly and is not covered under a Microsoft Service Level Agreement (SLA)?
• The Organisation has to invest in AD FS skills. AD FS can be complicated to design and relies a lot on the part of infrastructure and application designers to understand terminology unique to its architecture ‘ie. what’s a Relying Party Trust?’ which while sounding complicated to the novice is actually quite straightforward. Also, AD FS failure scenarios can be quite complicated to troubleshoot if the helpdesk is not involved in the design of the solution or not trained to help perform ‘root cause failure’ analysis should users complain they ‘cannot get to their email’.  Kloud recommends always to at least deploy the “Sample Claims App” that is provided in the ADFS installation files as an alternative ‘SAML aware application’ that can be used to troubleshoot whether the ADFS service ‘is working’ first before ringing Microsoft to complain that Office 365 ‘is down’.

Cloud Identity + DirSync from now on?

So taking all these points into consideration, and if a Kloud customer was investigating which option suited them for their Office 365 access strategy (as of the 5^th of June 2013), the following section outlines the relative benefits (and costs) of choosing a Cloud Identity model over a Federation Model.

Advantages over Federation Model

Cloud Identity with DirSync now provides the following benefits over a Federated Identity model of access:

• It’s not just ‘Office 365’ – Microsoft in their announcement state that DirSync will now support other MS Online applications such as TFS Online (see TechNet link).  Their support in supporting future Azure AD integrated applications to be WS Federation or SAML aware is unknown so the risk in going with an exclusive Federated Model with Office 365 is over time having to support as well Azure AD integrated applications that only support DirSync and password hash synchronisation.
• You don’t need any other on-premise server apart from a single Windows Server hosting a single instance of DirSync (and of course the existing AD DS infrastructure).
• Those customers running a Federated Identity (AD FS) solution purely for Office 365 reasons can now decommission the ADFS infrastructure (up to 2-6 servers) and move to a Cloud Identity model saving Windows Server licenses, virtual hardware and AD FS support cost.
• Authentication occurs at Office 365 services only and not to any on-premise infrastructure (AD FS or AD DS) reducing failure points. This is very important for those IT departments that are required to support a lot of BYOD devices, mobile devices and those devices that spend the majority of their time connected only to the Internet and not to a corporate network.
• No browser re-direction – Your browser is re-directed multiple times accessing SharePoint in a Federated scenario, and your browser has to be able to access your ADFS Security Token Service URL from ‘everywhere’ (ie. every corporate/organisation network plus the Internet) to get a token to access Office 365. With a Cloud Identity model, this re-direction is not required so authentication is ‘quicker’ (relatively speaking).

Disadvantages (or “no advantages”) against Federation Model

Cloud Identity with DirSync still has the following costs or disadvantages against a Federated Identity model of access:

• Your user still needs an AD DS account – there’s no avoiding this in either Cloud or Federated Identity access models
• DirSync still does not support multiple Active Directory Forests. Microsoft still recommends architecting a solution involving migrating everyone to a consolidated Active Directory forest and domain to host all Office 365 users. Kloud has implemented Microsoft Forefront Identity Manager (FIM) for these ‘multiple AD DS forest’ scenarios.
• Federation supports ‘two factor’ (2FA) authentication ‘hooks’ into AD FS authentication screens. There are no plans at this stage to allow for on-premise two factor authentication technologies to hook into Azure AD. DirSync does not natively support 2FA solutions. There are rumours right now about Azure AD with Azure Rights Management Service (RMS) offering a certificate based solution whereby a certificate turns your device into the ‘second factor’ by nature of having the certificate.
• The DirSync service now will have to be architected to achieve rapid restoration to mitigate potential cases of failure. Previously if the DirSync service went offline, only new users or updating of existing attributes would be impacted. If DirSync goes offline and your users change their passwords, those password changes won’t be replicated to Office 365 until DirSync is restored and in the meantime you’ll have users contacting the helpdesk wondering why their new password doesn’t work against Office 365.
• DirSync still doesn’t activate your users against valid Office 365 licenses! Kloud uses a Powershell ‘Connector’ (previously called ‘Management Agent’) in an on-premise FIM server to activate and de-activate Kloud employee licenses to Office 365.  DirSync doesn’t mitigate against a robust, secure, on-premise identity management service.  The same applies for a Federated Model of access.
• Same Sign On only. You cannot achieve ‘single sign on’ for a domain joined Windows workstation with a Cloud Identity model. You still need to authenticate to Office 365 with the same username (ie. UPN value – often a user’s ’email address’) and password after you login to a domain joined Windows workstation (assuming that workstation does not have a SharePoint cookie already or ticked boxes to ‘remember my password’). A Federated Identity supports ‘single sign on’ to some applications such as SharePoint online, using a local on-premise AD FS service (and your ADFS DNS architecture is correct).  The key difference is the number of authentication screens users will see, especially on workstations that have not logged into previously such as Kiosk PCs.
• Password changes do not occur ‘instantaneously’ – there is still a ‘one minute to a couple of minutes’ lag from the password changing in AD DS, to it being picked up in DirSync and pushed to Office 365. Communication to end users should not use the word ‘instantaneously’ as we have noticed a small ‘lag’ in this replication in our initial testing of DirSync
• Security may be diminished – Now that the password ‘hash’ is replicated to Azure AD, the Office 365 (Azure AD provided) password policy is not enforced, so if your on-premise AD DS password policy is weak, it will also be weak accessing Office 365 services. Your IT security admin. will still be expected to maintain and enforce AD DS’s password complexity requirements using Group Policy (GPO).

Let us know in the form below if you want to know anything more in this area if you’re considering Office 365 access and authentication scenarios:

[contact-form][contact-field label=’Name’ type=’name’ required=’1’/][contact-field label=’Email’ type=’email’ required=’1’/][contact-field label=’Website’ type=’url’/][contact-field label=’Comment’ type=’textarea’ required=’1’/][/contact-form]