Setting up user management
Configure the management agent to import and manage Okta users.
Step 1: Decide between import-only and management access
With OAuth, grant the service app one of:
okta.users.readto import users without exporting anythingokta.users.manageto import, create, and update them
The app also needs an admin role that covers the users and operations MIM will manage, and a resource set if you want to limit its reach. Add the lifecycle and credential permissions if MIM will change user status or passwords. Creating the OAuth service app lists the permission for each operation.
Retrieve the MIM schema again after any scope change.
With an API token, MIM always shows the full user schema, regardless of what the token's account can actually do. Select only the operations that account is permitted to perform.
Step 2: Select the object type and attributes
Select the user object type. id is mandatory.
Before you design provisioning flows, open Directory > Profile Editor in Okta, select the Okta user profile, and note which base and custom attributes are marked required. The usual set is login, email, firstName, and lastName, but the profile can be customized, so yours may differ. Every required attribute must receive a value on create, or Okta will reject it.
Select suspended if MIM will suspend and unsuspend users. Do not flow status.
availableFactors and enrolledFactors each add an API call per user during import. Select them only if the solution reads them.
Step 3: Configure joins and projections
Join on whatever your design calls for, but keep the following in mind.
The anchor is the Okta id, and so is the DN on import. Don't build your design around login or email: both can change, and neither identifies the object to Okta.
If you select managerId, MIM presents it as a reference to another Okta user. The manager has to be in the connector space already for the reference to resolve, which usually means importing users before flowing manager references.
Step 4: Configure outbound attribute flows
Flow to the writable Okta profile attributes. MIM derives their directions from the Okta schema, so if you can't flow to an attribute, it's because Okta has marked it as read-only or immutable.
When MIM provisions a user it supplies its own DN. Use any unique value, such as a GUID. The export returns the Okta id as the anchor and the confirming import replaces the temporary DN with it.
Step 5: Choose what happens to new users
On the Global Parameters page:
Activate new users activates the user immediately after it is created.
Send activation email to new users has Okta send its activation email, and only applies when the option above is selected.
If you leave activation off, new users stay in the STAGED state until something else activates them.
Step 6: Configure deprovisioning
Stage a connector delete when a user should be deprovisioned, then choose the User deprovisioning action on the Global Parameters page:
Deactivate leaves the user in Okta in a deactivated state. A delta import confirms the delete, because deactivated users are no longer presented to MIM.
Delete deactivates the user and then permanently deletes it. Only a full import can confirm that, because Okta cannot return an object that no longer exists.
Step 7: Configure password management
If MIM will set or synchronize passwords, see Setting up password management.
Step 8: Test
Run Full Import and Full Synchronization, and confirm the users and attributes you expected are there.
Test a profile update.
Test each operation you enabled: create, activation, suspension, unsuspension, deprovisioning, password.
Run a confirming import after every export.
If a create reports an error, check Okta before you retry. Exports are not transactional, so the user may have been created even though a later activation or suspension step failed.
Last updated