Introduction

Securing IT resources and assets with Intune in 2020 remains an ongoing struggle for most IT departments. Over the last few months, I’ve noticed common trends popup during the discovery and design phases with clients. It got me thinking that I wanted to provide some guidance for how I develop a secure and scalable framework for granting access to Intune.

The first interaction that I have with a new customer’s Intune tenant involves requesting access to their Intune tenant, a process which can be difficult in its own right. Once we’re in the design phase of their security model, I have to cover significant ground in explaining best-practices for how to grant access to Intune properly.

Many who have followed me over the years know the importance of designing a security model based on the principle of least privilege (PoLP). Unfortunately, there is a large portion of IT professionals who haven’t considered what PoLP means or how to design for it properly.

Microsoft supports PoLP by strongly discouraging the use of the Global Administrator role in Azure, especially as a means for getting rights to Intune. However, that hasn’t prevented organizations from using the Global Administrator role as a way of simplifying daily operations.

To properly cover my approach to configuring Intune access control, I’m putting together three posts as there are many different facets to consider when provisioning access to Intune. By the end, I hope to lay out a framework you can use to design your own Intune access control model to secure your environment better and deliver a smoother user experience.

In this first post, I’ll be starting with a basic set of permissions that are available through Azure Active Directory Roles, which should not to be confused with Intune’s role-based access control (RBAC). While Azure AD role-based access may be sufficient for some environments, the vast majority of clients I’ve worked with have benefited from taking advantage of the full capabilities of permissions, so I’ll provide some recommendations for configuring permissions.

In the next post, I’ll build on role-based access control by diving into Intune’s role-based access control to provide a more granular configuration of rights to the Microsoft Endpoint Manager admin portal (devicemanagement.microsoft.com). Next, we move to the proper use of custom roles, which will simplify your administration by consolidating multiple roles into a single role.

In the final post, I’ll go deep into Intune’s scope tags, which complement RBAC by adding more granularity to role-based access. This method is something you might see in larger organizations or places with unique security constraints.

 

Azure Active Directory Roles Basics

So, let’s get started with Azure Active Directory Roles. They tend to be simple on the surface when you look at the name of each role but, depending on the role of the technician, there is more to consider than you may be aware of in terms of which rights and roles an administrator may need.

First, let’s briefly review the roles I will talk about in this post:

1. Intune Service Administrator
2. Device Administrator
3. Cloud Device Administrator
4. Conditional Access Administrator
5. Security Reader
6. Desktop Analytics Administrator

 

The first two roles are typically assigned to support personnel who are required to administer Intune and support end user devices. The other roles are for more senior administrators or niche users of Intune and Azure AD.

For example, the Conditional Access Administrator is one role you might want only a select few senior administrators to have. At the same time, the Security Reader is probably more appropriate for day to day support of end-user conditional access problems.

 

Intune Service Administrator

The Intune Service Administrator is a bit of a catch-all role for Intune administration and gives very broad access to the tenant. You should only assign it to senior technicians or consultants doing project work, and you should avoid using it for operational roles in larger organizations. We will talk about this more when we get into custom roles in the next article, but for now, I will keep it simple.

The Intune Service Administrator role also gains the ability to manage Azure AD security group memberships, which helps technicians provision access to applications or make applications available to the device or end user. The additional rights are necessary to make the management of users and devices in the Microsoft Endpoint Manager admin portal a seamless experience since group management is tied to the provisioning and removal of everything from policies to applications on the device.

While an administrator can manage Azure AD groups with this role, he is limited to managing 250 groups through their end user permissions. Office 365 groups are not used with Intune, so managing them is not in the basic scope of permissions that the administrator gets.

 

Device Administrator

The next role is Device Administrator, which doesn’t do much in the Intune portal because it is tied to local administrator rights on Azure AD joined (and Hybrid joined) client devices. By default, the following users get local administrator rights on a machine:

• Users with the Azure AD global administrator role
• Users with the Azure AD device administrator role
• The user performing the Azure AD join

 

If other methods of Azure AD join are used, the user does not necessarily get local administrator rights unless configured by Active Directory, Azure AD, or Windows Autopilot.

Of the three methods, Active Directory comes with a noteworthy risk for mobile devices in that granting rights depends on successfully connecting with Active Directory. The issue, as I see it, is that modern device provisioning uses Windows Autopilot and for many organizations that means provisioning might occur at the OEM or for many other reasons might not have connectivity to a domain controller.

I am not a big fan of dependencies on Active Directory, so I try to discourage them when possible.

With Azure AD, giving local administrator rights can be done by simply giving the user the Device Administrator role. It is a broad right to give but might be more useful for support personnel that require local administrator access to all modern devices in the fleet.

