Should Azure AD groups be used for role assignments?
Recently I read a question on Reddit where someone asked how to do proper access management for Microsoft Azure, although the question seems fairly simple, the answer can be pretty complex.
My first reaction to the question if we should use Azure AD Groups to assign permissions in Microsoft Azure was “Yes”, but is this really the case?
The short answer to this is, it depends and I’ll try to explain why this is the case.
Throughout my career, I have had the opportunity to look into many different customer environments and have seen different implementations of the Role-Based Access Control (RBAC) model. One of the things that always comes back is that many customers have difficulty understanding the relationship between the roles and permissions that can be assigned, and the possible impact it has on other Microsoft cloud services.
When looking at the Identity Access Management (IAM) in the Microsoft Cloud, access is controlled based on Roles and Permissions that can be assigned to objects like users, groups, and service principals. I won’t go too deep into the kind of accounts that should be used for assigning specific roles but will dig a bit deeper into the side effect of assigning permissions through Azure Active Directory (AAD) groups.
On many occasions, I’ve seen that highly privileged roles are assigned in Microsoft Azure to normal worker account of individual users and even to ‘guest user accounts’. The assignment scope varies from resource-group level to assignment of highly privileged roles on subscriptions and even management group level. Due to the many scopes where access can be granted, it becomes really difficult to stay in control.
A good solution to have a better sight of the roles assigned can be the use of Azure AD groups. This can help to have a more organized way of granting permissions and give a clearer overview of the roles assigned. But this also comes with a downside.
If we take a look at how the RBAC model works, we can determine that each Microsoft Cloud Solution, like Microsoft Azure, Exchange Online, Office 365, Azure DevOps, Dynamics 365, etc. has its own specific roles that can be assigned to users to grant certain permissions. The common factor between all these cloud solutions is that they all use the Azure Active Directory as their centralized Identity and Access Management system. And this is precisely where the “it depends” comes from.
Going back to our Microsoft Azure environment and more specific to the permissions in Azure, we can determine that 2 roles have the permissions to assign roles to other identity objects. These are the ‘Owner’ and the ‘User Access Administrator role.
By going down the path of using group-based role assignments for Azure, this also means that anyone with the ‘User Administrator’ role assigned in the Azure Active Directory, which is merely scoped to execute user-related tasks, can now grant permissions in Azure. This is because the ‘User Administrator’ has the permissions to add users to AAD Groups!
So where normally only a ‘Global Administrator’ has the possibility to grant himself permissions to control and access subscriptions by setting the ‘Access management for Azure resources’ to Yes, we have now introduced a ‘privilege escalation path’ by giving the ‘User Administrator’ the same possibility to assign ‘Owner’ permissions to all users including himself in Microsoft Azure through AAD group membership!
Does this mean that assigning highly privileged roles can better be done through individual user assignments after all?
The answer to that question is “No” if you take the appropriate measures.
Possible solutions
Depending on the Azure AD licenses are available within the Azure AD tenant, there are several solutions to this problem.
- Azure Policies.
One part of the solution is to implement an Azure Policy that restricts the assignment to individual users and groups and service principals. Although this might sound like a complex solution, it is actually quite straightforward and extremely powerful to stay in control of Azure role assignments.
Use-cases you can think of are:
- restrict roles for guest accounts
- limit specific roles to cloud accounts (break glass)
- avoid user scoped assignments on management group or subscription level
An example can be found on my Github.
2. Privileged Identity Management (license required)
The Azure AD PIM is a solution that can be used to provide time-based and approval-based role activation of Azure AD and Azure resources roles. Once you activated PIM an administrator can assign eligible roles to users and groups.
This approach is very effective in remediating the assignment of standing permissions in both Microsoft Azure and Azure Active Directory. Be aware that the ‘Privileged Role Administrator’ role is just as powerful as the Global Administrator role, as this user can assign Global Administrator permissions to any user.
3. Privileged Access Groups — Preview (license required)
The newer kid on the block is called ‘Privileged Access Groups’ and brings the best of both worlds.
Within Privileged Access Groups and Administrator can assign the permissions to provide time-based and approval-based membership of an Azure AD Group. These groups can then be used in Azure for role assignments.
Using this together with the previously mentioned Azure Policy gives a very strong and flexible solution to stay in control of role assignments in Microsoft Azure.
Key takeaways:
1. Limit standing permissions to special accounts (break-glass)
2. Limit the assignments for highly privileged roles
3. Prevent assignments to guest accounts
4. Monitor changes in role assignments
5. Use PIM / Privileged Access Groups when available
