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 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.