Office 365 Deployment TechGuide: Identity and Mobility Management

Office 365 Deployment TechGuide: Identity and Mobility Management Migrating to Office 365 is a complex undertaking. This TechGuide covers in detail the identity and mobility management challenges associated with migration and guides you through the tools provided by Microsoft to address these challenges. Active Directory Okta Inc. I 301 Brannan Street, Suite 300 I San Francisco CA, 94107 info@okta.com I 1-888-722-7871

Sync users & groups Active Directory Federated Authentication Moving Exchange, Sharepoint, Lync And Active Directory To The Cloud Why can it be a challenge to migrate? There are two key tasks required in moving from on-premises technologies, like Exchange, to the Office 365 cloud equivalent. The first is data. Emails in your inbox, your schedule in the calendar, documents in SharePoint. Microsoft has a set of free tools to help customers migrate, but they lack some features and can be hard to use. Microsoft is well known as a company that builds platforms and often relies on its large network of partners to provide the complete solution. Office 365 is no different in this regard and companies like BitTitan and SkyKick are often purchased to make the data migration easier, quicker and more complete. The second challenge around an Office 365 migration is synchronizing your user information to Office 365 while continuing to use Active Directory for authentication. Active Directory usually contains up to date information about your employees, therefore you want to use this when creating and updating your user accounts in Office 365. You also want to avoid giving your employees a separate username and password for accessing Office 365, and so it makes sense to use the already known username and password in Active Directory. Again there are some free tools from Microsoft that can help you achieve this, but they lack important features and often force you to make compromises. While Microsoft is building a wonderful new cloud platform, they are reusing aging legacy technologies to provide the critically important connection to your existing employee information. 2

BYOD And Office 365 The migration challenge moves beyond just identity when you look at how people access Office 365. In the older on-premises world, most clients for Exchange, SharePoint and Lync were Windows desktops. With a few mobile devices accessing email. But today, with the cloud, that shift has moved significantly to mobile devices. Phones and tablets. ios and Android. So how do you easily enable access to the newly created Office 365 accounts? Mobile devices are typically in addition to a laptop or desktop. People also configure access to email on more than one mobile device, such as a phone and a tablet. What happens when the user is forced to change their password, for example per a 90 day password change policy, and they have two mobile devices and two laptops that will try and authenticate with the old password? Generally, the answer is a locked account and a call to the IT helpdesk. At the end of this document, once you understand the challenges around the identity migration to office 365, I will look at the impact of mobile devices. But first, let s focus on the identity challenges. Active Directory And Years Of Use And Abuse Active Directory is at the center of IT infrastructure for many businesses today and for many, it was the first major piece of IT infrastructure implemented. Most on-premises applications use Active Directory in some way. As a place of authentication, policy or just storing/retrieving information about users and their group membership. Active Directory deployments grow in both the number of domains and also forests. This happens naturally as the business expands, especially when businesses make acquisitions. Move forward three to four years and you soon find that Active Directory can be a wasteland of information. You end up with situations like: Some users have missing information. Users created in Active Directory may rely on manual human process and people might forget to fill out department names or use the right username format. With multiple forests created by different IT groups, usernames and format of fields like department or displayname can vary significantly. It is possible to have network connectivity between Active Directory environments that allow for cross forest trust and authentication. But often forests reside in data centers with little to no network connectivity between them. Sometimes resource forests are created which duplicate every employee account and are used to only own things like Exchange attributes (email address for example) while another user forest has all the other import user attributes like Firstname and Lastname. This means the complete picture of the user account is spread across many Active Directory domains. 3

