As was discussed in the last post Groups are a collection of users, while Roles are a collection of rights. The merging of these two concepts is a fundamental shift in both language and concepts from simple resource management to including security around that resource accessibility.
The functionality of groups and roles will also change based on the environment and resources to be managed.
Starting with On-Premise Active Directory, rights as roles tend to be applied through additional applications instead of default functions within Active Directory. However, this can be duplicated using nested groups as required. It is not preferred, given the complexity and manual intervention that is required. However, the mental exercise is a good place to start with identifying why and how Groups are different than roles.
The concept is very simple. For every resource (R) you have a local group (DL) associated with it, then have a global group (DG) from every Active Directory domain, universal group (UG) from every Active Directory Forest affiliated with it added in as a member of that local group. The users from these domains and forests will be added as members of the respective global or universal group.
Or, in short:
As it can be seen, this model, while simply will be complicated very quickly. Especially when the inheritance properties of each resource come into play. Which is why a separate application like SCCM is critical in an environment. Within SCCM these resources are managed as Roles, and a single group can be created to be associated with each role.
This changes once you move out of the on-premise domains and data centers, and into the Azure Cloud.
Within the Azure Cloud all access is through Role Based Access Controls (RBAC’s). While this is the same for all Azure services, they are broken out into two separate types as noted in screen shot here:
At a high level, Azure RBAC roles control permissions to manage Azure resources, while Azure AD administrator roles control permissions to manage Azure Active Directory resources. The following table compares some of the differences.
|Azure RBAC roles
||Azure AD administrator roles
Manage access to Azure resources
|Manage access to Azure Active Directory resources
Supports custom roles
|Cannot create your own roles
|Scope can be specified at multiple levels (management group, subscription, resource group, resource)
||Scope is at the tenant level
|Role information can be accessed in Azure portal, Azure CLI, Azure PowerShell, Azure Resource Manager templates, REST API
||Role information can be accessed in Azure admin portal, Microsoft 365 admin center, Microsoft Graph, AzureAD PowerShell
A few good key points to remember on these roles is also to ensure that they are audited at least twice a year. Microsoft maintains full control over the default/built-in roles, and they will be depreciated, upgrade, or new ones created based on feedback Microsoft gets from the user community. However, for Azure RBAC roles they can be exported out and custom ones created based upon business needs. No custom RBAC will be edited or adjusted by Microsoft.
Now we have a gone through the what is being discussed by this series, the next article will begin to cover the managing of these roles and securing them.