When you create an Intune tenant within your environment, you execute the creation with an account which is Global Administrator within Azure Active Directory. And in my work as an indendent consultant I see a lot of companies which keep using the account with Global Administator rights to manage their Microsoft Intune environment as well.

While for initially setting up some Azure AD functionality Global Administrator rights might be needed, this is only the case during the setup phase. Once you have implemented your environment, you hardly ever need the Global Administrator rights and for most tasks they are not needed perse. Think of the Global Administrator rights as an equivalalent of the Forest Administrator/Schema Administrator group within Active Directory.

Disclaimer: This post is written on December 4th 2019 and reflects the state of this functionality at that point in time.

If you want to start implementing Role Based Access Control (RBAC) within Microsoft Intune you can delegate rights in several ways:

  1. There are roles within Azure AD which have rights to certain parts of Microsoft Intune, these roles are:
    1. Global Administrator: Global permissions within Microsoft Intune
    2. Intune Administrator: Global permissions within Microsoft Intune (the Intune Administrator)
    3. Compliance Administrator and Compliance Data Administrator: View all Intune Audit data
    4. Message Center Reader: monitor notifications and advisory health updates
    5. Global Reader, Security Administrator, Security operator and Security Reader: Views user, device, enrollment, configuration, and application information, but cannot make changes to Intune
  1. There are roles within Intune (called built-in roles):
    1. Help Desk Operator: Performs remote tasks on users and devices, and can assign applications or policies to users or devices.
    2. Policy and Profile Manager: Manages compliance policy, configuration profiles, Apple enrollment, corporate device identifiers, and security baselines.
    3. Read Only Operator: Views user, device, enrollment, configuration, and application information. Can’t make changes to Intune.
    4. Application Manager: Manages mobile and managed applications, can read device information and can view device configuration profiles.
    5. 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.
    6. School Administrator: Manages Windows 10 devices in Intune for Education.
  1. You can create custom Azure AD and custom Intune roles if none of the provides roles supports your scenario

More information from Microsoft docs can be found here:

So, to conclude – if you need to setup Microsoft Intune you can also work with the Intune Administrator role – later you can make this role eligible for a select group of administrators if you have Privileged Identity Management (Azure AD PIM) available.


In contradiction to Azure AD, where you could manage all of its functionality without a license. I’m not stating that a license for Azure AD administrative rights isn’t needed, since you need to protect that account as well, but for Administrative purposes only there are no license requirements. 

The licensing requirements for Intune state that a license is needed  if a user or device benefits directly or indirectly from the Microsoft Intune service, including access to the Microsoft Intune service through a Microsoft API. I’ve also seen this specific requirement mentioned when configuring the Intune Connector for Active Directory which you install if you want to Domain Join devices during Autopilot provisioning.

Intune connector for Active Directory

Assigning users versus groups to roles

For now, you can only assign users to Azure AD roles, even though this is a highly requested feature, Microsoft is struggling with the fact that if they allow Groups to be used to assign to Azure AD roles that there are many roles which can manage the groups, therefore making it hard to govern membership of privileged roles, which makes a lot of sense. See also this Uservoice item for some more context: Azure AD Role Delegation to Groups.

Within Microsoft Intune it is only possible to assign Intune roles to Azure AD groups, which is handy but also has the same govenance remarks, keep that in mind.


Azure AD roles which provide rights to Microsoft Intune are global, which means that if an account is member of that specific role it can either read, write to all Intune data, or read/write to all Intune audit data.

When using Intune roles though we can scope based on so called Scope groups. Scope groups include Azure AD groups containing devices and/or users, most of the time a subset of all devices or users but can also be All Devices, All Users or All Devices and Users. By defining Scope Groups the administrative user can only assign apps or configuration to that Scope Group. If a user assigned to a Scope Group tries to assign to a group not part of its Scope Group he or she gets an access denied.

You don't have enough permissions to assign this mobile app to one or more of your selected groups, contact your administrator.
Error when assigning to Azure AD group not part of Scope Group in role definition

Scope tags are used for defining what the scoped user can see (devices, content like Apps and configuration which is tagged for a certain scope). For tagging devices, there are PowerShell scripts available for example on the PowerShell Intune Examples page on Github

Building a demo scenario

Once combined we can create the following scenario’s (examples)

  • Create an Application Manager which can only manage devices for which the name starts with LPT and only manage the apps which are tagged LPTAPP.
  • Create an Application Manager which can only manage devices for which the name starts with DS and only mange the apps which are tagged DSAPP.
  • Create a Help Desk Operator which can only manage devices, apps and policies to devices and users in the London office

The RBAC implementation can be compared to the Role Based Access functionality we have within System Center Configuration Manager which I blogged about here: (even though written for ConfigMgr 2012 still valid for most part today)

