Skip to main content

Intune RBAC - How Intune Processes Multiple Assigned Roles

·1356 words·7 mins


Jump to the How Intune Evaluates Permissions from Multiple Roles section, and then review the Visualizing Multiple RBAC Assignments for a quick synopsis of the issue.

I don’t have a resolution for this, but I am opening a support ticket with Microsoft because this seems bugged.

Background #

We manage a lot of iOS devices in our environment. All of these devices are enrolled via DEP/ABM and most of the devices have no user affinity, these are devices that are shared by teams of users and we have a number of profiles that can be assigned depending on how the device will be used. With these types of devices, they can be factory reset at any time and all of the apps and settings are restored once the device loads because everything is pushed down via the enrollment profile and the device is not enrolled under a specific user.

We also have some dedicated phones that are given to users in our organization to use as their phone. In most cases, these phones are used as peoples primary mobile device. These are still assigned an enrollment profile, but these devices almost all have personal data on them and are enrolled under the user with the device. Obviously, we don’t want to reset these devices except in very rare cases.

As I’m configuring Intune for our environment, I want our Service Desk team to be able to perform device management tasks on these corporate devices. Some of these tasks include restarting the phone, sending custom notifications to the phone, or triggering a sync on the device.

I also want our support team to be able to wipe (factory reset) our shared/team devices from the Intune console. Because these devices load everything automatically, I’d like these users to be able to assign a new enrollment profile to one of these devices and then trigger the reset from the console in order to re-issue a device to another team if needed.

However, I do not want them to be able to wipe dedicated devices, I would rather this action is only be performed by one of our tier-2 technical teams to prevent any potential data loss.

The Problem #

What I initially tried to do was to create two roles, one that included all the Device Management actions and a second that included everything except the wipe permission.

I created two scopes, one scope was assigned to the dedicated device, I assigned the “No Wipe” role to a security group for this role and assigned the dedicated device scope. The second scope was for these shared/team devices and then for the role that included the wipe action I assigned it to a second group that was scoped to the shared devices.

I added our support teams to both groups, and I expected that this would give them the permission to wipe devices on shared devices, and they would not be able to trigger a wipe on dedicated ones.

Unfortunately, Intune RBAC permissions do not work that way. Instead the support users had full management permissions on ALL devices. It appears that Intune takes all the permissions assigned to the user from each role and then grants those permissions to any scope granted to the user for any roles.

This means that you cannot combine roles for users to allow them to perform actions on subsets of devices, they will always be able to perform the most permissive role on any device that they have scoped from ANY role.

Testing and Validation #

I had trouble believing that this was how Intune was applying the permissions. So I set up some test roles to validate what I was seeing. I wanted to make sure that I wasn’t just doing something incorrectly.

Testing Setup #

To set up my test I created a security group “Test Role User” that included my test user, this is the group I would assign my test roles.

I then created a pair of roles and scopes:

Role Test Role One Test Role Two
Permissions Read, Sync Read, Wipe
Scope Test Scope One Test Scope Two
Group Test Role Device One Test Role Device Two
Devices UNC-C____ ROVER-C_____

Test Roles: #

Test Role Assignments: #

The “Test Role Device One” group included a device named UNC-C____ and the “Test Role Device Two” group had one named ROVER-C____.

You’ll see that I assigned the Sync permission to the first role and the Wipe permission to the second. I granted the Read managed device permission to both so the test account could see both devices in the scope.

Results #

Normally, I would expect that I would be able to see both devices. And I would expect that if I clicked on the UNC-C____ device, I would be able to perform the Sync action but not the Wipe because the Test Role One only granted me sync and was scoped to the group with that device.

Then I would expect the opposite for the ROVER-C____ device, I would be able to perform the wipe action but not the Sync one.

This is not how the results came out. Instead my prior experience was validated, it seems that Intune gets a list of all permissions granted from each assigned role, and then gets a total list of all devices you have permissions for from the scopes under each role. It then grants you all permissions, to all devices you have permissions for from all the scopes.

Each device had both the Wipe and Sync action available, meaning they applied to devices from the First and Second scopes:

How Intune Evaluates Permissions from Multiple Roles #

1. Gathers Granted Permissions from All Roles #

If your user is assigned to multiple roles, it goes through each role that you’ve been assigned to and then makes one list of all the permissions you’ve been granted.

You can see this list for your logged in user by going to Tenant administration > Roles > My Permissions:

2. Makes a list of all devices you have permissions for based on the scope of each role #

Every role assignment includes a group that roles is scoped to, along with a scope tag. This is supposed to define the subset of devices in your tenant that you have permissions for based on your role.

Intune iterates through each of the roles you are assigned and gets one list of all the devices from each scope.

3. Grants you all of the permissions from #1 to all of the devices in #2 #

The list of all permissions from step one is then granted to all of the devices from each scope that was gathered from step 2, even if those permissions and scopes are unique from your different roles.

Visualizing Multiple RBAC Assignments #

To make this a little easier to understand, consider these scenarios:

Scenario One: Permissions are assigned independently based on unique roles and scopes #

This is how I would expect permissions to apply:

The results of this would be the following permission table:

Device Name Read Sync Wipe
Dev1 X X
Dev2 X X
Dev3 X X
Dev4 X X

This is not how Intune applies permission, instead it uses scenario two.

Scenario Two: Cumulative permissions are applied to all devices from all assigned scopes #

This is how Intune applies permissions from multiple, unique roles assigned to the same user:

Which has the following results:

Device Name Read Sync Wipe
Dev1 X X X
Dev2 X X X
Dev3 X X X
Dev4 X X X

This basically makes it impossible to make granular permissions to different device groups to the same team of users.

Summary #

Maybe I just don’t understand how roles are supposed to apply compared to traditional permissions. But this seems broken to me, there should be a method to apply different permissions to subsets of devices for the same user or group.

It’s also possible this is only an issue related to iOS/Android devices, as we are not managing workstations yet with Intune I don’t have a way of testing that scenario.


Bulk assign devices to iOS Enrollment Profiles in Intune
·869 words·5 mins
TL;DR # This script can be used to do two things: get your iOS Enrollment Tokens and Profiles from your Intune tenant, and assign a list of devices to profiles using a csv input file.
Getting This Blog Online
·881 words·5 mins
This post covers how I got this site up and running.
Dan Zabinski - About Me
·78 words·1 min
Azure and AWS, Terraform, Microsoft Endpoint Manager, Powershell # See my first post to get an idea of what this blog is about.