Permissions Management and Azure Subscriptions

Let’s take a look at how Microsoft Entra Permissions Management works against Azure subscriptions. My primary focus in this test is to identify what type of information it gives me on the current RBAC and anything actionable we can do to quickly ensure that RBAC is not over permissioned.

I have only couple personal subscriptions where I test different workloads. Usually in those subscriptions RBAC is pretty simple and straightforward, as it is just one account that I use to test different workloads. To make this test a bit more comprehensive, I created a few user accounts and a few applications and configured one of my subscriptions with the following RBAC using new accounts:

Scope	DisplayName	RoleDefinitionName	ObjectType
/subscriptions/SUBID	TestAdmin2	Automation Contributor	User
/subscriptions/SUBID	TestAdminApp6	Automation Contributor	ServicePrincipal
/subscriptions/SUBID	PremiumTenant Admin	Classic Admin	User
/subscriptions/SUBID	Win11	Contributor	ServicePrincipal
/subscriptions/SUBID	WS22	Contributor	ServicePrincipal
/subscriptions/SUBID	TestAdmin1	Contributor	User
/subscriptions/SUBID/ resourceGroups/CloudVM	TestAdmin8	Contributor	User
/subscriptions/SUBID	TestAdminApp1	Contributor	ServicePrincipal
/subscriptions/SUBID/ resourceGroups/CloudVM	TestAdminApp2	Contributor	ServicePrincipal
/subscriptions/SUBID	TestAdmin4	Key Vault Administrator	User
/subscriptions/SUBID	TestAdmin5	Key Vault Secrets Officer	User
/subscriptions/SUBID	TestAdmin6	Log Analytics Contributor	User
/subscriptions/SUBID	Admin	Owner	User
/subscriptions/SUBID/ resourceGroups/CloudVM	TestAdmin7	Owner	User
/subscriptions/SUBID	TestAdminApp3	Owner	ServicePrincipal
/subscriptions/SUBID/ resourceGroups/CloudVM	TestAdminApp7	Owner	ServicePrincipal
/subscriptions/SUBID	Cloud Infrastructure Entitlement Management	Reader	ServicePrincipal
/	Admin	User Access Administrator	User
/subscriptions/SUBID	Cloud Infrastructure Entitlement Management	User Access Administrator	ServicePrincipal
/	Tenant Admin	User Access Administrator	User
/subscriptions/SUBID	TestAdminApp4	User Access Administrator	ServicePrincipal
/subscriptions/SUBID/ resourceGroups/CloudVM	TestAdminApp8	User Access Administrator	ServicePrincipal
/subscriptions/SUBID	TestAdminApp5	Virtual Machine Administrator Login	ServicePrincipal
/subscriptions/SUBID	TestAdmin3	Virtual Machine Contributor	User

As you can see, I configured it fairly comprehensively across different types of accounts and a few most critical RBAC roles that I could think of. Of course, it does not cover every possible RBAC, but most used and I wanted to see how it works at resource group level as well.

After refreshing data in Permissions Management, I have the following observations:

• Three accounts are marked as Super Identities. Permissions Management classifies super identities as “A super identity can be a human or machine entity with authority to perform actions equivalent to root access”. The following accounts marked as such:
  • PremiumTenant Admin – has Classic Administrator permission (equal to Owner)
  • Admin – has Owner at subscription level
  • TestAdminApp3 – has Owner at subscription level

• I was surprised not to see accounts with “User Access Administrator” RBAC in this category, as those accounts can grant themselves or any other account an Owner RBAC. If any of these accounts are compromised, game for this subscription is pretty much over. Seems to me an oversight.
• I’m also surprised that none of the accounts with Owner RBAC on the Resource Group (and for that matter User Access Administrator) are marked as Super Identities. While those accounts can’t do anything at subscription level, they can do anything at Resource Group level and if those accounts are compromised, they can control existing resources in target RG or do anything new there as well.
• I was less surprised not to see any account in “Contributor” RBAC being marked as accounts that need attention. As you can observe in the table, I have six of those accounts and main dashboard really didn’t bring my attention to any of them. Which again, if any of those accounts are compromised, they can do everything in the target scope, except update RBAC. I absolutely want to know any user in those roles.
• And, of course, even less surprised not to see any other accounts in what I would say powerful roles, like for instance “Key Vault Administrator”. Got some secrets in any AKV?
• It does have a category of overprovisioned accounts, but it marked the Super Identity accounts as such, and not any other accounts.

There is “Analytics” view in the portal, which provides information on each individual account. You can see which accounts have high Permission Creep Index “PCI” and then drill into it and see why Permissions Management gave it such high score. It is useful if you have a lot of time to look at each account individually, but it does not provide (at least I have not spotted one) unified view of all accounts.

Other data that I could not find in the portal, as relates to each user account, if they are for example enabled for MFA. For applications it is actually provides information on certificates, password credentials, usage and owners. Yet, it did not say if password credential expired or valid (I didn’t configure any apps with certificates, but I guess it won’t tell that info either). But overall this is all useful data as it gives an indicator who to track for application conversations and how often it is used.

I’ll continue to explore capabilities of this solution to see if it will be able to tell me at a glance about all accounts that we need to pay attention, but for now we’ll continue use PowerShell scripts to gather required data in a format that is easy to massage and quickly take action, as we usually have to do with customers in critical situations.

In the next installment I’ll take a look at the similar reporting against AWS account.

See you around!