Supported objects and operations

What the management agent can and cannot do with Okta users and groups.

The management agent supports the user and group object types. Both use the Okta object id as the anchor.

Users

Operation	Supported
Full import	Yes
Delta import	Yes
Create	Yes
Update profile	Yes, for attributes the Okta user schema marks as writable
Activate on create	Optional, with or without an Okta activation email
Suspend and unsuspend	Yes
Deactivate	Yes
Permanently delete	Optional
Set and change password	Yes

The user schema is built from the base and custom attributes of the default Okta user profile.

Groups

Operation	Supported
Full import	Yes
Delta import	Yes
Create	OKTA_GROUP only
Update name and description	OKTA_GROUP only
Add and remove members	OKTA_GROUP only
Delete	OKTA_GROUP only

BUILT_IN and APP_GROUP groups can be imported as read-only reference data. Okta or another application owns them, and the management agent will not write to them.

OAuth scopes and the schema

With OAuth authentication, the scopes granted to the service app determine what MIM sees when it retrieves the schema. A read scope presents the object type as import-only, a manage scope adds the supported export operations, and an object type with no scope isn't presented at all. See Creating the OAuth service app.

API-token authentication always presents both object types with all supported operations, because a token carries no scope information the connector can read. Select only the operations that the token's owning account is allowed to perform.

Deletion and deactivation

The User deprovisioning action setting on the Global Parameters page changes both export and import behavior. Read this section before you design your deprovisioning rules.

With Deactivate, a staged delete deactivates the user in Okta. Deactivated users are not presented to MIM, so a delta import confirms the delete. The user still exists in Okta and has to be deleted or reactivated there.

With Delete, a staged delete deactivates and then permanently deletes the user. Deactivated users that still exist in Okta are imported normally. Only a full import can confirm the permanent delete, because a deleted object cannot be returned by any query.

Group deletes are always permanent and are only confirmed by a full import.

Limitations

• The management agent cannot reactivate a deactivated Okta user. With the Deactivate setting the object leaves the connector space, so a later reprovision is exported as a create, which Okta rejects because the login is still in use. Reactivate the user in Okta first.

• Delta import cannot detect an object that was deleted outside MIM. Schedule a periodic full import.

• Selecting group member adds one membership query per imported group, and availableFactors and enrolledFactors each add one query per imported user.

• Okta rate limits apply to every import and export, and are shared with everything else using the org.

• Exports are not transactional. A create can succeed and a following activation, suspension, or membership change can fail. See Imports and exports.