This post explores using Azure AD role-assignable groups to provide additional protection for high value non-role based groups within a tenant. I'll first introduce the concept of role-assignable groups and what makes these groups interesting before moving into some suggested use cases.
What is a role-assignable security group?
A role-assignable security group is a security group that can have an Azure Active Directory role assigned to it e.g. Exchange Administrator. The primary use case of such groups is to streamline the role administration process. Using these groups we can implement a role-based access model for privileged access where instead of each administrative account having roles individually assigned, we can instead assign the roles to the group meaning we only need to add or remove users to the membership as required. Equally if we have Privileged Identity Management then assignments to groups can be eligible or permanent.
There’s a lot of capability here and there are multiple ways of implementing a privileged access model which may be the topic of a future post however for now I’d like to dive into what makes a role assignable group special and how else it can be useful to an administrator.
What's so special?
The key and interesting property of role-assignable groups is that they are protected and by default only a Global Administrator or a Privileged Role Administrator can create one or amend their membership. The reason behind this is to prevent privilege escalation. Without this protection a lower privileged admin role that can manage group membership, such as a User Administrator, could easily add a user to the group and elevate the privilege of any account.
*** Don’t get caught out ***
If you assign an owner to a role-assignable security group they can manage membership without holding the Global Administrator or Privileged Role Administrator role.
So now we know what they are, where else could this be useful?
There is no requirement to assign a role to a group once it has been designated which opens up possibilities. In my experience it is common to have groups within the tenant that you wish to protect that aren’t necessarily assigned a role...
Conditional Access
Let’s take an example within Conditional Access. A fairly common policy is to enforce multi-factor authentication for all users but there are often cases where we need to exclude accounts for various reasons e.g. service accounts which may not be able to satisfy the MFA requirement. In this case to avoid adding individual accounts we might have a security group containing the service accounts which is excluded from the conditional access policy.
Now while this group does not hold any Azure AD role I want to protect it as once again a malicious or compromised user administrator could add additional accounts into this group and consequently bypass the requirement for MFA lowering my security posture. It is a perfect use case for role-assignable groups; if we swap a new role-assignable group into our policy then we have added an additional layer of protection. N.B. existing security groups cannot be modified to become role-assignable groups - the property that defines them, isAssignableToRole, is immutable.
*** Don’t get caught out ***
Because you must create a new security group make sure to consider all references to your old group and swap them over prior to deleting it.
Privileged Identity Management (PIM)
Within PIM you can configure a directory role or an Azure resource permission to require approval to activate - the approvers can be set to specific users or a security group can be used. If using the latter this is a group that should be protected to avoid lower level administrators from being able to change the membership which would allow unauthorised users to sign off a privileged access request.
Endpoint Manager
Two ideas come to mind here:
Protecting a group that designates local administrators for devices in your tenant - this has a lot of potential for damage in the wrong hands so worth protecting!
For a group tied to enrolment restrictions e.g. you allow macOS devices to enrol by exception and this is tied to a security group that you want a tight rein over.
*** Don’t get caught out ***
At the time of writing you can only have 500 role-assignable groups per tenant, this is a considerable amount but worth noting before getting carried away. It's also worth pointing out this limit used to be 200, then 400 so has increased over time.
Wrapping up
I’m sure there are plenty more examples where this could be useful, I’d love to hear your thoughts ideas on where else role-assignable groups could be used, drop them in the comments below. Otherwise, thanks for reading!