Managing Access Security in Microsoft Intune​

​
The definition of roles and scopes in IT tools is a central issue in a modern workplace project. Due to the mass actions achievable through these tools, it is essential to define teams and their rights, as well as the areas on which each can intervene.​

Within Microsoft Intune and Azure AD (Entra ID), the management of roles and permissions is implemented on multiple levels.​

What are the native roles in Azure AD?

Firstly, it is necessary to consider Intune as a component of Azure AD. Several years ago, Intune was even a menu within Azure AD before having its dedicated portal. There are several Azure AD roles that provide permissions in Intune. These roles are pre-configured and serve as a solid foundation when implementing Role-Based Access Control (RBAC).​

An Azure AD role is defined by a set of permissions that is then assigned to a group containing administrators. There are roles providing read and write permissions on Azure AD menus, others offering exclusive read rights on the Defender portal, some specific to Intune, others for reading logs, etc. It is important to note that these roles are managed within Azure AD, the central hub of the Azure ecosystem​

 

Admins rely on native roles such as:​

• Cloud Device Administrator for rights over devices,​
• Global Reader for read rights across the Azure ecosystem,​
• Security Administrator for read and write rights on security features,​
• Intune Administrator.​

The Intune Administrator role grants full authority to the person holding it over everything in the Intune console, and beyond. This individual also has rights in Azure AD, particularly for reading and writing groups and devices. This right should be distributed sparingly, especially since, by default, it is not “scopable.”​

What is the scope of an Azure AD role?​

An Azure AD role that is not “scopable” means its scope extends to the entire directory. Azure AD should be considered as flat, not hierarchical.​

In large organizations, it is challenging to envision all admins performing mass actions across multiple countries or business units. This is one of the reasons Administrative Units (AU) were introduced. It’s a feature developed by Microsoft in Azure AD to limit a scope (group of devices or users) to admins with an Azure AD role.​

​
Administrative Unit: A Valued Feature​

As an Intune expert, reading BitLocker keys stored in Azure AD is a frequently encountered use case. To prevent ALL keys from being read by ALL admins with the dedicated role, the role is “scoped” only to FR admins so they can perform role-related actions (reading keys) only on FR machines.​

When dealing with another country, another Administrative Unit (AU) is created, like AU BE for Belgium, for example. Then, workplace devices in BE are linked to it so that only BE admins can read the encryption keys of these BE devices, and so on.​

It’s important to note that AUs are not OUs. In Intune, an Organizational Unit (OU) is defined as a container in on-premise Active Directory where policies, groups, nesting, etc., are placed. An AU should be seen as a label applied to devices with specific permissions linked to specific admins.​

Managing Intune Roles​

In addition to Azure AD roles, there are also roles specific to Intune. Their management can only be done in the Intune console.​

An Intune role allows administrators to have rights to work only within the Intune console, whether on mobile devices or desktops. Thus, an admin may have rights to manage mobile and desktop applications without having the rights to manage device configurations.​

Note that it is not necessary to combine an Intune role with the Azure AD “Intune Administrator” role since the latter implicitly includes the permissions of the Intune role.​

Permissions and Scopes in Microsoft Intune​

An Intune role is broken down as follows:​

• Permissions (role definition): Represents all possible actions in Intune, such as reading applications, writing configurations, reading deployment logs for compliances, etc.​
• Assignment: Represents the groups and scopes to which the role is assigned.​

Consider a role that grants write access to Intune object types such as applications, devices, configurations, etc. These are permissions. This role should then be assigned to several country groups, but admins should only be able to read Intune objects from their country. Therefore, within the same write role, an assignment can be created per country (FR, BE, NL, BR, etc.) so that each scope is isolated from its neighbor, based on the same write permissions.​

Role Assignments in Microsoft Intune​

An assignment in Intune consists of:​

• Targeted admins (members).​
• Scope groups: Represent groups with which admins can interact. They can only assign or modify configurations/apps if these are assigned to these scope groups.​
• Scope tags: These are labels placed on Intune objects. These labels are automatically assigned when the object is created. An admin can only see objects with the label assigned to them in their assignment. Note that scope tags are also applied to devices by script or through dynamic groups.​

It is with this combination of permissions and scopes that admins can interact with the same Cloud tools.​

Going Further​

It is important to carefully divide the perimeters and corresponding teams beforehand. This upstream task allows for the best representation of the company’s model in different tools and for tracking its evolution.​

On the other hand, access to Cloud tools such as Intune is coupled with conditional access in Azure AD. Thus, access to the Intune portal can be limited to machines enrolled in MDM (Mobile Device Management) and adhering to defined security standards such as antivirus, EDR, encryption, password complexity, Secure Boot, double authentication, etc.​

Finally, it is possible to rely on temporary roles for the duration of one or more actions (Privileged Identity Management Role). Permissions expire as soon as the action is completed.​