These sorts of issues present real problems when trying to migrate to Office 365. Typically you want to have all the users in Office 365 up to date with accurate information and have users login with usernames and passwords they are familiar with. When Active Directory has inconsistent data and incompatible configuration, most customers are asked to clean up AD or go through a painful and time consuming domain consolidation. This creates a barrier to the migration and adoption of Office 365. One thing worth mentioning is that today it is not viable for most businesses to replace on-premises Active Directory with a cloud equivalent. Moving the entire services of something like Exchange to the cloud is possible with Office 365, but replacing the entire Active Directory environment with a cloud service is not possible for a lot of people. There are too many on-premises systems, with no cloud hosted equivalent, which rely on Active Directory. Before we continue, we should also note that Microsoft has made a lot of changes to the names for its software used to connect Active Directory to Office 365. The free out of the box tool for synchronization is most commonly known as DirSync, but in 2014 was changed to AADSync. Microsoft is going to change the name again in 2015 to Azure AD Connect, which in reality is just a new installer that can deploy and configure both AADSync and ADFS. All of these software versions are actually based on a single, 10 year old technology called Microsoft Identity Integration Server (MIIS). DirSync, AADSync and Azure AD Connect also leverage functionality from MIIS s bigger brother, Microsoft Identity Manager (MIM), formerly known as Forefront Identity Manager (FIM). The DirSync, AADSync and Azure AD Connect software is specifically limited for Office 365 and prepackages some of the MIM capabilities. Confused? It can be very difficult to understand what all these versions do and which one to use. Microsoft is trying to make it simpler and has created the following page to attempt to clear things up. https://msdn.microsoft.com/en-us/library/azure/dn757582.aspx. For reasons of simplicity in this article when we are talking collectively about the DirSync/AADSync and Azure AD Connect solutions, we ll call them the DirSync family, otherwise we will be explicit in which one we are talking about. How do you migrate your many users to a single Office 365 deployment? bgates@company.local? satya.nadella@company.com markus.persson@company.com firstname.lastname@company.com 4

Understanding Solutions To Manage Authentication We ll start with authentication and then cover synchronization in the next section. Authentication for Office 365 with the Microsoft tools can be done in two ways. 1. Federate the authentication from Office 365 back to your Active Directory 2. Synchronize the password hash for the user from Active Directory into Office 365 The first method uses Active Directory Federation Services (ADFS) which requires you host a login page in your IT environment for authentications to Office 365. This page then takes credential information (usually username and password) from the user, and verifies them against Active Directory in real time. The second approach uses the directory synchronization tools to copy the Active Directory password hash into Office 365. There are pros and cons with each and the following section gives further insight into the areas where these two approaches differ. Lots of servers with lots of configuration Diagram showing using ADFS for Office 365 federated authentication Active Directory Federation Services (ADFS) Load Balancer/Proxy Active Directory Federation Services (ADFS) Load Balancer/Proxy A single server for all the connectivity to Office 365 Diagram showing using the DirSync family of software for password sync to Office 365 Azure AD Connect 5

Note with both of these solutions you need to procure dedicated servers and your IT team will need to be skilled in certain aspects of identity management such as federation and PKI. So that is the first con, the fact that when moving from your on-premises services to Office 365, you may end up adding more servers in your IT infrastructure. Microsoft is however offering free services to customers to setup these tools on virtual machines in Azure, which can alleviate the initial costs, but still presents a challenge with long term maintenance and management. Moving ADFS into Azure as VMs usually also means you move your Active Directory domain controllers as well. Not an easy or cheap task to accomplish. Let s take a look in detail at the differences between using federation with ADFS and synchronizing the Active Directory password hash. Required On-premises Infrastructure For Authentication While it is possible to use just a single ADFS server, Microsoft recommends against this for production. At a minimum you will need to deploy two ADFS servers and the required network proxy/load balancing solution, which often requires another two dedicated servers. The pro here is that ADFS can be scaled very well, simply add more ADFS servers into the farm and scale up your network infrastructure appropriately. The downside is that you have to deploy quite a bit of infrastructure and make network architecture changes. At least two to four servers and opening ports in the firewall. Sometimes you need network routing changes and new networking equipment. You also have to manage SSL certificates and the configuration of ADFS requires specialist identity knowledge. I ve seen one customer with many disconnected Active Directory domains and they faced the challenge of hosting upwards of 30-40 ADFS servers. Because customers moving to Office 365 in the cloud are reluctant to deploy the on-premises infrastructure required by ADFS, Microsoft is starting to recommend using password sync. The older DirSync can sync your AD password to Office 365, but the newer AADSync can also sync the Office 365 password back to AD. The pro is that you only need to deploy one new server, not the many servers required by ADFS. But this pro, is also a downside. You can t scale this server. You can t even run another active server for backup or load balancing. So that s one server for your entire Active Directory connection to Office 365. That single server needs network connectivity across all the Active Directory domains where you want to sync passwords. If something goes wrong, Microsoft suggests rebuilding the entire server. That means making sure you have change control and a backup process to ensure you always have the latest configuration. These are the common problems with running legacy on-premises technology. 6

