Role based access control in Microsoft Endpoint manager

Role base access control (RBAC) is a concept most of you are already familiar with administering Microsoft Exchange or Configuration Manager. Intune, or Microsoft Endpoint Manager, also offers the possibility to  restrict access based on a persons role in the organization, I would like to show you how this can be achieved.

What is RBAC ?

So the main idea behind RBAC is giving every user only the access to resources which he needs in order to complete his job. Utilizing Role assignments and scopes it offers fine-grained access management to management resources.  So, please, always keep in mind , as best practice, just grant users the least privilege they need in order to complete their tasks.

The IT Admins rights are limited by his role and his scopes. The role defines the access permissions an admin has and the scope are the objects he can see.

RBAC in Microsoft Endpoint Manager (MEM)

MEM is also using this concept and has some predefined roles which you can assign to users or a group of users. These roles control what a user has access to and what rights he has on the corresponding object. For example an “Intune Administrator” is allowed access to all resources regarding Intune but not allowed to access all aspects of Azure Active Directory.


The Built-in roles in Intune are :

Help Desk Operator: Performs remote tasks on users and devices, and can assign applications or policies to users or devices.

Policy and Profile Manager: Manages compliance policy, configuration profiles, Apple enrollment, corporate device identifiers, and security baselines.

Read Only Operator: Views user, device, enrollment, configuration, and application information. Can’t make changes to Intune.

Application Manager: Manages mobile and managed applications, can read device information and can view device configuration profiles.

Intune Role Administrator: Manages custom Intune roles and adds assignments for built-in Intune roles. It’s the only Intune role that can assign permissions to Administrators.

School Administrator: Manages Windows 10 devices in Intune for Education.

Based on your organizational structure it can be necessary to create either custom roles with a smaller subset of permissions or use other default roles. For example you have a group of people which are assigned the “Intune Administrator” , therefore are able to manage all aspects of Intune and you have another group of people who are solely responsible  for Application management. In this case you may want to assign these group of people the built-in role “Application Manager” so that they are able to manage all aspects around applications and release management.

Unfortunately, it is not that simple in most environments, if so, you are good to go. If the built-in roles do not satisfy your organizational needs you are free to create roles yourself.

In some cases, this concept is still not sufficient. Imagine you have several locations. For example the main office is located in London and another office is located in Paris. The Intune Administrators are located in London but you also have some Help Desk Operators in Paris. The Help Desk Operators are only allowed to manage devices and users located in the Paris office. Another use case could be separation by operating systems, for example if you have a a group of administrators for windows and another group for macOS.

These requirements cannot be fulfilled by adding or changing the role assignment of the Help Desk Operators. Here Scopes come in handy and help us to meet the criteria.

What are Scopes ?

In a nutshell Scopes are a set of objects you are allowed to manage or allowed to see. Built-in Scope is the ‚default‘ scope which every object is tagged with. Access rights to objects within the scope are defined by your role assignment. For example you have edit rights to applications in general, since you are a application administrator. But if an application belongs to a different scope than your assigned scope you will not be able to see or edit this application.

There are no further built-in Scopes. You can assign scopes to Group of devices or users (Scope (Groups)) or to sets of objects (Scope (Tags)).

scoping examples

Not every Intune object can have a scope. The following objects cannot be tagged

  • Windows ESP profiles
  • Device Categories
  • Enrollment Restrictions
  • Corp Device Identifiers
  • Autopilot Devices
  • Device compliance locations
  • Jamf devices

Use case different locations

Let’s take a closer look to one use case. We do have two locations, as mentioned above, London and Paris. IT in Paris should only access devices and users located in Paris.

So, let’s create a role assignment and a corresponding scope ! First of all we go to the devicemanagement portal and choose „tenant administration“ -> „all roles“ -> „Scope tags“ and create a new one

MEM Portal add new Scope

We will call it “Paris Help Desk” and assign all Paris clients to that scope.

Create Scope Tag

Of course we do have a dynamic Azure AD Security Group including all devices located in Paris 🙂

Assign group of Paris devices

Now we a a scoped and tagged all devices with that scope !

Now we duplicate the help desk operator built-in role. Under “All roles” select duplicate.  Maybe we want to make some customization later regarding the permissions of this group, therefore I prefer creating a duplicate.

duplicate built-in role

Type in “Paris Help Desk Operators” as a name and leave the permissions untouched. Simply assign the scope “Paris Help Desk” to the new role. Everybody with this Role will get the permissions defined in the ‚Help Desk‘ Role on the objects with the ‚Paris Help Desk‘ Scope.

duplicate buil-in role

Now we nee to assign the new role to a group of users (Help Desk Operators). Choose the new role an go to assignments.

new role assignment

The assignment page has been updated and now the assignments are a lot easier. IMHO they were quite confusing. After entering a name for the new assignment you have to set Members (Groups), Scope (Groups) and Scope (Tags)

  • Admin Groups

Add the group which will uses this role. In our case everybody from Paris office who should work as a help desk operator “Paris Help Desk Operators” . Ask yourself “who” you want to have these rights defined in the role.

  • Scope Groups

Add the security group on which the above chosen security group has access to. In our case all devices/users from Paris Office “All Paris devices/users”. “Where” these rights are needed

  • Scope Tags

Add the corresponding group tag “Paris Help Desk”. This is the tag belonging to this assignment and defines the set of objects the Members (Group) can view.

That’s it… we are done !

If you add a member to the “Paris Help Desk Operator” group he will get the role assignment we created. He will only be able to see the device in the “All Paris Devices” group and objects with the scope tag “Paris Help Desk”

For further information about RBAC in MEM see the official Microsoft documentation about RBAC in MEM