Microsoft Office 365 Deployment Guide

Overview

This guide provides the information to configure Office 365 in your Okta orgThe Okta container that represents a real-world organization.. Depending on your license type, some topics in this guide may not apply to you.

Prerequisites

The following permissions and accesses are needed to deploy Microsoft Office 365.

Microsoft Office 365

Requirement Description
Office 365 tenant name This is the tenant that you want to integrate. This is your default Microsoft 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). in yourtenant.onmicrosoft.com format.
Office 365 domain This is the domain that you want to federate. Ensure this domain resides in the above tenant.
Office 365 Global Administrator credentials Okta uses these credentials for API integration. Ensure the administrator resides in the above tenant.

Okta

Requirement Description
Super AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. permissions To ensure that you can perform all steps in this guide.

Procedures

1. Add Office 365 to Okta

2. Choose the next step

3. Provision users to Office 365

4. Configure Single Sign on

5. Assign Office 365 to users and groups

6. Secure Office 365 using app sign-on policies

7. Add-on tasks

8. Frequently asked questions

 

1. Add Office 365 to Okta

You can add the Office 365 app in your Okta org from the Okta Integration Network (OINAn acronym for the Okta Integration Network. The OIN is comprised of thousands of public, pre-integrated business and consumer applications. As an on-demand service, OIN integrations are continuously validated, always up to date, and constantly growing both in number and capability. Okta performs a single integration with an ISV or SP, providing thousands of end users with point-and-click customization for their orgs.).

  1. Log in to your Okta org with Super Admin credentials.
  2. Go to Applications > Add Application.
  3. Search and add Microsoft Office 365.

    The Add Microsoft Office 365 page appears.

  4. In General Settings, enter your Microsoft tenant name and Office 365 company domain.

    Note

    • For Microsoft tenant name, enter only yourtenant part of yourtenant.onmicrosoft.com.
    • For Office 365 domain, enter the complete domain.

     

  5. Click Next.

    Sign on Options tab opens.

  6. Without changing anything on the Sign on Options tab, click Done.

 

2. Choose the next step

 

3. Provision users to Office 365

You can create, update, and deprovision users in Office 365 from your Okta org. You can import users from different source directories into Okta and provision them in Office 365 using profile mappings.

Prerequisite

Bring users in Okta

You can import users from a directory such as Active Directory (AD) or an app such as Salesforce. You can also create users directly in Okta. See the following for more information.

 

1. Decide type of provisioning

Depending on your provisioning needs, you can select one of the following provisioning types.

  Operations supported Provisioning types
Licenses and Roles Management Only Profile Sync User Sync Universal Sync
Provision Users
Push licenses and roles Y Y Y Y
Create user N Y Y Y
Deactivate user Y Y Y Y
Edit user directly from within Office 365 Y(a) Y N(b) N(b)
Sync profile attributes(c)
Sync basic user profile attributes N Y Y Y
Sync limited number of extended attributes in addition to the basic attributes N N Y Y
Sync all extended attributes N N N Y
Sync AD groups and resources(d)
Sync security groups N N N Y
Sync contacts N N N Y
Sync distribution lists N N N Y
Sync resource mailboxes N N N Y
  1. Not available with Azure Active Directory Sync or Directory Synchronization.
  2. Users can no longer be edited directly from within Office 365. Changes must occur at the source of truth and be synced across.
  3. For more information, see Supported user profile attributes for Office 365 provisioning
  4. To sync groups from other directory services and apps to Office 365, configure Group Push. You must first configure provisioning and user assignments before pushing groups to Office 365. For more information, see Using Group Push.

 

Warning

  • User Sync and Universal Sync cannot be used with DirSync, Azure Active Directory Sync, or Azure Active Directory Connect.
  • Once you select User Sync or Universal Sync, you can not modify your selection back to Profile Sync.

 

2. Set up Okta → Office 365 provisioning

You can automate provisioning tasks by enabling API integration and configuring settings for different user life cycle stages.

2.1. Enable API integration