High Availability And Scale As I mention above, ADFS is designed to be scaled. You can deploy ADFS in farms of servers and deploy SQL server to even further stabilize the service. This allows ADFS to support authentication for any number of domains / forests, even when the forests are not connected / trusted, you deploy more ADFS servers. While this is a great benefit, the downside is that you need to maintain and run all this infrastructure. When migrating to Office 365 you are usually trying to reduce your on-premises IT footprint. DirSync on the other hand is a single server. For a simple single forest and single domain environment, it often satisfies. Where it starts to present problems is when you need to sync passwords from many different forests and domains. The latest version, AADSync, does support multiple forests, but that single server now needs reliable network connectivity between all of these domain locations. If the forests are not connected, a customer must look to DirSync s older brother, Microsoft Identity Manager (MIM). The problem here is MIM doesn t support the same password sync as its little brother DirSync. So you can only use MIM with ADFS. A Closer Look At Password Synchronization And Authentication Options It s worth looking in detail at the pros and cons of using the DirSync family of tools to synchronize your Active Directory password hash into Office 365. When using federation with ADFS, the servers are connected directly to your Active Directory domain. This is in turn connected to the internet via your network proxies and load balancers. So when someone attempts to authenticate to Office 365, they authenticate to ADFS and it checks the users credentials in real-time. If the Active Directory password doesn t match or the account is disabled, they can t login to Office 365. Federation is core to the whole direction the single sign on industry is taking. However, as ADFS is based on a legacy on-premises architecture, it incurs high costs to deploy and maintain. So Microsoft is recommending in a lot of cases to use the DirSync family of tools. They copy the password hash from your Active Directory into Office 365. Note Active Directory doesn t store the actual password, it stores a cryptographic hash. With DirSync this hash is then secured with another secure hash, so you are not storing the plain text Active Directory password in Office 365. 7

The sync from Active Directory to Office 365 happens whenever a password is changed or a new user created. This means the authentication actually takes place in Office 365. This approach, which uses a single server, addresses the problems of deploying lots of ADFS servers, but the downside is the delay between changes in Active Directory and the sync to Office 365. Note that when the password is changed in Office 365 and synced to Active Directory, it happens in real time. So the following concerns are all about taking changes from Active Directory and synchronizing them to Office 365. The delay in synchronization is different for two main areas where authentication is concerned. 1. The sync of the password from Active Directory to Office 365 can take up to two minutes and is not configurable. 2. The sync of an accounts status and group membership is three hours by default. This can be lowered but it is not recommended to have it running below 30 minutes. The two minutes time window for password syncs is critical. Many users who are changing passwords, expect to login within seconds, not minutes. Consider the scenario where your Active Directory is configured with a 90 day password change policy. A user is forced to change the password in on-premises AD, then they are likely to attempt to login to Office 365 within a two minute time window. When they can t login, they often think they made a mistake in changing their password and go back to their Active Directory account and change their password again. They can get caught in a loop of changing passwords which results in an IT helpdesk call. The whole point of this password sync is to avoid helpdesk calls. Password change Every 2 minutes (Not Configurable) Azure AD Connect Active Directory User / Group change Every 3 hours by default 8

The second area of concern is around data on the user account that affects access to Office 365. If the Active Directory account is disabled or deleted due to an employee leaving the company, that change isn t reflected into Office 365 for at least 3 hours (by default). So users can still access Office 365 even after their Active Directory account is no longer valid. This can be avoided by an IT administrator manually disabling the account in Office 365. If you are also using groups from Active Directory to determine access to Office 365 resources, these group changes are also delayed by 3 hours. Using ADFS would solve the problem of the Active Directory account being disabled or deleted, because it checks Active Directory in real time. However ADFS doesn t solve a problem of delayed group membership synchronization. Another complication in deciding how to do authentication is that if your deployment to Office 365 requires Microsoft Identity Manager (the reasons for are discussed in the next section), then you cannot implement password synchronization either from AD to Office 365, or vice versa. You have to deploy ADFS. This presents a problem for customers who need to use MIM for complex Active Directory environments but also wish to avoid the extra burden of an ADFS installation. Authentication Summary In summary, there is no right answer for what Microsoft technology to use for Office 365 authentication. You either take on the deployment and maintenance of many ADFS servers, or you reduce your effort and take on the risk of running a single server to keep your passwords up to date for all Office 365 users. Either way, you have to compromise. Understanding Solutions To Synchronize Identity Data Before you can even authenticate and access Office 365, you need to create user accounts. This is the role of the synchronization solution. While Microsoft is building a brand new and modern cloud platform for Office 365, the technologies offered to connect to Active Directory are based on 10 year legacy solutions. The first incarnation was known as Microsoft Identity Integration Server (MIIS) and has evolved through many rebranding s. But essentially these tools rely on the same legacy on-premises architecture that is a big metadirectory which stores both user and group information from Active Directory and Office 365, as well as your business logic which determines how Active Directory is connected to the cloud. There are two main solutions for synchronizing data from Active Directory to Office 365. The free DirSync family of tools or its bigger brother, Microsoft Identity Manager (MIM). The following section digs into the detail of the pros and cons of using either of these solutions. 9

