Intune RBAC for Noobs

Effective identity and access management is the very foundation of the Zero-Trust approach.

In any enterprise environment, access is happening everywhere – from a user accessing data from a personal/corporate endpoint working from anywhere in this remote-first world to an IT Admin accessing the Admin console to perform administrative tasks.

Zero-Trust is not only about securing end-user access to organizational data.

Zero-Trust is also about securing IT Admin access, ensuring that they work with the least required permissions at any point of time, with a limited administrative boundary.

This way, even if an Admin account gets compromised and there is a breach, the attack gets restricted to only a subset of the environment and doesn’t compromise the entire environment.

This is where Role-Based Access Control or RBAC as it is called in its abbreviated form comes in.

RBAC, at its core, is about assigning an identity with permissions specific to the role and nothing more.

RBAC is an integral part of the Zero-Trust approach. Planning and effective implementation of RBAC in the environment is an important step along the journey towards adopting Zero-Trust for securing the Enterprise environment.

In today’s blog post, we will be going through the fundamentals of RBAC in Intune.

This post is written for the complete beginners who want to get an easy understanding of Intune RBAC and how it can help in delegating administrative tasks effectively while following the Zero-trust model.

So shall we get started then?

Intune RBAC – Understanding Role-Based Access Control in Intune

RBAC in Intune helps to ensure that the right users (IT admins) have just the right access (Roles) that is required to get the work done, limiting their visibility to just the right Intune objects (Scope tag) while keeping their actions restricted to a well-defined logical administrative boundary (Scope group).

Having a well-defined and well-designed RBAC is critical for securing the environment as it can help to ensure reduction of the attack surface, in case an account with administrative privilege gets compromised in anyways.

For a noob, let us now break into each aspect of Intune RBAC role assignment.

What is Role?

With the help of Roles, we can configure and control the permissions that are required by a user, usually a person from the IT team, to successfully perform a specified task and this is what Role-Based Access Control (RBAC) is all about.

In an M365 environment, w.r.t Intune, a user can have roles assigned at two levels – Azure AD and Intune.

For example, you can grant users the Intune Administrator role from Azure AD by virtue of which those users will get complete access and management rights to all aspects of the Intune service. But you may not actually want everyone to have complete rights to all the aspects of the Intune service. This is where the RBAC system of Intune comes in.

A user with Intune Administrator role (assigned from Azure AD) can make use of the Intune RBAC to further configure and assign roles to other users (IT admins) from within Intune for the purpose of effective rights delegation.

It is very important to understand that Azure AD roles and Intune roles are two completely different things and rights/permissions granted via Azure AD roles cannot be limited via Intune RBAC.

In simple words, a Role is a way to define the permissions that the members of that role will have and is required to perform the designated operations that they are supposed to do in their day-to-day job.

But for the purpose of delegation, it’s not only the correct permissions that we have to worry about. We also have to ensure that the permissions as delegated

• is applicable to perform operations on the correct set of objects only, and
• the outcome of the operations as performed effects or applies to the correct set of users and/or devices.

This is where the Scope comes into play.

Nevertheless to say, in RBAC, Scoping of Role is an important aspect of Role assignment.

What is Scope?

Scope can be defined as the smallest operation set or a management unit to which the permissions as configured in the Role applies to.

By limiting the permissions as defined in the Role by means of Scope, we can ensure that we are not only granting just the sufficient rights that are needed to get the job done but at the same time,

• limiting the access to only those particular resources/objects which are required to be accessed by the role member to perform the required operations and get the job done. [Scope tag]

• limiting the administrative boundary by creating a subset of users and/or device on which the operations as performed will cause an effect. [Scope group]

This way, even if the user account with the assigned role ever gets compromised, because of limited scope, we can ensure a limited risk because of the reduced attack surface.

Working with Intune RBAC, we can limit a role via two types of scopes – Scope tags and Scope groups.

Understanding Scope tag in Intune for RBAC