Office 365 requires a token to authenticate against the Microsoft API. This allows Okta to implement provisioning in Office 365.

  1. Go to Office 365 > Provisioning > API Integration > Configure API Integration.
  2. Check Enable API Integration.
  3. Enter your Office 365 Global Administrator credentials.
  4. To import groups now, check Import Groups.

    You can import groups later after finishing provisioning. For more information, see Skip importing groups during Office 365 user provisioning.

  5. Click Test API Credentials.
  6. Save the credentials once they are verified successfully.

2.2. Select provisioning type and settings

Depending on the provisioning type you select, you can select provisioning and deprovisioning settings.

  1. Go to Office 365 > Provisioning > To App > Edit.
  2. Select Office 365 Provisioning Type.

    For more information about provisioning types, see Provisioning types for office 365.

    For Universal Sync only: Check Send full profile, contacts, and conference rooms from these AD instances if you want to sync AD groups and resources.

  3. Enable or Disable other provisioning settings. For more information, see Enabling Enhanced Provisioning.
  4. Click Save.

 

Note

Enabling Sync Password in Provisioning settings is useful in the following scenarios:

Syncing passwords is not necessary when Office 365 uses WS-Federation for single sign on, as users use their Okta credentials to access Office 365.

 

3. Map profile attributes Okta → Office 365

Depending on where your users are mastered, the username format can vary. For users to successfully sign into Office 365, their username for Office 365 must be in an email address format for the domain you are federating (username@yourfederated.domain).

 

Map username as-is

If your users already have their usernames in an email address format for the domain you are federating (username@yourfederated.domain) format, you can map the email as-is.

  1. Go to Office 365 > Sign on > Edit.
  2. In Credentials Details > Application username format, select Email.
  3. Click Save.

 

Map custom username

If your users are mastered in different directories or apps, their username format may vary. You can use Okta expression language to customize the username that will be passed on to Office 365.

  1. Go to Office 365 > Sign on > Edit.
  2. In Credentials Details > Application username format, select Custom.
  3. Enter this expression in the provided text box.

    String.substringBefore(user.email, "@") + "@yourfederated.domain"

  4. Replace yourfederated.domain with the domain you are federating.
  5. Enter an Okta user in the Preview box to check the result of the mapping.
  6. The resulting username should match the Office 365 username for the user.
  7. Click Save.

 

Map email address

If your users’ email addresses do not reside in the domain you are federating, you can use Okta expression language to customize the email address that will be passed on to Office 365.

Prerequisite

Provisioning type should be selected to User Sync or Universal Sync.

  1. Go to Directory > Profile Editor > Microsoft Office 365 Mappings > Okta to Microsoft Office 365.
  2. In source.email field, enter the expression:

    String.substringBefore(user.email, "@") + "@yourfederated.domain"

  3. Replace yourfederated.domain with the domain you are federating.
  4. Enter an Okta user in the Preview box to check the result of the mapping.
  5. The resultant email address should match the Office 365 email address for the user.
  6. Exit Preview and save mappings.
  7. Click Apply Updates Now.

 

4. Test provisioning

Ensure you have correctly configured provisioning by assigning Office 365 to test users in Okta and verifying they appear in your Microsoft tenant.

Prerequisite

Create Users option in Provisioning must be checked..

 

In Okta,

  1. Open Assignment tab of the Microsoft Office 365 app.
  2. Click Assign.
  3. Assign appropriate Office 365 licenses to test users.
  4. Click Done.

In Microsoft Admin Center,

  1. Open the list of Active Users.
  2. Ensure all test users appear in the list with appropriate licenses.

In Okta,

  1. Log into Okta as a test user.
  2. Ensure all Office 365 apps appear on the user dashboard.

Note

If you have selected User Sync or Universal Sync provisioning type, all users irrespective of their profile mastery, appear as Synced with Active Directory in the Office 365 tenant. However, the user is still mastered at the source directory.

 

4. Configure Single Sign on

You can enable users to sign into Office 365 using Secure Web Authentication (SWA) or WS-Federation.

