| Next >
RBAC
RBAC, or Role Based Access Control is a methodology for assigning permissions to users based on their job role(s). Administrative Rights delegation benefits from RBAC methodology by restricting rights to the people who need them without granting excessive permission. It contrasts with the most common AD access control methodology, Discretionary Access Control (DAC). DAC permission grants rights based on data ownership and allows the owner of a specific file all permissions associated with its use, including additional permission sets. In Microsoft’s Intune (recently renamed to Microsoft 365 Device Management, which I will continue to call Intune for brevity), RBAC is controlled with Roles, Groups, and Scopes. In this guide, I’ll introduce the theory behind Intune RBAC, while the next parts will go over the steps required to delegate administrative rights. RBAC is a very confusing concept at first, but once you get the hang of it, it will allow you to effectively manage permissions in Intune.
Creating Admin Users
- The first thing you’ll need to know about handling RBAC in Intune is how to successfully configure user accounts so they can access Intune and all objects they have permission to manage without excess permission. It’s important to understand that granting a user Global Admin permission in Office 365 will make it much more difficult to limit their rights in Intune, so you need to create the user with normal user rights as shown below.
- In addition to setting the correct default role for the delegated admin user account, every admin needs to have an Intune license to do their job. Failing to assign an Intune license to admins will cause a notification that the users don’t have permission to do anything. Assign a license as show here:
- Finally, you need to be patient. Almost every change to roles, scopes, and permissions in Intune requires replication before it will apply. This means a wait time of 15-30 minutes before the changes are fully applied. Users will not have any access to the Intune admin portal until the group assignments and everything else fully replicates. If you don’t assign the rights correctly, you’ll know it because those users will not have access to anything or they will have access to everything.
Now that you have your Administrative user, let’s move on to some terminology and theory…
Scopes
To make this information a little more accessible, I’ll explain what everything is from the bottom up, starting with Scopes. Intune uses a scope to grant permission to specific devices, groups, and other objects. Scope Tags are assigned to all objects to denote the objects that belong to a specific scope. Each object a scope tag is assigned to will become part of that tag’s overall scope. Objects in Intune can be assigned multiple scope tags, so you can have overlapping scopes to allow for higher or lower levels of access. One important thing to remember is that everything in Intune is tagged with the “Default” scope, and any administrative role that is granted permission to the default scope will be able to manage just about everything in Intune.
Groups
Groups are fairly self-explanatory, but there are some things you need to be aware of. In Intune, there are two types of groups; Security groups and Scope groups. A security group contains users or devices and is used to control which users are part of a specific administrative scope or which devices are subject to a specific policy or application. Scope groups, however, are a newer concept that are used to define a core group of objects that a specific scope applies to. A scope group can be used to define the objects, users, or policies that defines what portion of the complete whole a role is assigned to manage. For instance, if you have an admin that needs manage a group of devices regardless of where those devices are located or who owns them, you would set the scope group of that role to pull its scope of devices from a scope group that contains all devices. When done properly, the associated admin will have permission to manage, for example, only Windows devices throughout the company.
Below is a good example of how Scope Tags and Scope Groups can be used to group like objects for specific management personnel. In the diagram, you’ll see three different devices; iPhone, Android, and Win 10. All of these devices fall under the All Devices Scope Group. Normally, we would have to grant a user full admin rights to Intune before they can do anything, but that means they have permission to manage everything in the organization. If we want to restrict administrators to specific types of devices, we would create a Scope Tag for each device type (iPhone, Android, and Win 10) and tag each device with its associated Scope Tag. When this is done, we can use the Scope Tags as a subset of All Devices Scope Group to reduce administrative control to only what each admin needs to do their jobs. Windows 10 admins only have rights to manage Windows 10 devices, iPhone admins only have access to iPhones, and Android admins only have access to Android devices.
Roles
The core concept in Intune RBAC is, of course, roles. In Intune, a role will take in the scope group as its list of objects to pull from, assign a specific scope tag to determine which subset of devices are managed by that role, then assigns a group of users to manage those objects. With those decided, the role also defines the permissions users assigned to the role have on the objects in their scope. In the above diagram, we would need to create a Role that uses the All Devices group as its Scope Group, the Win 10 Scope Tag, and a group of users who will be Win 10 admins. With that done, we would assign the permissions those admins need to manage those devices. With these pieces put together, we finally have our role created and ready for work. All we need to do to grant our admins rights to the devices they need to manage is to assign them to the appropriate group.
Alterations
The RBAC system in Intune is very functional and gives an endless array of strategies for managing Intune and delegating permissions to admins without granting unnecessary rights. You can change things up any way you want. You can change the Scope Group to include each device type instead of all devices and set the Scope Tag to include all devices to get the same result in a different way. You can also choose to set a single Scope Tag to a certain type of device, then create Roles for each physical site by using Scope Groups that contain only the devices in each site.
The RBAC system is, as I mentioned earlier, a little confusing at first and there are some pitfalls that will make things work in unintended ways. Failing to remove the default scope tag from a role will result in admins with far more access than you want to give. The difficulty with this technique of assigning permission the need for strategic, long term thought and planning to find the best methodology. With some care and a little patience, however, you will be able to grab a hold of access rights in your organization.
Step by Step: Intune Delegation with RBAC #2
Step by Step: Intune Delegation with RBAC #3
Intune RBAC – Delegate Permissions Explained
Intune – Permissions for iOS and Android Devices
