NesƟng Azure AcƟve Directory Security Groups: 

Role-based access control aka RBAC is a technique for granƟng access to resources based on roles 

assigned to users. Both roles and resources are independent of each other and so are the security 

principals who could be users or groups. Groups help to manage RBAC assignments so that users can be 

added to or removed from groups without changing the assignments. Roles, groups, and assignments 

are used to control access to resources and are oŌen created only as many as necessary. 

Some examples of roles include owner, contributor, and reader roles. These are universally applicable to 

users and groups across resources. When the current pracƟce involves creaƟng an AcƟve Directory group 

for the purpose of controlling access to a specific resource, organizaƟons tend to generate a lot of 

security groups. While resources can also be grouped and roles assigned to the scope of resource 

groups, it is likely that those resources have independent use cases which makes proliferaƟon less likely 

to avoid. 

Two techniques come to the rescue of the business to tame the number of groups, roles, and 

assignments. First is the use of a custom role and the second is the nesƟng of groups. 

The custom role is inherently an enƟtlement to a collecƟon of permissions. These permissions must be 

included based on least privileges required and cover as many permissions as necessary to facilitate one 

or more use cases. Since a use case could involve mulƟple resources, the permissions in the set could be 

a mixed lot. The higher the scope the more the number of resources and thereby more mixed the set of 

permissions. By being more inclusive in the customizaƟon of roles and assignments, we come up with 

definiƟons than those with built-in definiƟons from the resource providers. 

Some people like to keep the permissions independent even for customizaƟons because they can be 

assigned to different resources with the noƟon that one resource can be done away with while the other 

persists longer. This can arise from changing business needs where ownership and operaƟons are no 

longer managed together. Besides, the resource grouping is generally done purely from the point of view 

that resources in a group will have the same lifeƟme and that deleƟon of the group will remove all the 

resources. Expansive roles and combining resources can therefore require different security groups for 

each even for the same set of users. One way to manage this is to treat two sets of security groups as 

one requiring another. One security group allows the users to be grouped and the nesƟng of one group 

into another gives those same users the roles and permissions necessary to complete their use cases. 

NesƟng of security groups might not have been allowed on-premises, but it is most likely, allowed in the 

cloud. 

The permission sets must also have some categories as they cannot all be privileges that allow access. 

Some must be called out as deny-permissions to clearly demarcate the uƟlity of the custom role. 

Similarly, the permissions for control and data path must be called out independently of one another. 

There can be other categories as well, but these are widely used. 

Lastly, there are several ways to organize hybrid enƟƟes but order and method help to make it easier. 

Also, prioriƟzing the use cases and determining the impact that they have, help to address the most 

important ones rather than cover all. Also, maintaining a sorted order of high to low privileges or being 

mindful of grading with each arƟculaƟon and organizaƟon, helps to be exhausƟve where necessary.