Design Office 365 Deployment

Okta’s Office 365 integration provides several key capabilities:

  • Provide Single Sign-On by means of Federation using WS-Federation and WS-Trust to web clients, rich clients and email-rich clients in a manner fully supported by Microsoft
  • Provisioning user and group data from Active Directory to Office 365 and assigning licenses
  • Enable Multi-Factor Authentication for Web Clients and supporting desktop applications Okta’s provisioning functionality has a number of key capabilities that are detailed below.

In cases where you have moved completely to Exchange Online, Okta can perform full synchronization of objects and attributes between AD and Office 365, without the need for any additional deployments such as AADConnect. In circumstances where Exchange is currently, or expected to be deployed in a Hybrid Configuration with Exchange Online, it is recommended to deploy Microsoft synchronization technologies to synchronize data into Office 365 and leverage Okta to perform granular role and license management. It is important therefore to understand how Okta can work alongside Microsoft solutions.


Large-scale organizations often have complex infrastructure, with differing technology needs and perspectives. For this reason, you may find that Okta is deployed alongside various federation technologies such as Microsoft ADFS, Ping or Oracle Identity Federation (OIF).

Note: If you have an existing SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. solution for Office 365, and are planning to move to Okta for SSO, be sure to document any customized settings in your configuration. Examples of such configurations could be utilizing an attribute for username that is non-default (User Principal Name is the default value here, however common other settings are Email or EmployeeID). These settings will need to be reconfigured in Okta when configuring Single Sign-On.

Directory synchronization

Okta’s 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. architecture allows it to reside in the same environments as other federation technologies. Large organizations can have a complex mix of identity related technologies. Often you will see multiple Active Directory forests and more than one identity management solution running between them and other directories and applications. Okta’s lightweight presence in the data center allows it to be deployed alongside existing identity management solutions.

It is important to note that if another technology is performing the synchronization of accounts to Office 365, and Okta is handling the federation for authentication, you need to ensure the Okta account usernames match the Office 365 usernames. This can easily be configured in Okta using Universal Directory attribute expression, this is described later in this document.

During migration to Office 365, some organizations find the need to instantiate an Exchange Hybrid configuration. in doing so, it is likely that you have one of Microsoft’s technologies performing part of the directory synchronization, DirSync, AADConnect or Forefront Identity Manager (FIM). Whilst in these Hybrid deployments, Okta cannot replace the need for these tools and instead can be used directly alongside for single sign-on and role and license management.

Note: If you are currently using AADConnect or another synchronization solution and plan to move to Okta Provisioning, be sure to document any customized settings in your configuration. Examples of such configurations could be utilizing an attribute for username that is non-default (User Principal Name is the default value here, however common other settings are Email or EmployeeID). As well as the attribute for sourceAnchor (also known as ImmutableID). It is recommended to discuss with Okta Professional Services prior to making such changes.

Universal Directory and Office 365

Advantage of using Okta with Office 365, include rapidly accelerated deployment times without the need to deploy complex on-premises services and increase the overall infrastructure footprint. The ability for Okta to do this is provided by our powerful cloud directory called Universal Directory.

Universal Directory can be described as a rich Metaverse in the cloud, it enables you to:

Universal Directory with Office 365 provides you full control over username transformation, email address formatting (per 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). or even per-user). This document describes the areas where you can use Universal Directory, but for a full understanding of its capabilities, refer to About Universal Directory.