Scope tag is a way to define a group of Intune objects (profiles, policies, etc.) for the purpose of administration, limiting the visibility of the right objects to the right admin users.

For easy understanding, let us draw a reference to an AD environment where we have an OU and that OU contains some objects.

In AD, the way we can delegate permissions to a specific group such that the group members can then manage the objects within that OU, but not anything outside that OU, it’s the same concept here in Intune role assignment with scope tags.

When we create a scope tag and assign it to different Intune objects, we are virtually clubbing those objects together as a single management unit. Now when we add the scope tag to an RBAC role, means the permissions configured as part of the role are only valid for and applicable to those objects which are clubbed together as a management unit by virtue of the scope tag.

This is a very handy feature, especially when you have a requirement to limit the permissions of the role members to only particular objects within Intune.

For example, if you are creating a role to delegate administrative tasks confined to a particular location, you can create a scope tag for the same and add it to the objects (profiles, policies, apps, etc.) that aligns to that location, and then add it within the RBAC role so as the role members will get to see and work with only those particular objects and not the others. This way, you can prevent human errors as well.

As of writing this post, the following Intune objects are the only exceptions not to support scope tags at the moment.

	• Corp Device Identifiers
	• Autopilot Devices
	• AutoPilot Profiles
	• Device compliance locations
	• Jamf devices

Understanding Scope group in Intune for RBAC

Scope group can be defined as the group of users/devices that fall under the administrative privilege of the role members. Meaning that the administrative action(s) as performed by the Role member will have an effect on only those users/devices which come under the Scope group for the Role.

A Scope group can be Azure AD groups containing a subset of all devices or all users in the environment, but can also be All Devices, All Users, or All Devices and Users.

As from the definition as above, by virtue of Scope group, the Role member’s administrative privilege is confined to the subset of devices/users as in the Scope group. Thus, if a Role member tries to perform any administrative action that is allowed by the Role permissions, but is for users/devices outside of the Scope group, that action will return an error.

Understanding the need for Intune RBAC with real-world example scenarios

The effective use-case of implementing Intune RBAC can be easily understood from the below real-world requirements.

• 1st level support should be able to only view user’s enrolled devices but cannot perform remote device actions like reset, retire. Further, they should be able to add users to required groups for app assignment but cannot create, modify, or delete any configuration settings and/or profiles/policies.

• 2nd level support should be able to perform remote device actions, clear device enrollment records, initiate remote help sessions, but cannot create/update/delete any profiles/policies.

• 3rd level support should be able to create/update/delete any profiles/policies and work with configuration settings that has a tenant-wide effect.

• The EMEA onsite support team should be able to delete Autopilot device records from the tenant, ensuring they  can only delete device records for Autopilot devices tagged to the EMEA region. Further, they should not be able to register new devices to Autopilot.

• The IT Team at a particular location/branch office should be able to manage users and configurations that are particular to that location/branch office. They should not be able to make changes to any global configurations.

I can probably go on and on stating such requirement statements, but by this time, you probably should have got the idea of how important RBAC is to work out such requirements effectively.

The End

In any Enterprise environment, it is never ideal to have IT Admin accounts assigned with permissions that are not required for their role. As an example, if you are assigning your Helpdesk operators with full admin privilege to a service, you are signing yourself up for a security breach and failure.

RBAC helps you to have more granular control of permissions and ensure that the IT Admins can go on with their work with just the right permissions in place so that they are limited to performing the task/operation that is expected for their role and nothing more.

RBAC if planned and implemented effectively can help in a very productive work environment without any hindrance to the work, and at the same time, also help to minimize the impact of any unfortunate security events.

Would you like someone who is a member of the 1st level IT support team (and maybe probably just got introduced to the world of MEM) to delete the enrolled device of any C-level executive while they are trying to explore and learn?

If your answer is no, then RBAC is your way ahead…  

In the next post, maybe I will be doing a walk-through of working out any of the access requirements as mentioned in this post to see RBAC in action from the MEM Admin Center.

But till then, continue to stay safe amidst the current sudden surge in C19 Omicron cases.