Admin Account Lifecycle Management – Part 1: Automated Provisioning with Entra ID Governance

by

The lifecycles of admin accounts can be tricky to manage, because admin accounts are not regular user accounts – they have to be handled differently. You need to make sure, just like with regular users, that they are not over-privileged. Another thing to consider with admin accounts is their lifecycle. What happens when the regular user is offboarded? Does the admin account get automatically deleted, or is it forgotten because it’s not a regular user and stays enabled until somebody sees the admin user and remembers that the user who owned that admin account has been offboarded and then manually deletes it?

This blog post will focus on the “onboarding” part of admin accounts lifecycle – how you can allow specific users in your organization to request different types of admin accounts and then “bind” the admin account to their regular user account. The way I’m going to accomplish this is by leveraging the API-driven user provisioning for both on-premise Active Directory (AD) and Entra. This will serve as the tool to create (or provision) the admin account and bind it to the user that requested it. The way I’m going to do it is by using the EmployeeID attribute in AD and Entra. (This requires you to already be populating the EmployeeID attribute for regular users.) When the admin account is created by the API-driven user provisioning, the same employee ID value for the user who is requesting the admin account will be set in the EmployeeID attribute, and then “AA” will be added to the end of the employeeID. AA stands for Admin Account – this is how the two accounts will get bound to each other. I will write another blog post on how the offboarding of the user will affect the admin account, but for now this blog post will focus on the request of the admin account and the provisioning of it.

The way the user is going to request the admin account is by requesting an access package in Entra ID Governance, and when that request for that access package is approved, a PowerShell script will run to create the user in AD or Entra, based on what type the user has requested. The Lifecycle Workflow will then run the task that generates a TAP (Temporary Access Password) for the admin account that gets sent to the user – the user who requested it is set as the manager via the API-driven user provisioning, and the admin account is also hidden from the GAL to not clutter AD unnecessarily.

Please note that this approach is not designed for Domain Admin accounts. Domain Admins should not be synced to Entra for any reason. The context for on-prem admin accounts in this blog is for Tier 1 or Tier 2 access and they should not ever hold Entra or Azure permissions in any way. I’ll elaborate on how to limit that as well at the end.

Prerequisites

Setting up the PowerShell scripts

Before we set up anything in Entra ID Governance, we will start off by creating the three runbooks in the Automation Account – one for on-premises admin accounts, another one for cloud admin accounts, and lastly a runbook that will send the requester an email with a Temporary Access Pass (TAP).

The code for each script can be found here:
Cloud admin account: Entra/API-driven inbound provisioning/EntraID_Create-AdminAccount.ps1
On-prem admin account: Entra/API-driven inbound provisioning/AD_Create-AdminAccount.ps1
Development/BlogPosts/AdminAccountPart1/CreateTAP.ps1 at master · ChrFrohn/Development – Send TAP to users manager: Miscellaneous/Create-TemporaryAccessPass.ps1

All three PowerShell scripts require that the Managed Identity is enabled and have SynchronizationData-User.Upload, Mail.Send, and UserAuthenticationMethod.ReadWrite.All permissions.
TIP: You can use this script to set the permissions: Setup-EntraIDPermissionsForAzureAutomationAccount.ps1, You will also need to provide the two scripts that create the admin account with the Provisioning API Endpoint for the API-driven provisioning for both AD and Entra ID.

The way the first two scripts work is that each of them uses the API-driven user provisioning to create the admin account in either AD or Entra. The scripts will get the Object ID or the UPN of the user that requests the admin account, and the scripts will then get that user’s name and employee ID from the Microsoft Graph and use that information to create the admin account (See picture beblow)
The manager attribute will be set to the user requesting the account, for TAP and other purposes that I will expand on later.

But we might be getting ahead of ourselves here. When the PowerShell scripts are in place in the Automation Account, we can then move on to Entra ID Governance where we will be creating a Catalog and two Access Packages that will trigger each of these scripts, and also the Lifecycle Workflow that will handle the password for the accounts.

Setting up Entra ID Governance for admin account provisioning

We will start by creating a new Catalog in Entra ID Governance Entitlement Management named “Admin accounts,” and then right after that we need to create two Custom Extensions – one for each of the PowerShell scripts. The creation of the Custom Extensions is the same for each of them; the only difference is the name of them, otherwise they are identical.

Navigate to the new Catalog and select Custom Extensions, and then “Add a Custom Extension” and provide it with a name and description. Press next and next, and then in Extension Configuration set it to “Launch and wait” and set the wait time to 30 minutes. The wait time is to allow enough time for the Automation Account to process the script in case there are other scripts running.

After that, press next and then provide the Logic App with a name and select the resource group where the Logic App should be placed. Please note this down as we will need to navigate to it afterwards in order to allow the Logic App to trigger the PowerShell script.

This process needs to be repeated so you have a Custom Extension for each of the PowerShell scripts.

Before we set up the Access Packages that will be used to request and create the admin account, we need to allow the two new Logic Apps that got created from the Custom Extensions to start the PowerShell scripts (runbooks) in the Automation Account.

Configure and set up the Logic Apps (Custom Extensions)

This again needs to be repeated for each of the Logic Apps. Navigate to the first Logic App and select Identity in the left side menu and enable it on System assigned. Then select Azure Role assignments.

Then assign the role Automation Operator to the Logic App via the Resource Group scope.