Synchronize User And Group Data From One Or Many Domains And Forests When you have just one domain in a single forest, DirSync, AADSync or the new Azure AD Connect is an easy way to connect your Active Directory to Office 365. The challenges start when there is more than one domain or forest or if your data in that single domain isn t consistent. For example you might have users with a variety of login names and the email address may not be consistently entered across all accounts. Multiple forests and domains present problems due the need to often read identity data across all domains. The recently updated AADSync now supports the ability to read from multiple forests unlike the earlier versions called DirSync. Active Directory Infrustructure HQ forest & domains IT DMZ Europe forest & domains Azure AD Connect Acquired company forest & domains The downside with using the DirSync family of tools is the limitation of a single sync server for your entire Office 365 environment. A company with many domains or forests that may be separated over different networks put strain on the single server. MIM is the bigger brother for the DirSync family of tools, but instead of being a quick and easy way to connect Active Directory to Office 365, MIM is a fully featured on-premises identity management product that can take months to deploy. MIM allows for more control over connecting to domains and forests in different locations. I ve actually heard of customers deploying multiple instances of MIM, all talking to a single master MIM instance that then connects to Office 365. The downside of this approach is the significant on-premises infrastructure that MIM requires. A common deployment consists of two MIM servers, two database servers and IIS servers for self-service password reset functionality. 10

Other Sources Of Identity For Office 365 Accounts Sometimes you want information in Office 365 to come from places other than just Active Directory. For example an employee s phone number might actually be better synchronized from your Cisco Unified Communications service. You might also have information in another directory service like LDAP. The entire account might come from LDAP, or you might have most information in Active Directory but just want to get employee ID from LDAP. You may want to provision accounts to Office 365 from a mix of directories. You want employees to come from Active Directory, but contractors might reside in LDAP or an SQL database. Information doesn t just come from on-premises systems, many people are moving their HR systems to the cloud and leverage services like Workday and UltiPro, and want to source user data from these applications. While DirSync and AADSync are built on a technology that can connect to these other sources of identity, these prepackaged tools do not currently support multiple sources (other than multiple Active Directory domains). Microsoft is adding LDAP to Azure AD Connect at some point in the future. But it is unclear how much flexibility is going to be added to this free tool. MIM really is the best solution from Microsoft if you have to get information from places other than Active Directory. MIM allows you to connect to a wide variety of sources, mix up the data and then provisioning it all to a common user profile to Office 365. The downside to using MIM however is that, unlike the DirSync family of tools, which can be deployed in under a day, most MIM deployments require a lot more effort. Typically at least a month of planning and implementation, and then it requires a lot of ongoing maintenance and configuration. However you can integrate MIM with whatever you want, it is just a question of skills, time and money. This does introduce yet another problem to consider. Building out a solution with MIM results in you developing important business logic in an on-premises system that isn t part of the same cloud platform you are trying to move to. So you can end up managing custom code, and duplicating your business logic. Writing rules in MIM and then recreating the same rules in the cloud, further complicating your efforts to move to cloud services. Transform / Normalize User Attributes In many scenarios a percentage of the data in Active Directory doesn t always match what you want in Office 365. A common example is IT departments that created Active Directory domains where the user domain isn t publically routable. You might have user@company.local usernames. Moving to 11

