Keep this in mind when integrating Microsoft Office 365 in Okta

The Microsoft Office 365 integration is the most used from Okta's integration network. Due to the importance of the integration, and how Office 365 works, we have described some things that are worth keeping in mind when implementing Office 365 with Okta.

Andreas Faltin
14. September 2021

Andreas is a cloud architect in Cloudworks and an Okta Technical Champion. He is helping customers on their digital Identity journey by designing and implementing complex IAM solutions. These have a high amount of automation to achieve high impact with minimal user friction.

The list below are not intended as a substitute for Okta's already full documentation of the Office 365 integration. Our intention is simply an added perspective based on our experience from the field.

1. It's not just Office 365

When planning the integration of an (existing) Office 365 environment with Okta it is important to be aware that Office 365 is only one part in the game that might be affected by the setup. Azure AD is the identity store for Office 365, so integrating Office 365 is likely to affect Azure AD services that are not connected to Office 365.

For example, a user of an Azure Enterprise Application will from the time that the Office 365 account is federated with Okta, also have to log in to that application with the Okta account. Azure AD will act as a Service Provider in this example, and there is usually no problem with this, but it’s important to be aware of the impacts and changes when moving SSO to Okta.

In addition to that, any on-premises Active Directory that is connected in any way to Okta and/or Office 365 needs to be considered. Whether Office 365 is connected to AD via AzureAD Connect or not there are some options unavailable when it comes to provisioning.¹

¹ Link to the provisioning scenarios in the Office 365 integration: https://help.okta.com/en/prod/Content/Topics/Apps/Office365/References/provisioning-types.htm

2. Federation is based on login domain

The activation of federation (SSO) in the Office 365 integration has a wide impact on user accounts in Office 365 and Azure AD. Federation in Azure AD works based on a domain-level. Meaning, once federation is activated for – for example custom.domain – all users with the UPN of <name>@custom.domain will be federated to the IDP, in this case Okta.

Okta-Office365 Figure 1 - AzureAD domain settings example. One federated domain and two “managed”, meaning it is not federated.

For regular Office 365 users that is of course planned and usually those users already exist in Okta. But given the nature of Office 365 and Azure AD this also applies to users that may not even be in Office 365 but exist in Azure AD with the same custom domain as the username, such as technical, external (not guest users) or admin accounts. So before activating SSO in the Okta Office 365 app it is important to go through all users in Azure AD and check if they exist in Okta and – if they don’t – either onboard them or change their username to a domain that is non-federated, for example the standard “<company>.onmicrosoft.com”.

3. It is important to import, but only once

In most scenarios the integration of Office 365 into Okta is not of a new tenant, but an existing – already configured and grown - Office 365 tenant. Parts of the configuration and information that are in Office 365 should be imported into Okta. That is up and foremost the license setup of each user to ensure that once provisioning is enabled the users are not faced with licenses being removed from their Office 365. But also the linking of an user account in Okta and O365.

There is, however, one very important point to consider: Import from Office 365 to Okta is a one-time only, on-create process. Any information that is changed directly in Office 365 after the import will not be transferred to Okta, even if there is another import job in the meantime. The solution to this issue is to remove the user from the Office 365 app in Okta (make sure all provisioning options are disabled) and import and confirm the user once more.

4. Import only captures basic attributes

Importing users from Office 365 that did not exist in Okta before, does not include all attributes that are included when you sync a user the other way, from Okta to O365. Okta can synchronize an extended set of around 20 attributes with “user sync” or even more with “universal sync” enabled.

However, the other direction Office 365 -> Okta will always be just the 4 basic attributes FirstName, LastName, email address, username. In case there is more information that needs to be imported from Office 365 to Okta this must be provided by either a CSV Import (make sure to use UTF-8 for special characters) or other mechanisms, like a Powershell script and API calls.

² Available attributes for synchronization: https://help.okta.com/en/prod/Content/Topics/Apps/Office365/References/O365_Supported_User_Attributes.htm

5. Conclusion

There are some things to be considered when connecting Office 365 and Okta. None of these are road blockers usually, but it is important to be aware of and accommodate them to avoid unpleasant surprises during the implementation. To make sure, it’s best practice to go through the implementation in a test & Oktapreview environment first before doing changes to any of the production environments.

If you do not have an Office 365 test environment, Microsoft offers free, time-limited Office 365 tenants through its Office Developer program. These tenants also have sample packs available with a bunch of example users and data.