Okta - Office 365 Deployment Guide

About this Guide

This Deployment Guide contains a significant amount of information due to the complexity often involved in migrating from existing on-premises Office services (Exchange, SharePoint, Skype for Business) to the Microsoft Office 365 cloud platform. We suggest you first scan through the document to understand the overall tasks, then read in detail the areas that apply to your deployment.

We strongly recommend that you contact Okta Professional Services before you continue with this deployment.

Microsoft Office 365 Overview

Office 365 is Microsoft’s cloud offering targeted at organizations using services such as Office, Skype for Business, Yammer, Exchange, and SharePoint. Office 365 aims to reduce the on-premises footprint previously required to run these services. Microsoft is recreating these services in the cloud building upon Azure services including Azure Active Directory (AAD), a cloud-based user and group directory that provides authentication, and user/group/device management services for Office 365.

For end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control., sending email, creating documents, and chatting with co-workers in Office 365 is almost identical to using the same services in your on-premises data center. The difference in Office 365 is that the need for IT to manage a large farm of servers for Exchange, Skype for Business, and SharePoint is eliminated. Traditional applications such as Word and Excel are also being rewritten to run entirely in your browser using Azure cloud.

Deploying Office 365 using Okta

Okta is designed to minimize the on-premises footprint while maximizing the advantages of cloud infrastructure. Utilizing Okta for Office 365 has allowed organizations around the world to solve complex deployments that would take months with legacy Microsoft technology. In many cases, Okta can replace ADFS and Azure AD Connect (formerly DirSync) for directory synchronization. It achieves this using a lightweight agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. that can be installed on existing Windows servers in your domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https).. This same agent is used for synchronizing data from AD to Office 365 as well as delegating authentication back to AD as part of a federated single sign-on. Okta’s directory integration agents can also read and write user and group data from AD and other LDAP servers.

For more information on AD integration with Okta, see Install and configure the Okta Active Directory (AD) agent

Okta’s Integration for Office 365 offers:

Step-by-step Instructions to Deploy Office 365 in Okta

  1. Supported Architectures for Office 365 Deployment
  2. Design Office 365 Deployment
  3. Configure Office 365 Domain
  4. Assign Office 365 to Users
  5. Integrate Office 365 App Using WS Federation
  6. Provision Users in Office 365
  7. Switch on Office 365 Provisioning
  8. Assign Office 365 Licenses and Roles
  9. Manage Office 365 Users Using Powershell
  10. Import Users from Existing Office 365 Tenant
  11. Import Groups from Active Directory to Office 365 through Okta

Optional Tasks