> For the complete documentation index, see [llms.txt](https://docs.lithnet.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lithnet.io/okta-ma/operations/setting-up-user-management.md). # 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.read` to import users without exporting anything * `okta.users.manage` to 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](/okta-ma/authentication/creating-the-oauth-service-app.md#step-5-assign-an-admin-role) 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. {% hint style="warning" %} The management agent cannot reactivate a deactivated Okta user. With **Deactivate**, the object leaves the connector space, so a later reprovision is exported as a create, and Okta rejects it because the login is still in use. Reactivate the user in Okta first. {% endhint %} ## Step 7: Configure password management If MIM will set or synchronize passwords, see [Setting up password management](/okta-ma/operations/setting-up-password-management.md). ## Step 8: Test 1. Run Full Import and Full Synchronization, and confirm the users and attributes you expected are there. 2. Test a profile update. 3. Test each operation you enabled: create, activation, suspension, unsuspension, deprovisioning, password. 4. 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lithnet.io/okta-ma/operations/setting-up-user-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.