Until a few months ago (as of this writing), I had an Automation Workflow in Okta that would delete Okta-mastered accounts that had not logged in for 2 years. That may sound like a long time to leave inactive accounts laying around, but we maintain accounts for former employees so they can get into Workday to retrieve their tax documents. Many of them will only sign in one time each year, but if an account goes unused for two years, they should be safe to delete without inconveniencing anyone.
Unfortunately, Okta recently changed the behavior of the Delete action in the automation workflow. Instead of setting the account status to DELETED, it deactivates them, turning the status to DEPROVISIONED, and the workflow is limited to just one Delete action so there's no way to actually delete the deactivated accounts in the workflow. To make matters worse, I have a powershell script that reactivates all deactivated accounts, so after the workflow deactivated the accounts, the powershell script turned around and reactivated them, even going so far as to sending activation emails to the accounts with legitimate email addresses. And THAT prompted calls and emails to the HR department, demanding to know why we continued to send them unsolicited emails. Needless to say, I deactivated that workflow as soon as I was made aware of the problem. I was quite busy at the time and so I didn't get around to finding another solution, until today. Well, yesterday, actually.
The solution has two parts. The first part involves the automation workflow. Instead of setting the account status to DELETED (DEPROVISIONED, actually), I modified it to set the status to SUSPENDED. In 5-6 years, I've used that status very rarely, so this seemed to be a great way to allow the workflow to identify dormant accounts and get them into some sort of container that I could then - and this is the second part - modify a copy of my reactivation powershell script to query Okta for all the users in the SUSPENDED status, and then delete them with an API call (two API calls, actually, since the first merely deactivates them, just as in the workflow).
Part 1: The Automation Workflow
The reactivation powershell script not only reactivates the accounts of former employees, but it also puts them into a special Okta group that assigns them to the Workday integration. The Automation Workflow also uses that Okta group to limit itself to just the former employees. The workflow is set to run at 5pm every day and look for any user that has been inactive for 730 days. If any former employee accounts meets that criteria, the account status is changed to SUSPENDED.
Part 2: The PowerShell Script
The powershell script will use the Okta API to query our org and return all accounts with a SUSPENDED status. It then loops through that array of accounts and makes two API calls to delete that account. As the script loops, information about each account is logged to a file, and when all the accounts have been processed, the script emails the log file to the designated email address. This gives us a record of which accounts were deleted, and when.
<# .SYNOPSIS Okta_Purge_Inactive_Former_Associates.ps1 - Deletes suspended Okta accounts for former associates Created by Mike Koch on December 16, 2020 .DESCRIPTION Queries Okta for all SUSPENDED accounts, then deletes them Send email with all logged events/actions .NOTES TO DO 1. #> [CmdletBinding()] Param() $api_token = "put_your_org_token_here" $uri = "https://yourcompany.okta.com/api/v1/users?filter=status%20eq%20%22SUSPENDED%22" [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 $allusers = @() $logfile = "c:\temp\Okta-Purge.log" if (Test-Path -Path $logfile) { Remove-Item -Path $logfile -Force } function LogWrite { param ([string]$logstring) Add-Content $logfile -Value $logstring } # Query Okta using the URI specified above, page through the results to get all matching accounts Do { $webrequest = Invoke-WebRequest -Headers @{"Authorization" = "SSWS $api_token"} -Method GET -Uri $uri $link = $webrequest.Headers.Link.Split("<").Split(">") $uri = $link[3] $json = $webrequest | ConvertFrom-Json $allusers += $json } while ($webrequest.Headers.Link.EndsWith('rel="next"')) if ($allusers.count -gt 0) { foreach ($usr in $allusers) { LogWrite "Deleting suspended user: $($usr.profile.login), $($usr.profile.displayname)" Write-Output "Deleting suspended user: $($usr.profile.login), $($usr.profile.displayname)" # the first DELETE only DEACTIVATEs the account Invoke-WebRequest -Headers @{"Authorization" = "SSWS $api_token"} -Method Delete -Uri "https://yourcompany.okta.com/api/v1/users/$($usr.id)" # the second DELETE actually DELETEs the account Invoke-WebRequest -Headers @{"Authorization" = "SSWS $api_token"} -Method Delete -Uri "https://yourcompany.okta.com/api/v1/users/$($usr.id)" } $MailMessage = @{ To = "SomeoneWhoCares@youremaildomain.com" From = "OktaMaintenanceBot@youremaildomain.com" Subject = "Report: Okta Former Employee Account Deletions" Body = Get-Content $logfile -Raw BodyAsHtml = $false SmtpServer = "your.smtp.server" } Send-MailMessage @MailMessage }
It's been a couple of months since the automation workflow broke. I opened a case with Okta and they acknowledged that there had been an unintended behavior change. The issue was escalated to the developers and the support case was closed. I'm sure they'll fix it eventually, but as a global retailer with thousands of employees, we have a lot of turnover so I need to keep up with the dormant account deletions. If for no other reason than to ensure that we have accurate counts the next time our contract is up for renewal. Even dormant accounts cost money.
Today's initial run of SUSPENDED users came to well over 14000. That got us caught up from the last couple of months, so subsequent runs should be much more reasonable, and finish much more quickly.
