I once bumped into a customer who said their Global Administrators all have the access elevation toggle switch permanently turned on, so that they all have the User Access Administrator role assigned at the root level all the time for environment-wide visibility. The justification for this was, that the access elevation cannot be controlled in any way, so even in the event of an account compromise or a token theft, the attacker can always elevate themselves to gain access to all the Azure subscriptions. I’ve since thought about it every now and then, well over a year now. Even though I don’t have any definitive answers, I wanted to share my thoughts why I think the principal of least privilege should still be applied here. Let’s start!
What is access elevation meant for?
Access elevation is a by design backdoor for tenant administrator (Global Admin) to regain access to Azure subscriptions that have lost all Owners. It can also be used to get visibility into all management groups and subscriptions in the tenant. The actual toggle is under the title of Access management for Azure resources.
Microsoft recommends that an administrator uses the access elevation only when needed and disables it after it is not needed anymore.
The control problem
My former customer was right. If an account with Global Administrator role is compromised, the attacker can user the standing role to elevate access to ultimately gain Azure resource access. Therefore, it doesn’t matter if it’s already on or not. Furthermore, if a session cookie is stolen from Global Administrator, that access token can be used to impersonate the Global Administrator to again use the access elevation toggle to gain Azure resource access. So it didn’t matter if the token scope included that permission or not because the GA role still grants access to use the access elevation.
What control do we have over this magical toggle that appears in the portal experience, Azure CLI and Azure REST API? Basically none.
- All we can control is that access elevation is only available for users who have Global Administrator role active
- The other thing we know is that the access elevation (User Access Administrator) does not get removed when the Global Administrator role expires when using PIM
- We can remove the role assignment that is caused by the active access elevation
Hmm….
I think if Privileged Access Management concepts are followed more closely we can find at least one reasoning why permanent access elevation is less of a risk when turned off.
Why least privilege approach still wins in my opinion
Adding the two bullets in the previous section together we can maybe break this vicious loop. When you have Microsoft Entra ID P2 licenses, you should be using Entra PIM to control eligibility to the Global Administrator role, right? Let’s start by implementing PIM for GA role, because that is sensible thing to do anyway. For that role activation we will require the administrator to complete step-up MFA (with the help of an Authentication Context). Then let’s disable the access elevation for all GA’s. This means that we have now hopefully mitigated the problem as far as we can with the limited control that we have.
- By using PIM for GA role, we reduced the risk associated with compromised GA account as the GA role is mostly only eligible and not active and the attacker will most likely be stopped by the step-up MFA (e.g. FIDO2 passkey).
- By disabling the Access Elevation, we removed the User Access Administrator roles and thus reduced the impact (blast radius) of compromised account. If visibility to subscriptions is necessary it can be handled by another PIM group granting reader role to root group, leaving access elevation only for true emergency situations.
Now the only time when adversary hits jackpot is when the Global Administrator account gets compromised when the GA role is active. If the account gets compromised when the GA role is not active, an adversary will not gain GA role permissions, but as we disabled the access elevation, the adversary does not gain User Access Administrator role to subscriptions either. By keeping the access permanently elevated we offer keys to the kingdom on a silver platter, but we don’t have to do that.
To reinforce the protection around access elevation it is a good idea to…
- Monitor and alert for operation ‘Assigns the caller to User Access Administrator role‘ which is found in Activity Log
- Periodically remove the User Access Administrator roles gained using the access elevation toggle. Here’s a link to the article section that covers the removal of those roles with a new feature that is being rolled out in stages to all tenants.
Summary
If you need to give your admins a visibility to the tenant root you should make a “Tenant Root Readers” group and make them eligible to it via PIM, don’t use access elevation. If you need to give them permissions to manage user access you could assign Role Based Access Control Administrator role to them which supports conditions (constrained delegation). It is a pity that we cannot manage access elevation using Entra Conditional Access user actions, Entra Roles protected actions or Entra Conditional Access Authentication Context. This, unfortunately, emphasizes the need to protect Global Administrator role itself and the need to monitor these elevation operations.
Stay secure!
