Before the summer vacation period, I wrote a blog post about ‘Monitor Elevate Access Activity In Azure’, in practice, how to detect when a user with global admin permissions elevates access to Azure root management group. This blog contains information on how to remove those permissions when needed.
Event about this activity is still not included in any standard logs (checked in my demo environment 09/25/2020) such as Azure Activity log or Azure AD logs but the activity can be detected with the Microsoft Cloud App Security when Azure instance is connected to it.
In case you detect activity where Global Admin grants access to the Azure Root Management group you might want to remove the permissions immediately. Of course, depending on the scenario because there might be situations where permissions are needed such as (reference list from docs.microsoft.com):
- Regain access to an Azure subscription or management group when a user has lost access
- Grant another user or yourself access to an Azure subscription or management group
- See all Azure subscriptions or management groups in an organization
- Allow an automation app (such as an invoicing or auditing app) to access all Azure subscriptions or management groups
Options For Permission Removal
Options for permissions removal are:
- Azure CLI
- Rest API
Is no go, these permissions can’t removed from the portal UI. If you try it, you will receive the following error.
Also, if user account changes the Azure AD setting from the toggle (Yes -> No), the permissions from the root management group are not removed.
As a former on-prem AD admin, this is my preferred option, CLI works also fine. First, connect to Azure management API and list all ’User Access Administrator’ permissions from the root management group.
Then, verify user permissions to be removed. In my environment, email@example.com is the unwanted account in here.
Remove needed permissions. After removal, verify that permissions are really removed.
If a rogue user is logged in to Azure portal permission removal affects immediately. User will receive an error when trying to navigate to the different blade in the portal.
I’m a bit surprised that this high privilege activity still isn’t found from standard Azure & Azure AD logs. Positive side is that with MCAS the activity can be detected. To use MCAS, you need to have a proper license for it.
The main key takeaway is that remember to monitor this activity and perform necessary actions to the account when needed.