SWA is a single sign-on method developed by Okta. It stores the end-user credentials using strong encryption combined with a customer-specific private key. When the end-user clicks the app chiclet, Okta securely signs them in using the encrypted credentials. .

WS-Federation defines mechanisms to transfer identity information using encrypted SOAP messages. It does not require a separate password for Office 365.

We recommend using WS-Federation because it is more secure than SWA and provides enhanced user experience.

 

Configure Single Sign on using Secure Web Authentication

You can enable users to sign into Office 365 using either SWA or WS-Federation. When possible, use WS-Federation because it is more secure than SWA.

  1. Go to Office 365 > Sign on > Settings > Edit.
  2. In Sign on Methods, select Secure Web Authentication.
  3. Select appropriate option for username and password setup. For more information, see About SWA Apps.
  4. Map username format as explained in Provisioning users, section 3. Map profile attributes Okta → Office 365.
  5. Click Save.

 

Configure Single Sign on using WS-Federation

There are two ways of configuring WS-Federation: automatic and manual.

You can allow Okta to automatically configure WS-Federation or you can manually configure it using customized PowerShell script provided by Okta.

Configuring WS-Federation automatically is recommended because Okta takes care of the back-end procedures.

Federation settings take approximately two hours to be applied across the system.

 

Configure Single Sign on using WS-Federation - automatic method

  1. Go to Office 365 > Sign on > Settings > Edit.
  2. In Sign on Methods, select WS-Federation > Let Okta configure WS-Federation automatically for me.
  3. Enter your Office 365 Global Administrator username and password.

    Your Office 365 Global Administrator username and password for WS-Federation are pre-filled if you have provided them while setting up provisioning.

  4. Click Save.

 

Warning

Ensure your administrator credentials for the Office 365 are NOT in the domain you are federating.

This will lock you out of the Office 365 domain. You won’t be able to authenticate yourself in Microsoft 365 Admin Center as you have to authenticate through Okta, where you will be treated as a user, not as an admin. Ensure you are using administrator credentials for an account that is on your default Office 365 domain. This domain is by default yourtenant.onmicrosoft.com.

 

Configure Single Sign on using WS-Federation - Manual method

You can user PowerShell to manually configure WS-Federation. You can fetch your current domain settings by using Get-MsolDomainFederationSettings -DomainName yourdomain.name before you begin the federation procedure.

  1. Go to Office 365 > Sign on > Settings > Edit.
  2. In Sign on Methods, select WS-Federation > I want to configure WS-Federation myself using PowerShell.
  3. Open Setup Instructions for the PowerShell command customized for your domain.
  4. Copy this command for use in PowerShell.

In PowerShell,

  1. Type Connect-MsolService.
  2. Enter your Office 365 Global Administrator username and password.
  3. Enter the copied customized PowerShell command.
  4. Ensure the federation is successful by entering this command:

    Get-MsolDomainFederationSettings -DomainName yourdomain.name.

 

Test Single Sign on configuration

  1. Log into Okta as a test user.
  2. Open Office 365 from the end-user dashboard.
  3. Ensure the user is successfully logged in to the Office 365 account.

 

5. Assign Office 365 to users and groups

You can assign Office 365 to groups and individual users from the app or from Directory.

If you are using Okta for provisioning, you can also assign licenses and roles to users and groups at the time of assignment.

If you have set up Okta → Office 365 provisioning and enabled the Create Users provisioning feature before assigning the app to users and groups, it creates user accounts at the time of assigning the app. If the user already exists in Office 365, Okta matches the user profile and maintains the relationship.

You can also assign license and role to users in Office 365. This fully automates the ability to provision fully working accounts 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. to log right into.

Note

Group priority determines what licenses and roles a user gets. If a user is a member of two groups assigned to Office 365, they will get the more robust licenses and permissions of the two groups. For more information, see Prioritize groups.

 

Assign Office 365 from the app