Office 365 requires that usernames leverage public DNS domains, so you need user@company.com. Often the answer is just to add the new domain name to your Active Directory and tell everyone they have a new username. In practice this isn t a good solution, such sweeping changes to Active Directory can cause all sorts of problems with existing on-premises software. You want to migrate to Office 365 without having to go through a lengthy Active Directory cleanup or consolidation exercise. The DirSync family of tools do allow for the manipulation of attributes like username. With the older DirSync there wasn t a supported method and customers had to go unsupported and hack in any changes. With the recent release of AADSync, Microsoft exposed a supported ability to edit the rules but they are still limited. If you have more than one domain, with different requirements for username formats in each, you can quickly get lost building your identity logic in a legacy on-premises platform. For complex, multi forest and multi domain environments or if you just need to fix up the data in Active Directory before it gets to Office 365 without actually making large changes to the directory itself, then Microsoft will recommend MIM. This usually requires getting an identity consultant / partner to help you deploy, unless your IT organization has experience in implementing identity management solutions. However this flexibility comes at a cost. MIM is a legacy, on-premises technology which means you deploy and manage new on-premises servers. All your business logic around the creation and management of users in Office 365 is embedded in an on-premises solution. None of this logic resides in the cloud, which is where you are moving the rest of your on-premises solutions. If you are using Azure Active Directory with MIM, you will find you are configuring and maintaining two very separate identity management solutions. Microsoft call this hybrid identity and it can be a costly solution. In summary there is no perfect answer to which Microsoft tool do you use for your synchronizing your Active Directory data to Office 365. It s a balance of ease of use and limitations of flexibility with the DirSync family of tools compared with the flexibility of ADFS and MIM and their significant on-premises infrastructure requirements and time, effort to deploy. Mobile Device Access To Office 365 Now consider that you ve got a grasp of the above, made your choices and you ve configured authentication and synchronization from your on-premises environment to Office 365. You ve migrated your data and you are ready to go. But how do users now successfully access these services? On the Windows desktop many users will be familiar with the Office suite on the desktop. Those who had Outlook configured for the on-premises Exchange server will be automatically migrated to Office 365. If they were familiar with accessing Exchange via Outlook Web Access, they simply now head to https://portal.office.com and login as normal. 12

But what about their phones and tablets? This is a little trickier. Microsoft has made huge strides towards bringing Office 365 native applications like Word, Excel and PowerPoint to Apple s ios and Google s Android devices. Exchange Active Sync, which not only handles access to email but also a user s contacts and calendar, is available in the native email clients for ios and Android. But configuring all these and knowing which Office apps the user has access to, is manual and incumbent on the user making the right choices. Mobile devices can also be less secure. Microsoft has started to add some mobile device management (MDM) capabilities to Office 365, specifically Exchange. This allows you to setup some basic policy over the device passcode, encryption and conditional access to data. But the features are limited and do not allow control over the download and sharing of data from Office 365 with other, less secure collaboration or file storage apps. Another problem is passwords. When you have several devices all configured for Office 365 email and other services, and the password for that Office 365 account is tied back to Active Directory. How do you ensure the right password is stored on the mobile device? What happens when you update the password in Active Directory? Often those mobile clients continue to access Office 365 with older passwords which can result in locked accounts for the user. Conclusion Migrating to Office 365 can be a complex undertaking. Microsoft s tools are one option for handling the identity and mobility management challenges, but they fall short in several ways. They also force you to rely on legacy technology at the same time you are adopting the newest technology in the cloud. Okta has taken a fresh approach to solving the integration challenges associated with cloud and mobile applications, including Office 365. Okta is built on a reliable, cloud-based architecture that helps businesses avoid the many pitfalls outlined above. Okta is trusted by more than 2,000 organizations, including those migrating to Office 365. Businesses such as Seton Hall, DocuSign, Girl Scouts and Post Foods have improved security and driven end-user adoption with Okta and Office 365. Learn how in our Office 365 Learning Center at www.okta.com/product/office365. 13

This TechGuide was authored by Simon Thorpe who has been active in the identity and security technology industry for over 15 years. Before joining Okta, Simon worked for Oracle and Microsoft, helping customers with a variety of challenges securing their users and data. He has also contributed chapters on data security to the book "Information Security: The Complete Reference, Second Edition". Simon's role at Okta is about understanding customer needs and helping Okta product management deliver the best solution possible for securing access to Office 365. 14