I am trying to understand the user provisioning in Okta, Active Directory, and Office 365. When I create a user in Active Directory, the user is imported to Okta, and based on an Active Directory group, the user is assigned the appropriate license. I have noticed that when I disable the user in Active Directory, the user's sign-in is blocked in Office 365. When I remove the user from the group in Active Directory I created to assign a license, that license is removed in Office 365. However, how do I actually delete the user in Office 365? When I delete a test user in Active Directory, the user isn't deleted in Office 365. When I delete the user manually from Okta, the user isn't deleted in Office 365. What is the correct workflow for user deletions? Must administrators resort to Office 365 PowerShell scripts for user deletions after they are deleted in Active Directory and Office 365?
Understanding App Assignment Before we go into the configuration of SSO and provisioning, it is worth understanding how Okta controls access to these applications. To be able to provision an account in Office 365 and provide SSO, you need both a user account in Okta (described in “Importing Users into Okta” which you can find in the Office 365 deployment guide) and the user needs the Okta Office 365 app assigned to them (described in “Assigning users to Office 365” which is also in the Office 365 deployment guide). Assigning an app in Okta to a user: • Allows that user to login to the application via Okta. • If the target application has been setup to provision new users, then assigning the app to the user causes Okta to provision an account in the target system. The inverse is also true, when you remove the app assignment, Okta will de-provision the user. In Office 365 this means the user account is set as Blocked. Okta does not delete users accounts in Office 365.
Here is the Okta Office 365 documentation that explains the process of de-provisioning users.
Thank you for the information. Unfortunately, neither the article you linked or the answer you gave addresses my question of: "What is the correct way to delete a user in Office 365 while using Okta?" I can see that the user isn't automatically deleting, as contained in the Okta Office 365 documentation. However, using the Office 365 portal administration also does not allow the user to be deleted, as it indicates that the user account is controlled by our on-premise directory. So, my original question stands, "How do I delete a user with an AD/Okta/Office 365 federation?" Is PowerShell the only way to accomplish this? Why isn't it documented better or discussed during implementation? Does Okta really expect Office 365 users to never be deleted?
Matt, had the same question myself but support was able to answer it. For now, you'll want to write up a powershell script around the remove-msoluser command, and execute that script to delete (move to recycle bin in exchange online) and if desired, remove from recycle bin to fully delete the account. Better user deprovisioning support is apparently coming as an early access feature in the next few months. Microsoft's docs basically say the same, that if a federated user is deleted from the directory (Okta in this case) but isn't deleted from Azure AD, it will need to be manually deleted. https://support.microsoft.com/en-us/help/2619062/you-can-t-manage-or-remove-objects-that-were-synchronized-through-the
Chris, thank you for this! So did you follow that link exactly as written? It sounds like you are basically turning off "dirsync", manaully deleting the users via PS, and then reenabling sync. Is that accurate?
We do what Chris mentioned in the org, but not exactly following the article. We don't have to disable dirsync as we don't even use Dirsync, which is no longer supported and replaced by Azure AD Connect. OKTA does the synchronization for us, my guess is through Azure sync.
We just run connect to MSOnline (connect-msolservice) and run the remove-msoluser <username> as Chris mentioned and that does the job. There are no errors that you would normally get that says it can't do it due to the sync with on-prem.
Would be nice to have OKTA do more than what it does today.