Removing the Identity Barrier for Office 365 Migrations
Abstract
Migrating to Office 365 can present many challenges. One of the greatest is the problem of identity. How do you easily connect your existing users, groups and other Exchange/Lync information in Active Directory to Office 365, and keep it up to date? Active Directory environments can be complex and often contain incorrect or inconsistent data. If you are working with Microsoft or one of their partners to migrate to Office 365, you may be advised to go through a lengthy clean up or consolidation of Active Directory. Migrating to Office 365 requires you to understand and resolve issues with Active Directory—otherwise you can expect delays in decommissioning expensive on-premises systems. Read this whitepaper to learn how Okta’s cloud identity service can be used to accelerate and simplify your Office 365 deployment while increasing overall security.
Introduction
How do you quickly connect Active Directory (AD) and all its user and group attributes to Office 365? This guide describes how Okta can help you avoid costly Active Directory consolidations and speed up your overall Office 365 migration without deploying costly on-premises servers.
Office 365's Identity Barrier
Migrating to Office 365 can present many challenges. One of the greatest is the problem of identity. How do you easily connect your existing users, groups and other Exchange/Lync information in Active Directory to Office 365, and keep it up to date? Active Directory environments can be complex and often contain incorrect or inconsistent data. If you are working with Microsoft or one of their partners to migrate to Office 365, you may be advised to go through a lengthy clean up or consolidation of Active Directory. Migrating to Office 365 requires you to understand and resolve issues with Active Directory—otherwise you can expect delays in decommissioning expensive on-premises systems. In the following pages, we will examine how Okta’s cloud identity service can be used to accelerate and simplify your Office 365 deployment while increasing overall security.
Understanding the Challenges of Migration
Making the move to Office 365 presents two big hurdles: the first is data migration: of mailboxes in Exchange, and files in SharePoint. The second hurdle is identity management: dealing with the problems of authentication and keeping user and group information in sync with Active Directory.
Data Migration
Moving the email and file data—often terabytes of information—over the Internet to Office 365 can be time-consuming and error-prone. Built-in migration features in Exchange, combined with free tools from Microsoft, do not always provide a speedy and trouble-free experience. Exchange infrastructure might need to be upgraded to current versions, further delaying the Office 365 migration. Because of these limitations, many third-party companies like BitTitan and SkyKick have evolved to simplify and speed up the process of migrating.
Identity Management
The second challenge of identity has similar traits. Complexities in Active Directory are not always addressed with free tools offered by Microsoft, and they and require you clean up and fix data prior to migration. Just like the Microsoft built-in migration capabilities, the free identity tools also don’t deliver a complete end to end IT admin or end user experience, making the long-term management of Office 365 difficult. Third party vendors like Okta have developed solutions that are more complete and easier to use. The identity problem can be broken down into four main areas:
• Authentication. Most IT admins wish to minimize the impact of moving to Office 365 on their users and let them authenticate to Office 365 using their existing Active Directory username and password.
• User and group synchronization. Active Directory has all the information about users, distribution and security groups. Copying and keeping this information up to date in Office 365 is critical, especially for Exchange migrations.
• Automating creation of new users, and offboarding of existing/terminated users. Once Office 365 migration is complete, there will be new people joining, leaving, and changing roles within the business environment. Changes to users’ information and access to Office 365 must be immediately reflected in Active Directory.
• Simplifying, yet securing access on mobile devices. Many users want to configure tablets and phones for email and to access documents. This should be easy for users but also allow the IT administrator
to increase the security, leveraging techniques like multi-factor authentication (MFA) and enforcing phone passcodes.
Okta provides a modern identity platform for modern email and collaboration platforms. Microsoft’s tools, like ADFS and Azure AD Connect, do not deliver a true end to end experience for both the IT administrator and the end user. Worse, they were designed over 10 years ago based on old legacy architectures. These tools are not suited for the new cloud era and force compromises when it’s time to deploy Office 365. This is why Okta developed a service to fill in the gaps and provide a more automated and complete solution.
While this document focuses heavily on using Okta for Office 365, Okta is a service that extends far beyond just this one application. Okta has the most mature cloud identity integrations for platforms such as Salesforce, Box, Workday, ServiceNow, Google Apps, Zendesk to name a few. There are more than 5,000 pre-integrated applications in the Okta Integration Network. To use Okta as an enterprise-wide Identity and Access Management (IAM) platform, large enterprise and public-sector customers require integration to a multitude of on-premises and custom applications. Okta provides several mechanisms across products to enable integration to these systems. Okta also has the most mature provisioning integrations, and a mature mobile access management platform that is integrated with identity. While this paper discusses Okta and Office 365 in detail, please keep in mind that Okta is a much larger identity platform that addresses a wide variety of use cases across many other services.
Okta was Born in the Cloud
Before we dive into the detail, we need to explain how Okta came to be the leading identity management service for Office 365. Okta was co-founded by Todd McKinnon, who was the vice president of engineering at Salesforce. Todd had intimate knowledge of how IT solutions were being developed in the new paradigm of the cloud. He knew that identity was going to be a big problem and decided to look at how to solve it from a new angle. Instead of basing his idea on existing on-premises identity management architecture, he wanted to build a cloud-first solution that could also be connected to on-premises systems without increasing the IT server footprint. People were moving to the cloud to get away from managing on-premises services, and Okta needed to provide a solution that fit in with that strategy.
Leveraging his experience at Salesforce, Todd built a team to design an identity solution where the majority of all the logic for enterprise identity would live in a massively scalable, always available, multi-tenant cloud service. He also wanted to ensure that everything was integrated, without multiple administrative portals, and delivered with a high-quality user interface—a consumer-grade experience for an enterprise technology. But, he knew that on-premises directories contained lots of information that is required to enable seamless access to a cloud application. Okta developed a completely new way of connecting the cloud back to the datacenter without having to deploy new servers with large-scale software to configure and maintain.
The result was Okta’s identity and access management as a service—a clever approach to connect one cloud system to another, and also connect to on-premises identity resources. As we go through the rest of this guide, we’ll highlight how this modern architecture benefits both Office 365 implementations and other cloud applications—and how to secure and connect them all together.
Authentication
The vast majority of Office 365 deployments are about migrating from the on-premises equivalent. The most common scenario is moving from Microsoft Exchange to Office 365. Exchange integrates heavily with Active Directory, and for many years IT administrators have invested massive time and effort in managing users and groups and other Exchange data in the directory. The main advantage for Exchange alongside Active Directory was a single username and password for authentication to Windows desktops and email. The Active Directory username and password were also used for many other business applications: file servers, finance systems, HR applications, and collaboration platforms. All these systems integrated with Active Directory, and with it, companies achieved a single sign-on (SSO) experience.
Office 365, however, is a SaaS application. After users are migrated to Office 365, each employee ends up with a brand-new user account in the cloud. You could just stop there, tell the user their new Office 365 login username and password—but lose the years of investment to achieve single sign-on in Active Directory. Users become frustrated because they now have to manage more than one password, and IT administrators become frustrated with disconnected environments.
Attempting to solve this problem of authentication using the Microsoft legacy technologies forces a choice among a few options:
• Implement Azure AD Connect and federate the authentication from Office 365 back to on-premises Active Directory using Active Directory Federation Services (ADFS)
• Sync the password hash from Active Directory into Office 365 using Azure AD Connect
• Implement Azure AD pass-through authentication (used with Azure AD Connect)
Active Directory Federation Services (ADFS)
ADFS is a powerful federation platform that authenticates Office 365 users to their Active Directory account by responding directly to the user authentication requests. You must configure and manage a network path from the internet to your ADFS servers, and from ADFS to your domain controllers. Network connectivity from the cloud, all the way into your Active Directory servers must be reliable. If anything fails, users cannot authenticate to Office 365.
ADFS Hardware Requirements
To deploy an ADFS solution, most companies end up with four new on-premises servers and network proxies and load balancers to configure. When there are multiple domains and forests, that number can climb dramatically and may require deployment of SQL server clusters. If you want to reduce costs by moving to the cloud, does it make sense to deploy more servers in your data center?
Azure AD Connect
Microsoft offers an alternative to deploying ADFS, which is to use their directory synchronization solution, Azure AD Connect. Azure AD Connect also resides in your Active Directory domain, but it makes outbound internet connections to Office 365, copying your Active Directory data. There is no need to manage public internet traffic into your corporate network. However, your network must be configured to allow Azure AD