Archives June 2021

After creating the administrative units, you can review them and modify their members and administrators from either the Azure portal or the Microsoft 365 admin center underRoles | Administrative units.

See Figure 3.20:

Figure 3.20 – Viewing administrative units

By selecting an administrative unit in the Microsoft 365 admin center, you can view or change its membership.

Note

The user interface for managing administrative units isn’t consistent. From the Microsoft 365 admin center, you can view an administrative unit and add users or groups to it, but you can’t do the inverse of navigating to a user or group object and adding it to an administrative unit. You can, however, perform both types of membership operations in the Azure portal.

While you can assign groups to administrative units, it does not automatically add the group member objects to the administrative scope—it only enables managing the properties of the group. You need to add the members of the group to the administrative unit directly in order for them to be in scope.

Note

Dynamic administrative units are a preview feature that allows you to use filters and queries to automatically populate administrative units. Like dynamic groups, dynamic administrative units can only have one object type (users or devices). Dynamic administrative units can only be configured in the Azure portal at this time.

As you define administrative structures and delegation for your organization, you’ll need to understand the limits of scoping controls. For instance, assigning an administrator to both an administrative unit as well as an Exchange or SharePoint Administrator role means that while they can only make modifications to users in their administrative unit, they can potentially make changes to application settings that affect users tenant-wide.

Note

Some applications, such as Exchange Online, support additional RBAC scoping controls to offer finer-grained service administration.

Planning and Implementing Privileged Identity Management

Privileged Identity Management (PIM) is the logical next step in RBAC and least-privilege identity management. While RBAC addresses what amount of privilege is needed to accomplish a task, PIM addresses the idea of how long this level of privilege is required.

Sometimes called Just-in-Time (JIT) access, PIM is a feature that allows users to request elevation to Azure AD roles or resources for limited periods of time to perform administrative tasks. At the end of the period, the roles and privileges are revoked, returning the user account to their pre-elevation access rights.

Note

PIM is an Azure AD Premium P2 or Enterprise Mobility + Security E5 feature.

PIM has a few key terms that you’ll need to understand:

• Assignment: This describeshow the user is granted the role. In the case of Eligible, it means a user has to perform an action to use the role, such as requesting elevation or asking for approval. In the case of Active, it means the user doesn’t have to do anything to request the role.

• Duration: This describeshow long a particular assignment is active. It can be permanent (no expiration date) or time-bound, meaning it will be active only for a specific period of time.

For example, John is a full-time employee and needs to periodically be able to perform functions in the Exchange Administrator role. His assignment would be Eligible, while the duration would be permanent.

In another example, Kay is a temporary worker whose contract ends on July 31. She periodically needs to be elevated to be able to perform user administration functions. Her assignment would be Eligible, while the duration would have an end date of July 31.

PIM for Azure AD roles and Azure resources can be configured in the Azure portal on the Identity Governance blade, as shown in Figure 3.12:

Figure 3.21 – Privileged Identity Management

Next, you’ll look at configuring a simple assignment.

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.