Now that we have allowed the Logic App to operate the runbooks, we can then proceed to set up the Logic App to start one of the runbooks. In the Logic App’s menu on the left, navigate to Logic App designer. The first step we need to add is Create job from Azure Automation.
You will need to select the subscription and resource group where the Automation Account is located, and then the Automation Account.
Then select the runbook – in this case Provision-Cloud-AdminAccount (you might need to select runbook under Advanced parameters first), then select Yes in “Wait for job” and in the last one, Runbook Parameter, select ObjectId (Requester ObjectId).

We need to add one more step, and that’s the Get status of job:

Remember, this needs to be repeated for the other script (on-premises admin account).

Creating the Access Packages

We need to create an Access Package for each of the admin account types, so the process is more or less the same with only variation being in the Custom Extension step where one Access Package will have Custom Extensions for the cloud admin account and the other Access Package will have the on-premises admin account.

Start in Entra ID Governance Entitlement Management and select Access Packages, and then New access package. Provide it with a name and description, and make sure to select the Catalog that we created in the beginning.

The Resource roles step can be skipped – we will not add anything there since this Access Package is only used to create (provision) an admin account.

The Requests step is where we will need to determine the settings of who can request, who will approve, etc. We need to restrict the users that are allowed to request these Access Packages, and the simple (and best?) way to do it is by selecting “Specific users and groups,” and then select one or more groups that contain the users you want to be allowed to request the Access Package – I have selected one group for now.

The next part of it is the approval of the request for the Access Package. This can be set up any way you see fit, but here is how I’m doing it. I’m going to set it up for 2-stage approval, and in the first one I’m going to select the manager as the first approver, and then the fallback will be the group that contains the users that approve PIM requests since they are the closest ones to know if a user should be allowed to have an admin account. In the second stage, it will be the PIM approvers group, since they have the final say, and “Require approver justification” is set to yes for both stages.

You should consider adding require Verified ID with a Face check for the requester of the Access Packages, but that is always something you can add at another time if you have not set that up yet.

The next step we will focus on is the Lifecycle step. Here we will keep it simple and set the expiration to never and specific time request to no, since this is not a “regular” Access Package that needs to expire or otherwise.

In the Custom Extensions step, we will select the first of the Custom Extensions we created – in this case the cloud admin account provisioning, and the Stage should be when Assignment is granted.

This was the last step for the Access Package creation. Remember to repeat this for the on-premises admin account!

The password for the accounts

One of the key parts of this setup that we have not set up is the password for the accounts. The API-driven user provisioning can’t be used to set the password of the admin accounts, and the other thing is how to provide the user that requested the account with the password. To solve this we will be using TAP (Temporary Access Pass), and send that Temporary Access Pass to the user by using a Lifecycle Workflow in Entra ID Governance with a Custom Extension.

The creation of the Custom Extension for the Lifecycle Workflow is more or less the same as with the Custom Extensions for the Access Packages, so repeat that process. The only difference is where you need to create it from, and that is from the Lifecycle Workflow menu in Entra ID Governance here: https://entra.microsoft.com/#view/Microsoft_AAD_LifecycleManagement/CommonMenuBlade/~/overview. I have written a blog post about how to do this in more detail here: How to run PowerShell scripts in Entra ID Governance Lifecycle Workflows, but as I said, it’s the same process as we just went through with the Access Packages extensions.

The PowerShell script for sending the TAP can be found here: Miscellaneous/Create-TemporaryAccessPass.ps1.

When the Custom Extension has been set up, we can start by creating the Lifecycle Workflow.

The Lifecycle Workflow is based on the template Onboard new hire employee. Using that template with the createdDateTime attribute set to 0, the Lifecycle Workflow will trigger as quickly as possible for both the cloud admin account and also for the on-premises admin account.

But in order to make sure this only runs for the admin accounts, we need to set the rule in the Scope details to be EmployeeId startsWith AA. This will make sure only the admin accounts are targeted for this.

In the Tasks step, we need to remove all the “default” tasks, and then only add Run a Custom Task Extension. Then select it and provide a name and description for the task, and then finally select the Custom Extension that was created for this.

When you are done setting this up, press next and create – remember to enable the Lifecycle Workflow at the bottom.

The requester’s point of view

Everything is now ready for the user to start requesting admin accounts and for managers and other approvers to approve the request, and for the user to receive the TAP and start using the admin account.

The user will request the Access Package just like any other via https://myaccess.microsoft.com/, type in the justification, and then wait for the manager and other approvers to complete the approval.

When the request has been approved, the user will then receive the TAP via email and can then proceed to use the admin account.

Wrapping up

You should think carefully about the need for having privileged accounts like the on-premises admin account sync to Entra. The rule of thumb is to not do it for any reason in order to prevent an on-premises admin account from being compromised and also compromising Entra and other cloud resources. In order to mitigate that, I’ll recommend creating a Conditional Access policy that blocks all cloud apps, and then only exclude My Profile (8c59ead7-d703-4a27-9e55-c96a0054c8d2) in order to allow the usage of TAP, etc.

I will go into more details about this in the next blog post about admin accounts that will focus on preventing on-premises admin accounts from accessing cloud resources in any form and how to request access to on-premises resources. The last installment in what will be a three-part blog post series about admin account governance will be about offboarding and how to handle the admin accounts.

Post Views: 3,178