Microsoft 365 administrators have various roles and tasks that they need to manage to ensure that the organization runs smoothly.
Authorization concepts that are familiar from the on-premise world cannot be replicated 1:1 in the Microsoft Cloud. In order to ensure data security, several steps need to be implemented.
These are as follows:

 

PIM:

With the Privileged Identity Management (PIM) function, Microsoft 365 offers the option of assigning predefined administrator rights to time-limited and only explicitly authorized persons.
In order for such roles to be assigned to the corresponding users, these users must fulfil corresponding requirements. These include a multifactor authentication (MFA) obligation, authorization for the corresponding PIM role, etc.
Users who have PIM authorization should only be able to request this for higher-level, non-daily work. The aim is for the individual departments to be self-managed or managed by so-called delegates.

 

Administrative units:

From a technical perspective, each department of a company is assigned to so-called administrative units (AU). This action can be used to define users who explicitly have administrative authorizations for this dedicated AU only. As certain areas are not only managed by the corresponding AU, users of the Delegated Administrators can also be assigned to several AUs.
Authorizations for the respective AUs can be assigned and removed in several ways. The following options are currently available:

  • Direct assignment of individual users to an AU. (Not recommended)
  • Assignment via M365 groups (static and dynamic groups possible)
  • Dynamic assignment via predefined attributes.

 

AUs also support the following compliance solutions:

  • Data lifecycle management
  • Data loss prevention (DLP)
  • Communication compliance
  • Records management
  • Sensitivity labelling

 

SharePoint sites (through MS Teams)

Whenever possible, new SharePoint online (SPO) sites should be created by Microsoft Teams. This has several advantages, such as the optional availability of the SPO site in Microsoft Teams. Furthermore, you can decide what kind of site (In Teams: Team) should be created.

The following options are available:

  • Org wide (This type of Microsoft Teams team is automatically displayed in Teams for every user who has a cloud or synchronized account. Each user can also search for the corresponding site on the entire tenant and move freely, depending on their document authorization).
  • Public (Public sites are basically similar to Org wide sites. However, they differ in that the sites are not automatically assigned to each user in the Teams client. Nevertheless, every user can search for the site and consume content).
  • Private (From Microsoft Teams’ point of view, private sites offer the highest level of security. Only users who are explicitly members can have access to the corresponding site. An unauthorized user cannot search for private sites).
  • Shared (Shared sites were developed by Microsoft to enable cross-tenant work with partners and/or customers. Since the introduction of shared channels, employees no longer have to switch between the tenant accounts by logging in and out, but can access the shared sites directly in their own tenant. Provided they are authorized). *1

*1) In order for shared channels to be used, a two-sided trust position is required for each customer/partner, which is configured by Azure B2B.

 

Data Classification

Labelling is basically used to ensure that confidential documents are not leaked. This can be defined internally and externally, but also at departmental level (e.g. finance, HR, management, police, etc.). There are various application options for labels, which allow customers to design and use them individually.
As a further example, labels can also be used to ensure that documents classified with the “Internal” label in this example cannot be sent by e-mail to external recipients.

 

DLP

When implementing AUs, dedicated custom DLPs can be created which are focussed on the respective AU and its users.
These DLP policies can be created and applied separately for each AU or individually.

 

PIM roles

In the authorization concept for the Canton of Aargau, only the role of Global Administrator (GA) is to be provided via PIM. A group of administrators is defined by the customer, who can apply for the corresponding GA role. PIM also offers other administrator roles, but we recommend that these are not managed via PIM but via the AUs.
This ensures that administrators cannot assign roles to each other for no reason.

The length of GA access via PIM should be limited to a maximum of 4 hours so that administrators do not work with the highest authorization level for longer than necessary.

 

Azure Subscriptions

The authorization concept described is aimed at Entra ID and Microsoft 365 apps and services.
Azure services such as Azure Speech services or storage accounts are not managed by Microsoft 365. These are Azure services.
Azure Services can be managed in the following two ways:

  • Authorizations on the respective Azure subscription on which the services are stored
  • Authorizations on the respective resource group on which the services are stored.

Here too, the authorization can be defined and assigned using several levels.

 

Authorization matrix as a basis for decision-making

