Challenges of Identity and Mobility for Office 365

This post was co-written by Simon Thorpe, who works on Okta’s product team and Slalom Consulting’s Rick Koppin (Director of Slalom’s Technology Enablement practice) and Daniel Chiang (Solution Principal, leading Slalom’s Information Security and IT Optimisation practices). Daniel and Rick have a combined 20+ years of experience successfully helping organisations and clients build and implement IT strategies and initiatives and Simon, a former Microsoft employee, has been leading the charge around educating customers and partners on the identity and mobility challenges around Office 365 at Okta.

Okta and Slalom Consulting have extensive experience with a wide range of Microsoft technologies and services. Rick and Daniel have been advising clients on Microsoft strategy for years and Simon works closely with Okta’s Microsoft account teams to make sure Okta’s technology works effectively for Office 365 customers. At the start of the year, Ed Sawma (who also works on Okta’s product team) blogged about the skyrocketing demand from customers using Okta for Office 365 and recently published another post highlighting some of the identity and mobility challenges of moving to Office 365. It became clear to us that customers would be interested in further discussion into this topic, including examining the pros and cons of using the out of the box tools from Microsoft, which is what we’d like to do today.

Migrating email, collaboration and file sharing to the cloud

For many businesses, migrating existing on-premises applications and services (Exchange, SharePoint and Lync) to their equivalent cloud service offering in Office 365 makes business sense. Accomplishing this appears straightforward. The first phase is managing access for the user from the on-premises system to using the cloud. The second phase is to migrate data from these on-premises systems (employee email, files and contacts) to the cloud environment. The approach seems simple, yet it’s complex in implementation. All the information about users, groups, and contacts must, be delivered to Office 365, creating a smooth transition to the new services. Additionally, authentication to these services must adhere to existing corporate credentials and policies.

Microsoft has tools that aid in migrating both data and user access, but they lack important features, require significant design considerations and present compromises in functionality. These tools are based on older technologies that are rooted in on-premises architectures. Finally, if the services delivered by these tools fail, users cannot access their data in Office 365.

Years of use and abuse of Active Directory

Since Active Directory has been the default identity store in enterprises for years, most AD environments have accumulated a mix of both useful and discarded identity data. A common example is when a company acquires another organisation, sets up an Active Directory forest and discovers the acquired company has a legacy directory infrastructure from a previous acquisition. Over time, the buildup of Active Directory identities, infrastructure, and domains data can be very unmanageable.

The outcomes are clear:

• Users with missing information due to poorly followed manual processes.
• Many forests and domains created by different IT groups with inconsistent standards for username, display name and email address, etc.
• Disconnected Active Directory environments that do not communicate with each other, but collectively hold redundant user and group information for the company.

These problems always prevent an easy move to Office 365. A migration presents a chance to standardise on email address formats and an opportunity to clean up user data, such as job titles and department names. When Active Directory has inconsistent and duplicate data, cleanup and consolidation of domains into a single forest can take weeks or months of time.

Using the Microsoft tools for Office 365 identity

There are two main areas that need to be addressed when using Office 365 and leveraging an organisation’s existing Active Directory.

• Authentication: Use the current user name and password stored in on-premises Active Directory for all Office 365 services.
• Synchronisation: Keeping user and group information in Office 365 up to date with on-premises Active Directory.

For authentication, the goal is for users to use the existing username and password they are familiar with and use for other on-premises systems. Microsoft has two methods, both of which are a compromise of choices. First, the use of Active Directory Federation Services (ADFS) for single sign-on (SSO). ADFS has been around since 2005 and is an on-premises authentication service with a heavy footprint. It’s common to end up with four or more new servers in multiple data centres.

Microsoft recently created another option – just synchronise the Active Directory password hash to Office 365. This is done with a simple, single server technology. But now your users authenticate directly with Office 365 identities, and changes to the user account are delayed. Thus, if you disable an account in Active Directory, it doesn’t immediately prevent that user from accessing email and other Office 365 resources. Also the single server model is a single point of failure.

Diagram showing many ADFS servers for Office 365 federated authentication

Diagram showing a single password sync server to Office 365

Before users can be authenticated, account information must be created and kept up to date. As before, Microsoft provides a few choices, but again they are rooted in older technology. Microsoft has resources which details the differences between the various choices: https://msdn.microsoft.com/en-us/library/azure/dn757582.aspx

Confusing? Yes.

The right tool depends on the type of Active Directory environment in the enterprise. Okta has created a technical guide which goes into detail of regarding selecting the appropriate tool for each respective enterprise environment.

Access Office 365 with mobile devices in a BYOD world

Once authentication and management of users is complete, a process needs to be developed to determine how existing and new users access Office 365. Traditionally users accessed Office on the Windows desktop. But today users often access Office 365 first on a mobile device. Microsoft has responded well in delivering Office clients on these platforms, but simplifying the ability for a user to configure the native email account or install the Microsoft apps still remains.

One of the most common use cases is when a user has Office 365 email configured not only on their laptop, but also on their iPhone and iPad. As a result, if a user account is in Active Directory and the company has a 90-day password change policy, then a change in password prompts a wrong password to be validated against Office 365. The result is a locked out account and a call to the help desk is then required.

Making the right, informed decision

As it has become clear, there are several decisions that need to be made regarding identity and mobility for Office365. Okta has created a TechGuide to review this topic more in depth. Okta also recommends a discussion with a trusted Microsoft partner around identity and mobility to really understand what is needed to make your users successful. This is a complex, and some of the most advanced IT organisations still struggle to successfully migrate their data. Slalom Consulting has guided many of our clients through to successful migrations of their data, and they have proven to be one of our recommended partners to help enterprises solve their identity and mobility challenges.

To learn more about how Okta can help with identity challenges around migrating to Office 365, visit our website at https://www.okta.com/integrations/microsoft-office-365/#overview.