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.
Before you begin
- Complete Configure Single Sign-On for Office 365.
- Disable the Microsoft MFA for the Office 365 admin account that you're using for WS-Federation. If the MFA is enabled, it can break provisioning and single sign-on setups in Okta.
-
Bring users into Okta: You can import users from a directory such as Active Directory (AD) or an app such as Salesforce. Currently, Okta doesn't support imports that take longer than two hours to complete. Contact Support if you have this type of import. You can also create users directly in Okta. See the following for more information:
-
Decide the type of provisioning, depending on your provisioning needs. See Provisioning options for Office 365.
Start this procedure
To provision users in Office 365, you need to perform the following tasks in order:
Set up Okta to Office 365 provisioning
You can automate provisioning tasks by enabling API integration and configuring settings for different user lifecycle stages.
Enable API integration
Office 365 requires a token to authenticate against the Microsoft API. This allows Okta to implement provisioning in Office 365.
- Go to .
- Check Enable API Integration.
-
Click Authenticate with Microsoft Office 365. You're redirected to the Microsoft Azure login page.
-
Log in to your Microsoft Azure account.
-
Read and accept the requested permissions.
-
Upon accepting the scopes in the Microsoft Azure portal, you're redirected back to Okta.
-
- Enter your Office 365 Global Administrator credentials.
-
To import groups now, check Import Groups.
You can import groups later after finishing provisioning. See Skip importing groups during Office 365 user provisioning.
- Click Test API Credentials.
- Save the credentials once they're verified successfully.
Select provisioning type and settings
These options depend on the provisioning type you select.
- Go to .
-
Select Office 365 Provisioning Type. See Provisioning options for Office 365.
For Universal Sync only: Select Send full profile, contacts, and conference rooms from these AD instances if you want to sync Active Directory groups and resources.
- Enable or disable other provisioning settings. See Get started with Office 365 provisioning and deprovisioning.
- Click Save.
![Info Info](../../../resources/images/assets/icons/notes/help.png)
Each user provisioned for Office 365 has an attribute, StsRefreshTokensValidFrom, which is a date that invalidates existing user sessions and refresh tokens when users change their password, requiring the user to sign in to their apps again. This attribute is automatically calculated and populated based on the provisioning type.
-
License Only or Profile Sync: The StsRefreshTokensValidFrom attribute is set to the current date and time when the user changes their password in Okta.
-
User Sync or Universal Sync: If the user is linked from Active Directory (AD), the StsRefreshTokensValidFrom attribute is set to the pwdLastSet attribute in AD. For all other users, the StsRefreshTokensValidFrom attribute is set to the current date and time when the user changes their password in Okta.
Map profile attributes Okta to Office 365
Depending on where your users are sourced from, the username format can vary. For users to successfully sign in to Office 365, their username for Office 365 must be in an email address format for the domain you're federating (username@yourfederated.domain).
![Important Note Important Note](../../../resources/images/assets/icons/notes/help.png)
You must remap attributes whenever you make any changes to provisioning settings.
Map username unchanged
If your users already have their username in an email address format for the domain you're federating (username@yourfederated.domain) format, you can map the email without reformatting.
- Go to .
- In Email. , select
- Click Save.
Map custom username
If your users are sourced from different directories or apps, their username format may vary. You can use the Okta Expression Language to customize the username that is passed on to Office 365.
- Go to .
- In Custom.
Enter this expression in the provided text box:
String.substringBefore(user.email, "@") + "@yourfederated.domain"
, select - Replace yourfederated.domain with the domain that you're federating.
- Click Save.
Map email address
If your users' email addresses don't reside in the domain you're federating, you can use the Okta Expression Language to customize the email address that's passed to Office 365.
Prerequisite
Provisioning type should be selected to User Sync or Universal Sync. See Provisioning options for Office 365.
- Go to .
- In the source.email field, enter the expression:
String.substringBefore(user.email, "@") + "@yourfederated.domain" - Replace yourfederated.domain with the domain that you're federating.
- Enter an Okta user in the Preview box to check the result of the mapping.
- The resulting email address should match the Office 365 email address for the user.
- Exit Preview and save mappings.
- Click Apply Updates Now.
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. Be sure that you've selected the Create Users option in Provisioning.
In Okta:
- Open the Assignment tab of the Microsoft Office 365 app.
- Click Assign.
- Assign appropriate Office 365 licenses to test users.
- Click Done.
In the Microsoft Admin Center:
- Open the list of Active Users.
- Ensure that all test users appear in the list with appropriate licenses.
In Okta:
- Log into Okta as a test user.
- Ensure that all Office 365 apps appear on the user dashboard.
![Info Info](../../../resources/images/assets/icons/notes/help.png)
If you've selected the User Sync or Universal Sync provisioning type, all users appear as Synced with Active Directory in the Office 365 tenant, irrespective of where their profile is sourced. However, individual users are still sourced from their respective directories.