Setting up regional-specific permissions with Intune scope tags
A common question when implementing Intune for multi-national organizations is: “How can I allow regional IT teams to manage devices that are in their own region, without access to the rest of the organization’s devices?” This is something that isn’t obvious for IT teams that aren’t unfamiliar with Intune. This article explains the details about how to set up the permissions within Microsoft Endpoint Manager (MEM) Admin Center for an IT team in Seattle where their manager can only manage devices enrolled into Intune via Autopilot in that region.
The Theory – Intune Scope Tags
The most important element to understand is something called scope tags. An Intune scope tag is a container that allows specific teams to manage the specific devices defined in a Dynamic Device Group t. It’s worth noting that Intune assigns a default scope tag automatically to all untagged devices. All objects within Intune must have at least one scope tag.
Role-Based Access Control (RBAC) with Intune
Endpoint Manager includes nine RBAC roles for Intune management (Figure 1):
The roles range from Intune Role Administrator, giving full power over Intune, to the Read-Only Operator role which gives holders read-only rights to the Intune environment. To see more on the Built-In roles, please check the Microsoft documentation.
To determine the required permissions, we must create a custom Endpoint Manager role for the Seattle administrators to ensure that they can only manage devices in their region.
Check out the Top 10 Security Events to Monitor in Azure Active Directory and Office 365 in this eBook.
Dynamic Device Group
Autopilot uses Azure AD Dynamic Device Groups to control registered devices. A typical environment has a DDG which is automatically updated with a device when its Hardware Hash is uploaded to Intune. To identify Seattle-based devices, we the device a specific Group Tag when we upload the Hardware Hash to Intune.
Setting up permissions for the Seattle IT department
Create Azure AD Groups
The solution needs two Azure AD groups. First, a Security Group for The Seattle IT Team (called “Seattle IT”) populated by the members of the Seattle IT team. The second Security group is a Dynamic Device Group, used for Seattle-based devices enrolled via Autopilot. Create the group with the following dynamic membership rule:
(device.devicePhysicalIds -any (_ -eq "[OrderID]:SeattleDevice"))
If you have a “catch-all” Dynamic Device Group for Autopilot devices, the dynamic member rule should be changed to the following (thanks to Peter Egerton’s blog):
(device.devicePhysicalIDs -any (_ -contains "[ZTDId]")) -and -not (device.devicePhysicalIDs -any (_ -eq "[OrderID]:SeattleDevice"))
Create Scope Tag
Next, we create a scope tag in the Intune scope tag section. The following information is needed to create a scope tag:
- Name The name of the scope tag should be easily identifiable i.e., “Seattle Office.”
- Description A description of the scope tag which identifies its purpose.
- Included Groups Here we add the group we created above. This will assign the scope tag to all the devices in this group.
Create Intune RBAC Roles
We now decide the administrative rights to assign to our administrators. Go to the RBAC landing page. We need the following details:
- Name The Name of the role, such as “Seattle Admin”
- Description A user-friendly description of the Intune RBAC role
- Permissions for the scenario. In this case, we need some granular permissions, including permissions to manage Windows 10 devices: (Figure 2) & (Figure 3)
Create Autopilot Profile
Last, we create an Autopilot profile for the Seattle devices. The important points are to ensure that devices are easily identifiable by giving them a SEATTLE prefix and that any device that uses this profile inherits the “Seattle Office” scope tag. I used the settings shown in Figure 4.
Enrolling a device
After uploading the Hardware Hash with the Group Tag SeattleDevice, and enrolling the device via Autopilot. I can now see it in Intune alongside the other desktop that I previously enrolled: (Figure 5)
By examining the device properties, it’s obvious that Intune enrolled the device automatically with the Seattle Office group tag (Figure 6):
The Result
If we now log in as a Seattle administrator, only the device based in Seattle is visible (Figure 7):
The administrator can perform all the administrative tasks on this device that we assigned permissions for earlier: (Figure 8)
Conclusion
Assigning the Intune Role Administrator permissions to all admins is never the right answer. It is important for organizations to create Intune RBAC roles to ensure administrators have the necessary permissions to do their work without the ability to interact with devices that do not concern them. In a multi-region or national company with multiple helpdesks that look after specific devices, using Intune scope tags is the right way to ensure that IT teams have permissions to the devices that they need to look after.
Check out the Top 10 Security Events to Monitor in Azure Active Directory and Office 365 in this eBook.
You stated “The roles range from Intune Role Administrator, giving full power over Intune…” Are you sure about that? I thought the Intune Role Administrator only has permissions to manage Roles, not full power over every thing. The user(s) assigned to the “Intune Administrator” in Azure are the ones that have full power of Intune. All other roles in Intune have fewer permissions (less power) and must be scoped with Scope Groups and Scope Tags.
hi With the permission you have shown we cant upload hardware hash online or import hardware hash csv ,import option is greayed out ,we have elevate intune administror role for that ,any suggestion for that