Some of you might ask if there is an alternative to the Local Administrator Password Solution for Azure AD because you want more granular control with local administrator access. I get this question a lot, unfortunately, I don’t have good news at this time. I haven’t found any workaround we can use with Azure AD. We’ll have to wait until a third-party solution fills the gap here.

Finally, local administrator rights can be granted (with limited scope) to just the device using Windows Autopilot, which then grants local administrator rights to the end user as part of the device’s provisioning process. The end user is given the right explicitly to the device and does not involve the Device Administrator role.

 

Cloud Device Administrator

The Cloud Device Administrator role provides device-based rights in Azure AD. As such, the focus is narrow, but it does provide additional rights not found in the Intune Service Administrator role.

These rights include:

• Enable, disable and delete devices in Azure AD
• Read BitLocker keys

 

The distinction is that the Intune Service Administrator role will give you enough rights to only delete a device in Azure AD. Still, this role does not give the additional rights for managing the device objects in AD (e.g., enabling and disabling of device objects).

 

Conditional Access Administrator

The Conditional Access Administrator role is a crucial role for users who need to view and make changes to Conditional Access. The Intune Service Administrator role is insufficient to work with Conditional Access even though you can access Conditional Access policies in the Microsoft Endpoint Manager admin portal.

This role should only be used sparingly and is a prime candidate for misuse due to its convenience. Resist the urge to use this role for day-to-day operations as changes to conditional access can create outages and must be carefully implemented. If you must exclude people from Conditional Access policies, consider using Azure AD security groups in your policies for excluding users.

It is also important to note that this role does not give you permissions to the Azure AD sign-in logs, which is crucial to troubleshooting Conditional Access issues.

Security Reader

The Security Reader role is much better suited for day-to-day operations where the first line of support and triage take place. For example, if an end user is having an issue authenticating, I recommend that you grant the helpdesk with this right so that they can view the sign-in logs themselves rather than escalating the case to a higher support tier.

Interestingly, the sign-in logs are found in the Azure AD portal and not with the Conditional Access policies in the Microsoft Endpoint Manager console. The administrator has to be familiar with locating the sign-in logs in the Azure AD portal, which is completely separate from the Microsoft Endpoint Manager admin portal (shown below).

Desktop Analytics Administrator

This role is for users that need access to Desktop Analytics, which is a cloud backed feature that requires the use of Microsoft Endpoint Manager Configuration Manager. It is the successor to Windows Analytics and focuses on helping enterprises manage the servicing of Windows 10 and Office 365.

You should consider assigning this role to users that need to analyze Windows and Office readiness or more senior Microsoft Endpoint Manager administrators.

Note. The Intune role will not automatically give access to the Desktop Analytics portal.

In the table below, I’ve presented basic permission schemes using the Azure AD roles that you can use to design your security model.

User Type	Azure AD Roles
Tier III Administrator	Intune Service Administrator, Device Administrator, Conditional Access Administrator, Security Reader, Desktop Analytics Administrator
Tier II Administrator	Intune Service Administrator, Device Administrator, Security Reader, Desktop Analytics Administrator
Tier I Administrator	Intune Service Administrator, Device Administrator, Security Reader

 

As you can see, all administrators need the Intune Service Administrator role, which is something I recommend customers look into when building out their security model for Intune.

Specifically, lower level technicians should not be allowed to change device policies or on-board new applications into the environment. Usually, these kinds of changes need to follow processes that provide some governance around these sorts of changes as they can be business impacting and cause significant outages. Don’t worry we will talk about this more in the next article.

 

Wrapping Up Part 1

There are three key takeaways from this post. The first is that you should always start designing your security model around role-based security and strictly avoid using the Global Administrator role or roles with more permissions than needed by the administrator.

The second takeaway is that in real-world scenarios, it will likely take more than a single Azure AD role to provision a Microsoft Endpoint Manager administrator in the cloud. Most administrators have to perform tasks that require permissions from several different roles, and potentially, their responsibility goes beyond supporting devices. Still, it is important not to over-provision roles because having too many people with too many administrative rights can create confusion and problems.

The final takeaway is that many organizations would benefit from assigning the Security Reader role to help-desk staff so that they can begin triaging issues before escalating them to higher-level technicians. I’m finding that too many organizations are not empowering their help-desk with the sign-in logs to see the actual error codes the end user is experiencing when trying to sign in.

Conditional Access schemes make authenticating more complex in a cloud-connected world, but this is necessary to provide the contextual security needed in a zero-trust security model. As your Conditional Access policies evolve, they will use different methods to determine the authenticity of an authentication request. As such, all levels of administrators will need to have greater visibility into the to provide effective support in these situations.

In the next post, I’m going to cover Intune’s role-based access control to provide a more granular configuration of rights to the Microsoft Endpoint Manager admin portal!