There are lots of permissions that can be delegated in Intune/Microsoft365 Device Management. Understanding what each of those permissions is for and when to assign them is, therefore, a little difficult. With this post, I’ve gone through the task of outlining all of the delegate permissions in Intune as of September 2019. I’ll try to keep this up to date, but if I fail to, just leave a comment telling me something has changed and I’ll get things fixed. A lot of the permissions are easier to understand and there are explanations in Intune for each, but I’ll try to explain the permission from a more strategic perspective. Please be aware that I have not tested the majority of these permissions, but am instead collating information from the info bubbles in the permission list and my own experience with Intune. From top to bottom, here are the permissions:
Android for Work
These permissions control Intune’s Android for Work apps and Enrollment, which is what the BYOD style Intune Enrollment uses for app deployment permissions. It utilizes a “Work Profile” on Android devices that segregates work apps and data.
Allows the delegated admin to view the Android for Work enrollment profiles and app sync status. This also likely grants permission to read Android Enterprise enrollment profiles and tokens.
Update App Sync
Allows the delegated admin to update the Google Play for Work configuration and sync apps from the Google Play for Work store. Also likely grants access to configure Managed Google Play store and sync apps from that store into the Intune App list.
Allows changing the Android for Work/Android Enterprise configuration and manage enrollment profiles. This is needed to change, update, or remove any Android enrollment profiles.
There is only one setting in this section – Read. Put simply, this lets delegates read the audit logs to find out who made changes to configurations and where changes have been made.
Corporate Device Identifiers
Corporate Device Identifiers are used to keep track of devices that are owned by the company. Mostly used to pre-declare ownership of devices that are enrolled using Intune’s BYOD techniques using Intune Company Portal. This feature is available under the Device Enrollment blade. The permissions here are fairly self explanatory; Create, Delete, Read, and Update. Each allows specific access to existing entries or to create/delete entries manually or with a CSV.
Device Compliance Policies
Device Compliance in Intune is used to control which devices have access to company resources. This is a piece of the Intune Conditional Access feature that grants access to resources based on specific criteria. If a device does not meet compliance requirements, as defined in compliance policies, it will not be able to access resources or specific applications in the Azure AD Controlled environment. One thing of note here is that this permission delegation section also covers control of the Intune for on-premises Exchange connector, which is used to extend Conditional Access policies to an On-premises Exchange environment, allowing Intune to control who can access Exchange On-prem. Exchange Online is automatically under Intune’s control, so no connector is needed there.
Allows admins to assign compliance policies to groups in Azure AD or assign groups that can access Exchange on-prem through conditional access.
Allows admins to create new compliance policies for use with Conditional Access.
Allows admins to delete compliance policies or delete existing Exchange on-prem ActiveSync connectors.
Allows admins to view compliance policies and their associated settings.
Allows admins to make changes to compliance policies, Exchange ActiveSync connectors (Intune for On-prem) and the access settings for Exchange On-prem.
Device configuration profiles are used to prevent or allow specific functions on Intune managed devices. This is the “Group Policy” of Intune and is needed if you want to control access to data, features, and other controls on mobile devices. The permissions in this section control what admins can do with Configuration profiles. Note: These permissions also apply to Device Enrollment restrictions. In other words, granting assign permissions here also grants permission to assign device enrollment restrictions to specific groups. If you don’t want your admins to be able to prevent groups from enrolling specific device types or OSes, don’t assign these permissions to them. You can end up with lots of problems with this permission set, so be very careful about giving people this. Think about it this way, if you don’t want an admin futzing with Group Policy, don’t give them any permissions here. Except maybe Read. If you’re generous. With that explained, the permissions here are self explanatory in that they give varying levels of control over device configurations and device enrollment policies; Assign, Create, Delete, Read, and Update.
Device Enrollment Managers
A Device Enrollment Manager in Intune is granted permission to enroll up to 1,000 devices into Intune. By default, each individual user in Azure AD has rights to enroll up to 25 devices. Adding a user as a DEM lets them go past this limit. Simple enough. Before you ask, I don’t know if Global Admins are subject to either limit, but if you have occasion to enroll over 1,000 devices as a Global Admin, let me know if you can do it. At any rate, permissions here give you control over DEMs. There are two permissions…Read and Update (Delete falls under Update, in this case). If you are *not* a global admin or Intune Service admin, you can only see or update/delete the DEMs that you created.
Endpoint Protection Reports
Allows admins to view reports associated with the Windows Defender Advanced Threat Protection client. A note here…You won’t be able to view Endpoint Protection Reports unless you integrate Intune with the Azure Log Analytics system. Once that’s done, though, this permission lets a delegated admin view those reports. (Maybe necessary for integrating with SIEM)
This one’s a little confusing at first (and probably second) glance. But I’ll explain some of the background regarding Enrollment. First off, these permissions apply only to Windows Autopilot and iOS Device Enrollment Programs (which, for this guide, covers Apple Business Manager and Apple School Manager) plus Apple Configurator. These enrollment methods allow quick zero to light touch configuration of devices and require some configuration in Intune. Android has its own DEP solution, but Intune is still very weak with Android management at the moment, so no controls for that here. I’m going to collapse the permissions here a little because there are a bunch.
Allows admins to create new devices by importing them from Apple Configurator (Autopilot and DEP devices are not “created” by admins).
Delete DEP and Apple Configurator created devices. I should note here that I believe this refers only to the Device list under the Enrollment Program Tokens section and not the root device view, which is covered under the Managed Devices permission.
View the devices under DEP, Apple Configurator, and Autopilot enrollment sections.
Only applies to Windows Autopilot. Basically syncs Intune with the Autopilot registry system.
Assign, Create, Delete, Read, Update Profile
Allows permissions on device profiles for Autopilot, DEP, and Apple Configurator. Note, here, that the “Assign” permission’s info bubble shows that it only applies to Autopilot. I am not certain, but I suspect this also applies to DEP, since there are profiles that need to be assigned there as well, but that permission may be covered under Update.
Create, Delete, Read, Update Token
Apple’s DEP (ABM and ASM) involves the use of Enrollment tokens to link Intune and DEP. Creating a token involves generating a .PEM file that is then uploaded in ABM/ASM. A token file is generated and then downloaded from Apple’s systems and uploaded to Intune. Create permission lets you download the .PEM file, while Update lets you upload the resulting token file. Update permission also allows admins to initiate device Sync from DEP systems.
Intune Data Warehouse
Intune Data Warehouse is a data collection system that stores usage and other data for use by Power BI and other business intelligence reporting solutions. Only one permission here, which is Read.
This permission doesn’t control access to Apps in Intune, but rather to the App Management policies. App Management policies allow discreet control of specific applications that are set up to allow management through Intune. This permission set applies to those policies. Permissions are Assign, Create, Delete, Read, Update, and Wipe. Hopefully those are self-explanatory, but I should point out that the Update permission allows users to delete pending wipe requests, which could be potentially problematic. Be careful with that one.
Simple enough, this allows specific permissions on the Devices view in Intune. Delete, Read, and Update permissions are self-explanatory. Update permission is fairly limited, however, and mostly covers just changing ownership between Personal and Corporate or changing settings on the Properties page.
Grants permission over the portions of the Client Apps section in Intune that can be fully managed from there. Assign, Create, Delete, Read, and Update permissions are available. Also allows users to manage VPP tokens, Windows Enterprise Certificates (used for implementing on-prem PKI with Intune), and Symantec certificates (integrating Symantec Endpoint Protection with Intune), etc, etc. See the info bubbles for more info on what you can do with these permissions.
Control over Organization level Intune settings. Create, Delete, Read, and Update permissions are available. I don’t recommend assigning these permissions to anyone through RBAC, as they are best controlled with Global Admin privileges. Organizational settings include Mobile Device Threat Protection Connectors, Exchange Connectors, and Device categories.
Probably also best managed by Global Admins, this section pertains to the status of the Teamviewer Connector in Intune. Read lets you view its status, Update allows management of it. You need to have read to have Update.
This is the biggest category of permissions available. Each of these permissions is associated with some remote management feature. The permissions are fairly self explanatory, but each permission is Yes/No, so this will just be a bulleted list of permissions with limited explanations. Understand that many of these remote actions can only be performed on DEP enrolled devices if they are Apple controls. I will not cover which ones fall under this limitation here. I will, however, point out which functions only apply to iOS.
- Bypass Activation Lock – For company owned Apple Devices that are set up using an Employee’s Apple ID, this allows admins to bypass any activation locks that the employee may have set up.
- Clean PC
- Disable Lost Mode – iOS only
- Enable Lost Mode – iOS only
- Enable Windows IntuneAgent
- Get filevault key – for Macs, basically used to store encryption keys in Intune.
- Locate Device – iOS only
- Manage shared device users – Forces logout in Windows (also maybe Intune Company Portal)
- Play Lost Mode Sound
- Reboot Now – End users aren’t notified if you do this and can’t save work. Be careful, lest the workers revolt.
- Remote Lock
- Request remote assistance – Allows admins to request remote access to a device using the TeamViewer connector. Doesn’t work with Surface Hubs, HoloLense, Windows 10 S, or iOS.
- Reset Passcode
- Retire – Clears only company data at next check in and deletes the device from Intune.
- Revoke App Licenses – Applies to any iOS VPP licenses assigned to the device.
- Manage Encryption Keys – Apparently applies to any device…currently in preview.
- Rotate filevault key – Changes the Mac filevault key used to encrypt the device. Used if a company owned device is loaned to a user that leaves the company (mostly).
- Set device name
- Shut down
- Sync devices – Forces the device to sync with Intune.
- Update device account – Applies to Surface Hub devices.
- Windows Defender – Starts updating signatures for Defender.
- Wipe – Factory Reset. This can either keep or erase user data. Both options are available with this permission.
Delegates all rights associated with role management. Self-explanatory on what each permission does. Note that the Assign and Update permissions do not include one another. You cannot change the permissions associated with a role without Update permission, and you cannot create role assignments without Assign permission. Read permissions are required to perform Assign, Update, and Delete actions. If you create a role without read permission, well, good luck verifying your work.
Delegates rights to work with the Security Baseline features. Security baselines allow you to define and manage minimum security requirements that are used with Windows 10 and Windows Defender ATP. The permissions available here are the same as under Roles and are also self-explanatory.
Security tasks are a list of actions that need to be performed before a device (or devices) meet the security baselines available. The permissions here are Read and Update. Read lets the admin view the task list, update lets the admin perform whatever task is shown from the task list itself. Without Update permission, the task has to be performed manually through other means.
For organizations that have integrated expense management with their telecom provider. Read permission allows admins to view settings for any Telecom connectors.
Terms and Conditions
That’s all of them. Lots of reading, lots of writing, but hopefully you won’t be too confused any longer when determining what level of permissions to delegate when working with Intune. If you are looking for more information about Role Based Access Control in Intune, be sure to read through the Admin Delegation for Intune guide:
Step by Step: Intune Admin Delegation with RBAC #1
Step by Step: Intune Delegation with RBAC #2
Step by Step: Intune Delegation with RBAC #3