Intune scope tags and role-based access control explained

For larger Intune environments a solid role-based access implementation becomes crucial to ensure a secure administration. But how does Intune role-based access control (RBAC) work in combination with scope tags and how to get started? This post gets you covered with explanations and practical examples.

Role-based access control within the Microsoft 365 ecosystem

Within the Microsoft 365 ecosystem, Microsoft provides Azure AD administrative roles to administrate services like Exchange (Exchange administrator), SharePoint (SharePoint administrator), Intune (Intune administrator) and so on.

As you can see Azure AD provides (usually) only one role which grants full administrative access over a service. You can configure more fine-grained controls within the service itself - that’s where the RBAC controls of the respective service kick in.

To give you another example: You might have a 1^st or 2^nd level support department which needs permissions to perform remote actions on Intune managed devices. Instead of assigning them the Azure AD Intune Administrator role, it’s more convenient to assign them a fine-grained Intune RBAC role which delegates exactly the permissions needed.

As the name already indicates Intune related roles only live within the Intune tenant and cannot be managed from AAD and vice-versa:

Azure AD administrative roles with Intune permissions

Along with the “Intune Administrator” the “Global Administrator” role is as of today the only role which grants write access to the Intune service. You can find an exhaustive list which covers also roles with read access within this Microsoft docs article: Azure Active Directory roles with Intune access.

Intune roles

The Intune service comes with a predefined set of built-in roles. These role definitions are immutable which means that you cannot edit permissions, display-names or descriptions.

If you want to customize a role you can duplicate your desired built-in role which then becomes a “custom role”.

You can manage all Intune roles and RBAC settings under the “Tenant administration” -> “Roles” blade:

Example use cases

Imagine a small to medium company with a central IT which provides all services.

If you have use cases like:

• Members of the 1^st level support should be able to perform device actions (reset, retire, lost-mode) and assign mobile apps
• Members of the 2^nd level support should be able to modify device configurations and create mobile apps

that’s where an Intune role assignment to the repective groups (1^st and 2^nd level support) will be sufficient.

Advanced use cases

Larger companies or companies with decentralized IT departments organized by business regions like EMEA, APAC… could have advanced use cases like:

• The support team of EMEA should be able to perform device actions only on EMEA devices
• The support team of EMEA should only be able to modify EMEA device configurations and not global configurations

We need more fine-grained controls to identify which resources belong to EMEA. And these controls are called “Scope tags”.

Intune scope tags

What’s an Intune scope tag?

A scope tag assigns an Intune configuration (e.g. device configuration, compliance policy, mobile app or managed device) to one or more specific management scope(s). {: .notice}

You can imagine a scope tag like a “virtual Active Directory organizational unit (OU)” - to each Intune object you assign a scope tag it would reside within that OU. In Active Directory terminology we would then “Delegate permissions” to a specific group which can manage objects within that OU - that’s exactly what Intune role assignments and scope tags do (hypothetically).

Default tag

By default, all Intune entities which are created from a user without an Intune role (which means it was either an Intune Administrator or Global Admin) get automatically assigned this built-in scope tag. Every object in Intune needs to have at least one scope tag assigned.

What about accounts without an Intune role?

Azure AD administrative roles with Intune permissions which don’t have an Intune role assigned always preserve permissions based on the AAD role on all resources no matter to which scope they belong.

Scope tag inheritance

• An admin which got an Intune role with scope tag(s) assigned will inherit the scope tag(s) to all resources he creates
• Apple VPP tokens will inherit all scope tags from the VPP-token level to the mobile apps

Configurations supporting scope tags

All except the following resources in Intune currently support scope tags:

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

List from microsoft docs.

Assignment of Intune roles and scope tags

To assign a role you can customize the following options:

• Admin Groups
  • Azure AD Group which will have the role assigned
• Scope Groups
  • Here you can add specific groups which can be managed by this role
  • Admins can perform assignments only to groups specified within the “Scope Groups”
    • Selected groups ->
    • All users -> Admins can create “All user” assignments but cannot perform any device-related tasks
    • All devices -> Admins can manage all device properties and tasks including assignments but cannot perform user-related tasks
    • All users and all devices -> Admins can can can manage and target all devices, users and AAD groups
• Scope tags
  • controls over which scope the role is valid
  • if you don’t specify a scope it’s valid across all scopes (whole Intune tenant)

Real-world example

To come back to our advanced role assignment example about EMEA - we need to do the following steps to implement Intune RBAC for the EMEA team:

• Create a new Intune role (e.g. “Continental operators”) which has permissions to perform device actions and edit device configurations
• Add a new scope tag called “EMEA”
• Assign the “EMEA” scope tag to all “EMEA” devices
• Assign the EMEA scope tag to all “EMEA” device configuration profiles
• Assign the Intune role “Continental operators” to an AAD group which holds the EMEA IT staff e.g. “gs-aad-apac-intuneoperators”
  • Make sure to include the “EMEA” scope tag within the role assignment

Result

Members of the “gs-aad-apac-intuneoperators” AAD group have now permissions according to the custom Intune role “EMEA operators” role over all Intune objects which have the “EMEA” scope tag assigned.

An EMEA user which owns the custom Intune role will only see the devices and configuration profiles with the EMEA scope tag assigned:

Remarks

• We can create multiple role assignments for the same role. This is useful when you want to implement the same set of permission to the respective scope
  • If APAC needs the same permissions like EMEA on APAC resources we can just add a new role assignment and use the APAC scope tag and AAD group
• Scope tags can also be assigned to Intune managed devices via AAD groups
  • Peter van der Woude wrote a great post about this
• If you want to prevent EMEA admins from adjusting assignments of the EMEA device restrictions (e.g. to another group or removing it) you can either:
  • disable the “assign” permissions in the custom role
  • specify the Azure AD groups where they should be able to target in the role assignment under the “Scope (Groups)” setting

Additional notes

License requirements

Using Intune roles did require an active Intune license assigned to the admin. This changed with the 2006 release which was rolled-out in Juni 2020. You can disable the license requirement in your tenant:

But keep in mind that for MFA / Conditional Access an Azure AD Premium P1 plan is still required.

Verify assigned Intune permissions

You can easily verify Intune permissions assigned to your account by visiting Tenant Administration -> Roles -> My permissions:

Conclusion

Intune offers very fine-grained control to administrate a tenant with Intune (custom) roles and scope tags. For smaller environments and especially companies with a central IT working with scope tags might overdo the cake but for larger decentralized tenants these are welcome features to reduce the load on the central IT team. Whereas Intune Intune roles can be very helpful to assign the right permissions to 1^st and 1^nd level support teams.

Happy Intune RBAC-ing.