We are now at the last part of the blog post series about admin lifecycle management. In this last part, the focus will be on offboarding – specifically the scenario where the user who owns the admin account(s) is leaving the company and their regular user account is offboarded. In the real world, however, admin accounts are often left behind, meaning the admin account remains enabled with all its roles still attached. This presents a security risk and is therefore something we need to address.
The way this is going to be accomplished may not be the most complex solution you are about to read, but sometimes we need to keep it simple. And the way we are going to handle the offboarding of admin accounts is to simply delete them. The reason for this is, that there (should) is no real reason to keep the account since the user has left the company, the regular user account may be kept for mail forwarding and such. But the admin account(s) should not “survive” after a user with admin accounts has left the company.
In this blog post I will go over how we identify the admin accounts that needs to be processed and how we are deleting them, whether it be an on-premises admin account or a cloud admin account.
Prerequisites
- API-driven inbound provisioning app setup already (For both Entra and AD on-prem)
- Entra ID Governance license
- Azure Automation Account
Finding the admin accounts
The first thing we need to do is to find the admin accounts that belongs to the user that are being offboarded. Remember in part One where we added the user as the manager for the admin accounts and then set the AA (admin accounts) prefix? We are going to utilize that now in the offboarding.
The way this is going to work is by having a Custom extension task in your regular user offboarding Lifecycle Workflow that will process the user and then get the direct reports for the user and then filter based on the Employee ID that starts with “AA”. Then for each account found that matches that filter a new lifecycle workflow will be triggered that will delete the admin accounts.
To find the admin accounts we are going to use the following PowerShell script that needs to run in a Runbook in the azure automation account we have used in Part One.
The whole process on how to run a PowerShell script in a Lifecycle Workflow task can be found here https://www.christianfrohn.dk/2024/06/06/how-to-run-powershell-scripts-in-entra-id-governance-lifecycle-workflows/
You will need to provide the PowerShell script with the Workflow ID of the Lifecycle Workflow that handles the admin offboarding, but before we can actually do that we need to create the Lifecycle Workflow that will handle the deletion of the admin accounts.
Processing the admin accounts
We will need to create just one new Lifecycle Workflow that is based on the template Real-time employee termination. The reason for this one is because it’s an on-demand template and it provides us the built-in task Delete user which is the only task we need.
When you have selected the template Real-time employee termination proceed to the review tasks tab.
There is however something we need to be aware of, and that is: Users with Microsoft Entra role assignments aren’t supported, nor are users with membership or ownership of role-assignable groups
That means that we need to make sure that the admin accounts get all their Entra roles removed before we can delete them. This will be done by adding the task Remove all access package assignments for user.
Because we utilized Access Packages in part Two to assign Entra roles – either directly in the access package or using groups via the access package – this will then give us the clean removal of the Entra role assignments. If you however have assigned an Entra role directly to an admin account, then the delete task will fail. Like so:
Note: If you keep seeing the above error when offboarding admin accounts, you can add a new Custom extension task that runs a PowerShell with: Start-Sleep 300 – This will provide enough time to let the Entra backend catch up
In order to delete the accounts we will need to add the Task Delete user account. Remember to select Delete on-premises account in the task
The task will use the Microsoft Entra Provisioning Agent to delete the user account in on-premises Active Directory. This means that we don’t need to tell the Lifecycle Workflow task if the admin account is a cloud admin account or an on-premises account, and if the account is a cloud-only account it will get deleted without the need for the Provisioning Agent and just use the built-in feature in Entra ID Lifecycle Workflow.
When you have the two tasks, then select Review + Create at the bottom and then select Create.
Now that the new Lifecycle Workflow for the admin accounts have been created, you can then copy the Workflow Id into the PowerShell script in the Runbook in the Automation account.
Here is how it looks when it’s run (from when the task is triggered in the regular user’s offboarding Lifecycle Workflow):
And the Admin account offboarding task from the Lifecycle Workflow:
Wrapping up
As I mentioned in the beginning, keeping it simple is sometimes the right approach. The admin accounts get deleted when the regular user is offboarded – no complicated archiving or retention, just deleted. The admin accounts should not “survive” after the user has left the company.
The whole solution relies on Access Packages being used for privileged access. If you have Entra roles assigned directly to the admin accounts outside of Access Packages, the delete task will fail. So if you are planning to implement this, make sure your admin accounts get their roles through Access Packages as described in part Two.
With all three parts combined, you now have a way to provision admin accounts when requested, secure them with Conditional Access and Access Packages for privileged access, and automatically delete them when the regular user leaves. I hope this blog post series can help you with managing the lifecycle of admin accounts in your environment.