Creating the management agent

Create the Okta management agent in MIM and work through its configuration pages.

Complete the guide for your authentication method first. Before you start, you should have your Okta org URL, and either an API token or a client ID and the key details.

Step 1: Create the management agent

1. Open MIM Synchronization Service Manager.

2. Select Management Agents, then Create.

3. Select Okta (Lithnet).

4. Enter a name and description.

Creating an Okta management agent in Synchronization Service Manager.

If the management agent type is not listed, close and reopen Synchronization Service Manager. If it is still missing, restart the MIM Synchronization Service. This is usually because the product was installed or upgraded while the service was running.

Step 2: Configure connectivity

The fields you need depend on the authentication method:

• API token

• Private JWK

• X.509 certificate

There are two common mistakes on this page. The Tenant URL is the Okta org URL, such as https://example.okta.com, not the -admin hostname or an authorization server path. The log file path must also point somewhere the MIM Synchronization Service account can write to.

See Connectivity settings for the full field reference.

Step 3: Configure global parameters

There are three decisions to make on this page:

• Whether to import BUILT_IN and APP_GROUP groups. Both are read-only.

• Whether deprovisioning a user deactivates it or permanently deletes it.

• Whether new users are activated on creation, and whether Okta sends them an activation email.

The Global Parameters page.

The deprovisioning choice also changes what a full import returns, so read Global settings before you decide.

Step 4: Select object types

Select user, group, or both.

With OAuth, only the object types allowed by your granted scopes are shown. If one you expected is missing, grant the matching read or manage scope in Okta and retrieve the schema again.

Selecting the user and group object types.

Step 5: Select attributes

id is mandatory. Beyond that, select only the attributes that your joins, flows, filters, and reporting actually use.

Attribute directions come from the mutability set on the Okta profile and, with OAuth, from whether the app holds the read or manage scope.

availableFactors, enrolledFactors, and group member each cost an extra API call per object during import. Select them only if you need them. See Schema and attributes for the details.

Selecting user profile and factor attributes.

Step 6: Configure anchors

id is the anchor for both object types. The connector declares it in the schema, so there's nothing to configure here.

The connector also uses the Okta id as the distinguished name on import. When MIM provisions a new object it has to supply a DN itself, so 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. Run that confirming import before exporting any further changes to newly provisioned objects.

Step 7: Configure synchronization rules

Build the connector filters, joins, projections, and attribute flows your solution needs. Two connector-specific rules apply:

• Flow suspended to suspend and unsuspend a user. Never flow status. It is import-only, and activation and deprovisioning are driven by the global settings instead.

• Never flow anything to BUILT_IN or APP_GROUP groups. Only OKTA_GROUP groups are writable.

The object-specific guides cover the rest:

• Users

• Groups and membership

• Password management

Step 8: Configure deprovisioning

To deactivate or delete an Okta object, configure MIM to Stage a delete of the object for the next export run.

For users, the User deprovisioning action global setting decides whether that delete deactivates the user or permanently deletes it. Group deletes are always permanent.

Step 9: Create the run profiles

Finish the wizard and create the run profiles.

Then return to Getting started for the first controlled import and synchronization. Make sure your ongoing schedule includes a periodic Full Import: Okta can't return an object it no longer holds, so a delta import will never detect a deletion.