Continuing from where I left off in part 1 of this blog post series, in this one I want to turn the focus on the security I wrote a little bit about at the end of part 1, but also how to request access to different resources on behalf of the admin accounts. One of the elements of all of this that stands out for me is the on-prem admin account. That is because I’m going to govern these accounts using a cloud system, but that sort of contradicts some of the best practices like you should not sync on-prem privileged accounts to the cloud, and for good reason, you are running a risk of opening yourself up to lateral movement. Say your on-prem admin account got compromised, then your cloud environment could be compromised as well.
In order to try to mitigate that, I have created a Conditional Access policy that prevents the on-prem admin account from accessing any cloud resource except for the My Profile page.
Another part of this blog post is about how to securely provide access to different resources for either the on-prem admin account or the cloud admin account. Even if you have PIM set up in Entra, you will still need to make the cloud admin account at least eligible for some roles, and the on-prem admin account needs to also have some form of access to a web server or similar.
There is of course the question about licenses for your cloud admin accounts: should they have or should they not have licenses in order to perform various tasks in different Microsoft admin portals? I will not get into the subject about whether you should or should not assign licenses to cloud admin accounts. I will demonstrate how it can be done.
Prerequisites
- Entra ID Governance license for the admin accounts
- PIM setup and configured
- Plus Addressing in Exchange Online enabled
Conditional Access Policy for on-prem admin account
As mentioned, in order to prevent the on-prem admin account from accessing cloud resources, I’m going to create a Conditional Access policy that will block access to all cloud apps and then exclude My Profile (8c59ead7-d703-4a27-9e55-c96a0054c8d2) in order to allow the usage of TAP, etc.
Navigate to Entra ID and then Protection, and select Conditional Access. Create a new policy and give it a descriptive name – I have named mine “203 – On-prem Admins – All Apps – Block”.
In the Users section under Assignments, select Include and then choose the security group that will contain your on-prem admin accounts. I have a group called “On-prem admins” that I’m using for this. Remember to create an Exclude group for this policy since there are some cases that will require an admin account on-prem to have a cloud privileged role, and then of course your break glass account group.
In Target resources, select All cloud apps under Include, and then under Exclude add My Profile (8c59ead7-d703-4a27-9e55-c96a0054c8d2). This exclusion is important because it allows the on-prem admin account to still use TAP and manage their profile
Under Access controls, select Grant and then Block access. This is the part that will actually prevent the on-prem admin account from accessing any cloud resource. Use report-only to begin with, just to make sure
When you are done, enable the policy at the bottom.
Email & Notifications for cloud admin account
I want to also touch on the fact that the cloud admin accounts need to have some form of email when it comes to PIM notifications or similar. This can be accomplished by using Plus addressing, or you can of course assign an Exchange Plan 2 license to the cloud admin account and then set up mail forwarding to the regular account that the cloud admin account is bound to. If you decide to go with the Plus addressing like Merill Fernando describes in this tweet: Merill Fernando on X: “Are you following best practice and setting up your Azure AD secondary/admin accounts without a mailbox? A neat hack is to use the new + mail format to set the Email address of the admin account to the user’s primary mailbox. This way all PIM & other alerts get to the user 1/4 https://t.co/6TSJnRTfvS” You can use this script to setup plus addressing for the cloud admin account by using this PowerShell script as a part of the provision Lifecycle workflow that was configured in part 1 in the same way as the “Send TAP” was configured.
Miscellaneous/EntraID_Set-PlusAddressing.ps1 at master · ChrFrohn/Miscellaneous
Getting access to resources
Before we can configure Access Packages to be used to provide access to privileged resources, we need to alter the Access Packages for both admin account types from part 1 of the series, and also the Lifecycle Workflow. We need to create an Entra Security group that will be used to govern who can request the access packages for the privileged resources.
Create the group like so:
And then add it to both admin account provisioning Access Packages from Part 1:
And then add a new step “Add user to group” in the admin account tasks lifecycle workflow like so:
Now that we have that configured, we can proceed to talk about how the access packages should be configured. In order to get access to resources for either the cloud admin account or the on-prem admin account, we are going to use Access Packages in Entra ID Governance entitlement management, but the kicker is we are going to request on behalf of the admin accounts. Remember in part 1 where the manager of the admin account gets set to the requesting user? This is where we are going to utilize it.
By creating access packages and then scoping them to only the users that should be able to request them, we have come a long way already.
All access in this “flow” should be set to Manager in Who can request access, this will allow us to request on behalf of the admin account.
It will then look like this when the user requests an access package on behalf of the admin account (Sorry for the Danish wording in screenshot)
I would strongly recommend leveraging Verified ID with Face Check for all access packages that will provide access to any resource related to admin accounts, whether it’s on-prem or cloud admin accounts, for that extra security level.
In regards to the approval of the Access Packages, I would suggest using at least two approval stages. It could be the manager as the first one, and then the same people that approve PIM requests or someone similar. This is a business decision and not something I can tell you.
Now we have established a sort of baseline for how the Access Packages should be configured, we can then begin to talk about what Access Packages to build, and what they should contain. I’m going to tell you about how I have done it, but since every company is different in their approach on how to tier access, you should therefore consider this next part more as inspiration than a guide on how you should do it.
First of all, I have built 3 Access Packages for the cloud admin accounts: Admins, Support, and Developers. Each of these Access Packages contains Entra roles and security groups that each role needs in order to perform their everyday job.
The following is a screenshot of what I have decided to put in each access package for the given role – Again, this should be considered inspiration.
The cloud admin account access packages are pretty straightforward to set up since we are working with cloud users and cloud resources. The trick is now to do the same with on-prem admin accounts.
For on-prem admin accounts, I’ve created a tiered approach that aligns with the traditional tiering model for privileged access. I have built two access packages: On-Prem Admin – Tier 1 for server admin access to member servers and critical infrastructure, and On-Prem Admin – Tier 2 for application server admin access to things like application servers and database servers. Domain Controllers would be Tier 0, which I’m not covering in this blog post since those should be handled with extra care and probably not through this flow at all.
This creates a clean separation: either you’re a cloud admin or you’re an on-prem admin, never both with the same account. To enforce this separation, you can use the Separation of Duties feature in the Access Package settings. By marking the cloud admin access packages as incompatible with the on-prem admin access packages (and vice versa), you prevent a situation where someone accidentally – or intentionally – requests both types of access for the same admin account. This way, the system itself enforces the boundary rather than relying on approvers to catch it.
The approach and configuration of the access packages stay the same as cloud admin packages, but you can’t use Entra security groups for on-prem resources like RDP to a server, etc., unless you are using group write-back. That’s another discussion about whether you should use Entra write-back security groups for on-prem resources. You can of course do it, but you are opening up the possibilities of lateral movement again. Another possibility is to use the approach I wrote about in this blog post: A Way to Manage On-Prem AD Group Memberships Using Entra ID Governance, The concept of that blog post can be applied in the same way for on-prem admin accounts, but you might need to have a privileged Service Account that handles the adding/removing of the admin accounts to their privileged on-prem security groups. This can be secured by using a Key Vault for storing the credentials of that Service Account. – Securely storing and retrieving credentials with Azure Key Vault in PowerShell scripts
No matter the solution you select, whether it’s write-back groups or using on-prem groups, the safeguard for both solutions is that the “On-prem admins” group used in the Conditional Access policy will be added to each of the Access Packages that handle on-prem privileged access. Because even if a user that is not supposed to be assigned one of the access packages somehow gets assigned, the user will then get blocked from accessing any cloud resource at all, and in that way keeping the account confined to either on-prem privileged access or cloud privileged access.
Wrapping up
Another safeguard worth mentioning is Global Secure Access (GSA). If you have GSA in place, you can use it to add another layer of protection for the on-prem admin accounts. By requiring the compliant network check through Conditional Access, you can ensure that the on-prem admin accounts can only access the allowed resources when connected through GSA. This adds yet another barrier that makes it even harder for a compromised account to do any damage.
You might have noticed that between the creation of the on-prem admin account and the first request for privileged access, the account is not blocked from cloud resources. This is by design – at that point the account has no privileges anyway, so there’s nothing to protect against.
As I mentioned earlier in this post, how you tier your access and what you put in each Access Package is very much a business decision and will differ from company to company. What I have shown you here is how I have done it, and you should consider this as inspiration for how you can do it in your own environment.
In the next and final part of this blog post series, I will focus on the offboarding of admin accounts – what happens when the regular user that owns the admin account leaves the organization, and how we can ensure that the admin account gets properly handled.