Simple scenario to demonstrate the Role Based Access Control Model

So I’ve created the following scenario, where we have two Intune Adminstrative users:

1. Ferry Kuhlman, who can only manage devices within the Help Desk Operator role which are part of the Azure AD group AAD_Intune_DeviceTestGroup1, which only contains DESKTOP-0T962JG and devices, content and configuration tagged with TestGroup1.

2. Stanley Messie, who can only manage devices within the Help Desk Operator role which are part of the Azure AD group AAD_Intune_DeviceTestGroup2 which only contains DESKTOP-336P247 and devices, content and configuration tagged with TestGroup2.

The Intune Administrator can see the following devices starting with Desktop (in my case 3)

Devices starting with DESKTOP in the Device overview

Preparation steps taken

1. The first thing we are going to do is create 2 admin groups, one for Ferry Kuhlman named AAD_Intune_AdminTestGroup1 and one for Stanley Messie named AAD_Intune_AdminTestGroup2.

2. Create Scope tags (Microsoft Endpoint Manager admin center | Tenant Admin | Intune roles | Scope (Tags) )

TestGroup1 and TestGroup2 created as scope tags

3. Tag some Apps with either TestGroup1 or TestGroup 2 scope tag

Google Chrome tagged for TestGroup1

3. Tag some policies with either TestGroup1 or Testgroup2 scope tag

Profile – W10 – Kiosk configuation policy tagged with TestGroup2

4. Tag some devices with either TestGroup1 or TestGroup2 scope tag

DESKTOP-P6R9QKF - Properties 
+ Add 
Scope Tag 
TestGroup I 
Discovered apps 
Device compliance 
Device configuration 
App configuration 
Security baselines 
Recovey keys 
Managed Apps 
Save X Discard 
Device name O 
Management name * 
Device category 
Device ownership 
O To auto assign scope tags to devices, go to Roles Scope(Tags) > Assign scope tag to 
all devices in selected group. The scope tags will overwrite the assignments listed in 
this section. 
Scope (Tags) 
1 scope tag(s) selected
DESKTOP-P6R9QKF tagged for TestGroup1

Bringing it all together

In this example we are going to create the Help Desk Operator role for Ferry Kuhlman

1. Go to Microsoft Endpoint Manager Admin Center | Tenant Admin | All Roles

2. Select Help Desk Operator and click on Duplicate. Provide a name for this role (Help Desk Operator (TestGroup1) and under Scope (tags) select TestGroup1

Create duplicate of Help Desk Operator role

3. Go back to all roles and click on Help Desk Operator (TestGroup1) and go to Assignments

4. Click on + Assign to start the role assignment

5. Provide a name (TestGroup1) and optionally a description

6. Provide a member group which contains the user who should become member op the group (in our case AAD_Intune_AdminTestGroup1)

7. Provide a scope group which contains the device which the user can manage, in our (case AAD_Intune_DeviceTestGroup1)

8. Provide a scope tag, in our case TestGroup1

Provide a scope group

Repeat these steps for Stanley Messie as well


When Ferry Kuhlman logs in to the Microsoft Endpoint Manager Admin Center he sees the following:

When Stanley Messie logs in to the Microsoft Endpoint Manager Admin Center he sees the following:


Implementing Role Based Access Control with scoping for Intune doesn’t really provide a smooth experience yet. This mainly has to do with the fact that part of the functionality is provided by Intune roles (which support scoping) and part comes from Azure AD. As an example, what the administrative user can see under Users and Groups is depending on the rights that account has within Azure AD. If the administrative user is a normal user, what he/she can see is depending on the following setting: Restrict access to Azure AD administration portal.

Insight24 B.V. - User settings 
Enterprise applications 
App registrations 
Identity Govemance 
Application prog 
Azure AD Connect 
Custom domain names 
Mobility (MDM and MAM) 
Password reset 
Company branding 
user settings 
Notifications settings 
E] save X 
Enterprise applications 
Manage how end users launch and view their applications 
App registrations 
users can register applications 
Administration portal 
Restrict access to Azure AD administration portal O 
Linkedln account connections 
Allow users to connect their or school account with Linkedln. 
Data sharing between Microsoft and Linkedln is not enabled until users consent to connect their Microsoft work or school account With their Linkedln account 
Learn more about Linkedln account connectionso 
Selected group 
External users 
Manage external collaboration settings
Restrict access to Azure AD administration portal

If this setting is set to Yes, then the administrative user doesn’t see any users, groups or Azure AD devices, but they do see the groups when they want to assign apps or configuration – which is confusing since they can select the group but get an access denied when they want to save the configuration if the selected group is not part of the Scope group.

Even though, with some rough edges, the functionality is usable and implementing RBAC is still advised, perhaps withouth the scoping to start with.