A dedicated authorization matrix makes sense, especially in connection with administrative units. Dedicated support teams can be set up depending on the area (country location, department, division, etc.). These units can then be divided more granularly and the corresponding authorizations controlled. It is recommended that there is a superordinate IT department that is responsible for the management and administration of the respective administrative units.

Location Role Entra ID Purview Defender EXO SPO Power Platform Teams M365 Apps Intune Viva PIM (Global Admin)
Department Default End User N/V N/V N/V N/V N/V Environment Maker N/V N/V N/V N/V NO
Department Power User N/V N/V N/V N/V N/V Environment Maker N/V N/V N/V N/V NO
Department Guest User N/V N/V N/V N/V N/V N/V N/V N/V N/V N/V NO
Department 1st Level Support Message Center Reader N/V N/V N/V N/V Environment Maker N/V Read only Operator NO
Department 2nd Level Support Message Center Reader

Authentication Admin (AU Level)

Cloud Device Admin (AU Level)

User Admin (AU Level)

Guest Inviter

N/V N/V View-Only MGMT

Mail-Forwarding (Custom RBAC Role)

N/V Environment Admin Teams Communication Support Specialist

Teams Administrator (AU Level)

Teams Device Administrator (AU Level)

Company-specific authorization definition Read Only Operator Company-specific authorization definition NO
Department Application Manager N/V N/V N/V N/V N/V N/V N/V N/V NO

 

Location Role Entra ID Purview Defender EXO SPO Power Platform Teams M365 Apps Intune Viva PIM (Global Admins)
Superior IT 3rd Level Support Message Center Reader

Authentication Admin

Cloud Device Admin

User Admin

Guest Inviter
Helpdesk Admin

Knowledge Admin

Directory Readers

Report Readers

Application Admin

Groups Admin

License Admin

N/V Quarantine Admin

Seurity Operator

Exchange Administrator SharePoint Administrator Environment Admin

Power Platform Administrator

Teams Communication Support Engineer

Teams Device Administrator

Teams Administrator

Company-specific authorization definition Intune Administrator Company-specific authorization definition NO
Superior IT Lead Engineer 3rd Level Supporter +

User Administrator

Global Reader

Compliance Administrator Security Operator Exchange Administrator SharePoint Administrator Power Platform Administrator Teams Administrator Company-specific authorization definition Intune Administrator Company-specific authorization definition YES
Superior IT Architect Message Center Reader

License Administrator

Authentication Administrator

N/V Security Reader Security Reader Security Reader Security Reader

Power Platform Administrator

Security Reader Company-specific authorization definition Intune Administrator Company-specific authorization definition YES
Superior IT CSO N/V N/V Security Reader Security Reader Security Reader Security Reader Security Reader Security Reader NO
Superior IT Security Authentication Administrator

Privileged Role Administrator

Global Reader

Conditional Access Administrator

Cloud Application Administrator

Identity Governance Administrator

N/V Security Administrator Security Administrator Security Administrator Security Administrator Security Administrator Company-specific authorization definition Intune Administrator Company-specific authorization definition YES
Superior IT Risk Global Reader Compliance Administrator

Insider Risk Management Administrator

Security Reader Security Reader Security Reader Security Reader Security Reader Company-specific authorization definition Security Reader Company-specific authorization definition NO
Superior IT Legal Global Reader Insights Reader Security Reader Security Reader Security Reader Security Reader Security Reader Company-specific authorization definition N/V Company-specific authorization definition NO
Superior IT Compliance Global Reader

Identity Governance Administrator

Compliance Administrator

Customer Lockbox Access Approver

Security Reader Security Reader Security Reader Security Reader Security Reader Company-specific authorization definition N/V Company-specific authorization definition YES (After approval)
Superior IT Licence Management Licence Administrator

Billing Administrator

Guest Inviter

N/V N/V N/V N/V N/V N/V Company-specific authorization definition N/V Company-specific authorization definition NO

 

Supplements

This matrix is intended as an illustrative example; it can of course be adapted and/or expanded depending on the requirements of your own company.

  • The distinction between “Default Users” and “Power Users” are the local authorisations on the user’s own device.
    The power user also has the authorisation to install something on their device, whereas the default user does not have this option.

 

  • How Exchange online Custom RBAC Roles can be built and the automatic Administrative Unit on-boarding, as well as a possible training matrix, which is related to the authorisation matrix, is dealt with in a Part two of this article.