Azure AD roles are used to delegate permissions to perform tasks in Azure AD and Microsoft 365. Most people are familiar with the Global Administrator role, as it is the first role that’s established when you create a tenant. However, there are dozens of other roles available that can be used to provide a refined level of delegation throughout the environment. As the number of applications and services available in Microsoft 365 has grown, so has the number of security roles.
Roles for applications, services, and functions are intuitively named and generally split into two groups, Administrator and Reader, though there are some roles that have additional levels of permission associated with them (such as Printer Technician or Attack Simulator Payload Author).
If you’re reading this book chronologically, you’ll already be familiar with the Global Administrator role (also called the Company Administrator role in some legacy interfaces). If not, you can refer to Chapter 1, Implementing and Managing a Microsoft 365 Tenant, to get up to speed. The Global Administrator roleis able to administer all parts of the organization, including creating and modifying users or groups and delegating other administrative roles. In most cases, users with the Global Administrator role can access and modify all parts of an individual Microsoft 365 service—for example, editing Exchange transport rules, creating SharePoint Online sites, or setting up directory synchronization.
Further Reading
There are currently over 70 built -in administrative roles specific to Azure AD services and applications. For an up-to-date list of the roles available, see https://learn.microsoft. com/en-us/azure/active-directory/roles/permissions-reference.
For the MS-102 exam, you should plan on becoming familiar with the core Microsoft 365 and
Azure AD roles:
Role name | Role description |
Global Administrator | Can manage all aspects of Azure AD and Microsoft 365 services |
Hybrid Identity Administrator | Can manage Azure AD Connect and Azure AD Connect |
Cloud Sync configuration settings, including Pass-Through | |
Authentication (PTA), Password Hash Synchronization | |
(PHS), Seamless Single Sign-on (Seamless SSO), and | |
federation settings | |
Billing Administrator | Can perform billing tasks such as updating payment information |
Role name | Role description |
Compliance Administrator | Can read and manage the compliance configuration and reporting |
in Azure AD and Microsoft 365 | |
Exchange Administrator | Can manage all aspects of the Exchange Online service |
Guest Inviter | Can invite guest users regardless of whether the members can |
invite guests setting is enabled | |
Office Apps Administrator | Can manage Office apps, including policy and |
settings management | |
Reports Reader | Can read sign-in and audit reports |
Security Reader | Can read security information and reports in Azure AD and |
Office 365 | |
SharePoint Administrator | Can manage all aspects of the SharePoint service |
Teams Administrator | Can manage all aspects of the Microsoft Teams service |
User Administrator | Can manage all aspects of users and groups, including resetting |
passwords for limited admins | |
Table 3.1 – Core Azure AD and Microsoft 365 roles
Planning for Role Assignments
One of the core tenets of security is the use of a least-privilege model. Least privilege means delegating the minimum level of permissions to accomplish a particular task. In the context of Microsoft 365 and Azure AD, this translates to using the built-in roles for services, applications, and features where possible instead of granting the Global Administrator role. Limiting the administrative scope for services based on roles is commonly referred to as role-based access control (RBAC).
In order to help organizations plan for a least-privilege deployment, Microsoft currently maintains this list of the least privileged roles required to accomplish certain tasks, grouped by application or content area: https://learn.microsoft.com/en-us/azure/active-directory/ roles/delegate-by-task.
When planning for role assignments in your organization, you can choose to assign roles directly to users or via a specially designated Azure AD group. If you want to use groups for role assignment, you must configure the isAssignableToRole property during the group creation. For example, in Figure 3.1, the Azure AD roles cannot be assigned to the group due to the current setting of the Azure AD roles can be assigned to the group toggle. To enable roles to be assigned to this group, the toggle will need to be set to Yes, thereby setting the isAssignableToRole property of the object to $true behind the scenes. It cannot be configured afterward. If you make a mistake on this setting for a group, your only option is to delete the group and start over.
Figure 3.1 – Configuring the isAssignableToRole property on a new group
Azure AD groups that are configured to be role-eligible must have assigned membership. As soon as you move the slider to configure a role-assignable group, the ability to change the membership type to dynamic is grayed out. Role-assignable groups must have assigned membership to prevent unintentionally elevating a user to a privileged role or removing a user’s privilege when a group’s dynamic membership rules are evaluated.
Leave a Reply