Assign to individual user

  1. Go to the [app] > Assignments > Assign > Assign to People.
  2. Search for the desired user.
  3. Click Assign for the desired user.
  4. In the Assignment dialog, enter other requested information.

    This information changes depending on the single sign on method and provisioning you’ve opted for.

Assign to group

  1. Go to the [app] > Assignments > Assign > Assign to Group.
  2. Search for the desired group.
  3. Click Assign in front of the group.
  4. In the Assignment dialog, enter other requested information.

    This information changes depending on the single sign on method and provisioning you’ve opted for.

 

Assign Office 365 from Directory

Assign to individual user

  1. In Directory > People, open the desired user profile.
  2. In Applications > Assign Applications, search for the desired app.
  3. Click Assign for the desired app.
  4. In the Assignment dialog, enter other requested information.

    This information changes depending on the single sign on method and provisioning you’ve opted for.

Assign to group

  1. In Directory > Groups, open the desired group profile.
  2. Click Manage Apps and search for the desired app.
  3. Click Assign for the desired app.
  4. In the Assignment dialog, enter other requested information.

    This information changes depending on the single sign on method and provisioning you’ve opted for.

 

 

6. Secure Office 365 using app sign-on policies

The default sign-on rule for Office 365 is different than other apps in Okta. This rule denies access to all clients from any network. It cannot be modified. This prevents clients that use Legacy Authentication from accessing Office 365.

The other Okta-provided rule allows access to only web browsers and apps that support Modern Authentication. Modern authentication is a term for a combination of authentication and authorization methods. These methods can include multifactor authentication (MFA), clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. certification-based authentication, Azure Active Directory Authentication Library (ADAL), and Open Authorization (OAuth).

You can edit this rule to make it more stringent. Alternatively, you can add another to allow clients using Legacy Authentication (not recommended). For more information about app sign on policies, see Office 365 Client Access Policies.

 

Edit sign-on rule to prompt for MFA

You can edit Allow Web and Modern Auth rule to prompt for multifactor authentication.

Prerequisite

Factor types should be enabled before you can use them for the MFA prompt. For more information, see Multifactor Authentication .

Warning

Enabling MFA for sign on may break older non-modern authentication clients since they do not have the ability to prompt for MFA.

  1. Go to Office 365 > Sign on > Sign on Policy > Allow Web and Modern Auth rule > Edit.
  2. From the Sign on Rule dialog, go to Actions > Prompt for Factor.
  3. Select the frequency at which you want to prompt the user for MFA when accessing Office 365.
  4. Click Save.

 

7. Add-on tasks

Once you have successfully deployed Office 365 in your org, you can explore other functionality to enhance your Okta-Office 365 integration. Some of these topics are listed below.

Provide Microsoft admin consent for Okta

Office 365 Client Access Policies

Using Group Push

Use Okta MFA to satisfy Azure AD MFA requirements for Office 365

Office 365 Silent Activation

 

Also see

Manage users

Manage groups

Manage user profiles

8. Frequently asked questions

Can my users access Office 365 using POP and IMAP?

Yes, they can but we cannot secure them via MFA since they do not use Modern Authentication. We recommend disabling these protocols in your Office 365 tenant and not using them if possible. To disable these legacy protocols in your Office 365 tenant, refer to this Microsoft Support documentation: How to enable or disable POP3, IMAP, MAPI, Outlook Web app or Exchange ActiveSync for a mailbox in Office 365.

 

What should I do if I want to configure multiple domains under one tenant?

You can configure a separate instance of the Office 365 application within Okta for each domain you have in your office tenant. For example, if you have five domains under your office tenant, you would have five office apps in Okta, each pointed to the same office tenant but set with a different domain.

 

Why don’t I see options to license and roles while assigning the Office 365 app?

It’s probably because you haven’t set up Okta for provisioning users into Office 365. For more information, see Provision users to Office 365.

 

Can I use PowerShell to configure Office 365 in Okta?

Yes, you can use PowerShell to check licenses and other information about your users. You can also delete federated users from PowerShell. For more information, see Configure Single Sign on using WS-Federation - PowerShell method.

 

Top