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:

• Role-based access control (RBAC) with Microsoft Intune
• Administrator role permissions in Azure Active Directory
• Create a custom role in Intune
• Create and assign a custom role in Azure Active Directory

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.

Licensing

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.

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.

Scoping

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.

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)

• Role Based Access Control in ConfigMgr 2012: Part 1 – Introduction
• Role Based Access Control in ConfigMgr 2012: Part 2 Scenario
• Role Based Access Control in ConfigMgr 2012: Part 3 Mapping OpCo roles to ConfigMgr roles
• Role Based Access Control in ConfigMgr 2012: Part 4 Outcome

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)

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) )

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

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

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

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

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

Repeat these steps for Stanley Messie as well

Outcome

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:

Conclusion

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.

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.