RobL.71426 (Customer) asked a question.
Should a Full Import deactivate a Suspended user?
We source our users in AD.
When we disable an AD user and do an Import, the user is Suspended in Okta. This is expected.
When we delete or move the disabled AD user and do a FULL import, we expect the user to be unassigned from the AD Integration and Deactivated in Okta. This does not seem to be happening.
Are my expectations wrong? Is there a reason a Suspended user does not get Deactivated by a Full Import after they're removed from the Okta OU?
Hello @RobL.71426 (Customer),
Thank You for posting.
Navigate to Directory > Directory Integrations > Active Directory > Import > Import Now, then review the descriptions of incremental and full imports.
Note that it states for incremental imports that "Users not present in the data will not be changed. (This is the type of import performed by automatic scheduled imports.)" So if you delete the user, then the data is no longer present and the user will not be disabled in Okta.
Now see the description for full imports that states, "Users not present in the data will be deactivated." So this is why running a full import will deactivate the user.
Instead of deleting the user entirely, just try disabling the user, so the data is still present and will get picked up by an incremental import the next time it's scheduled.
Regards,
Natalia
Okta Inc.
Hi Natalia,
The wording on the Full Import is fuzzy : "Users not present in the data will be deactivated." DEACTIVATED is a specific thing in Okta, but it appears that what actually happens to these users is whatever the AD Integration Setting is (in our case, Suspended, not Deactivated)
So we understand the suspend action. Now we have another issue:
Once we have more than 20% of our total Okta AD users deleted from AD, we are now constantly triggering the 20% unassignment threshold warning. It appears this means that all the users are set to be unassigned from the AD Integration, but they weren't all deleted at once, so they should have been unassigned in small batches over time. It appears they are being flagged / counted for unassignment, but never actually unassigned, so the 20%+ warning level persists.