With Microsoft's implementation of Granular Delegated Admin Privileges (GDAP), Liongard has updated the Microsoft 365 (M365) inspector to align with these new protocols. To accurately configure an M365 inspector within this framework, it is necessary to utilize an account that possesses specific roles for authentication with Partner Center and associated M365 tenants. The required roles include 'Cloud Application Administrator', 'Directory Writers', 'Global Reader', 'Security Reader', and 'Reports Reader'. Each role contributes to a comprehensive set of permissions that enables the inspector to perform its functions without compromising on the principle of least privilege.
Roles Explanation:
Cloud Application Administrator:
This role allows management of cloud applications. It's not as expansive as a full administrator role, but it provides sufficient privileges for tasks related to cloud applications without granting full administrative rights. It's a role suited for those who manage cloud-based applications and services within Azure.
Why does Liongard require it?
Without this role, we are unable to acquire consent from the child tenant using CPV in the Partner Center API. We get back a 403 HTTP error from the Partner Center API, indicating that an account without this role lacks the requisite permissions.
This is what the error would look like in our platform if a client set up a brand new child launchpoint without this role:
Directory Writers:
This role can read and write basic directory information, usually granted to applications rather than individual users. It's not typically used for user accounts but is essential for applications that need to write data to the directory services.
Why does Liongard require it?
The Directory Writers role is required to call any endpoint that needs a Directory.Read.All scope, including https://graph.microsoft.com/v1.0/groupLifecyclePolicies. To get endpoints that rely on this scope to work, there must be a GDAP Directory Writers role set up. Liongard does not actually write any information, as we only request the Read scope; permissions in MS work as a union of the set of roles and set of scopes, so to write, we would need to request the Directory.ReadWrite.All scope (which Liongard does not).
We get back a 401 error from this endpoint (it just happens to be the first one that fails, but there are others):
Global Reader:
The Global Reader role can view everything that a Global administrator can, without having the ability to edit or change any settings. This role is suitable for auditing and review purposes, ensuring compliance without risking changes to the system configurations.
Why does Liongard require it?
The inspection (parent launchpoint in our testing instance) completes with no failures but the Sharepoint section of the dataprint is missing some data in sites, lists, pages, and drives
Security Reader:
The Security Reader role can view security-related policies across Microsoft 365 services but does not have permissions to change any settings. This role is useful for roles that need to understand the security posture of the environment but should not make changes, such as compliance officers or security operations teams.
Why does Liongard require it?
Inspector completes, however, Exchange Online → Mailboxes is also not being populated. Same information missing as Reports Reader.
Reports Reader:
This role can view various reports across Microsoft 365 services to monitor usage and identify trends. It does not include the ability to make any changes to services or settings. It is typically used by those in roles that require the ability to review but not alter the reporting data.
Why does Liongard require it?
Without this role, Mailbox data is not acquired (e.g. Storage_Used_In_Bytes), as Liongard lacks the required permissions. One of the endpoints responsible for populating this data fails with a 403 error: https://graph.microsoft.com/beta/reports/getMailboxUsageDetail(period='D7')?$format=application/json.
Without this data, User data, like user licensing data, will also be missing in the dataprint, as the endpoints that populate individual user data also fail.
How does the Liongard Entra ID app function?
Initial Enterprise app creation:
The parent tenant creates an enterprise Liongard application in their instance. Children automatically create an enterprise Liongard application when the parents do
Authentication:
We use the provided Refresh Token to obtain a parent access token and child access token, if applicable. If we’re getting a child access token, we use CPV to grant the scopes, whose functions are listed when in the initial inspector setup.
Inspections:
We use the access token obtained in the authentication section to call endpoints and obtain the data required inthe dataprint
Does Liongard store the M365 account credentials?
Liongard does not store the M365 account credentials: As per best practices for security, Liongard does not keep the actual account credentials used to authenticate with Microsoft services.
Liongard does store an OAuth token that is generated when using the “Sign-in to Microsoft” button within the inspector: This token is then used for subsequent inspections, which avoids the need to store and use the actual credentials each time, enhancing security by using tokens that can be limited in scope and duration.
Furthermore, these OAuth tokens are never stored in plain text, and are always passed around encrypted and over safe channels.