While researching about restricting access to Microsoft 365 Defender and its three portals (M365 Defender, Defender for Identity and Microsoft Cloud App Security [MCAS]) I’ve noticed a few quirks. In the last couple of weeks, I sat down and took some time to investigate the authorization structure behind all three portals and how to restrict access to them. This is not your usual „follow the five steps and you’re done“ kind of post but rather an insight into how I went down into the rabbit hole with lots of twists and turns.
Why do we need to restrict access?
By default, the Global Reader role in Azure AD has full access to all three portals. With Global Reader being a common role to assign to users, e.g., consultants performing work in a client’s tenant, customers feel uncomfortable with consultants having read access to the vast amount of highly sensitive personal identifiable information (PII) in the Defender apps.
Three different ways of authorization for three portals
Defender for Identity (MDI) – https://portal.atp.azure.com
When an MDI instance is created, MDI creates three security groups in Azure AD. A user only gets access to the MDI Portal if they are in one of the three groups.
M365 Defender – https://security.microsoft.com
By default, RBAC is disabled.
Microsoft Cloud App Security (MCAS) – https://portal.cloudappsecurity.com
No RBAC, no security groups but users can be invited (not integrated with Azure AD)
What access does a user or Global Reader have by default?
To see what permissions a basic user and the Global Reader role have I set up a fresh M365 tenant with M365 Defender enabled.
| Role | M365 Defender (w/out RBAC) | Defender for Identity | Cloud App Security |
| User | No | No | No |
| Global Reader | Yes (read access) | No (blocked by Security Groups setup by MDI) | Yes (read access) |
As you can see, Global Reader has full access to M365 Defender and MCAS. A quick fix might be to restrict access to M365 Defender by enabling RBAC in its Settings (security.microsoft.com > Settings > Endpoints > Roles > Turn on Roles).
Does enabling RBAC in M365 Defender restrict access?
| Role | M365 Defender (with RBAC) | Defender for Identity | Cloud App Security |
| User | No | No | No |
| Global Reader | Yes (read access w/out MDO alerts) | No (blocked by Security Groups setup by MDI) | Yes (read access) |
As you can see, we somewhat “restricted” access to M365 Defender but now there’s an issue with Defender for Office 365 (MDO) alerts (more on the limitations below). The major issue is though that MCAS is still wide open.
And if you’ve looked at MCAS before you know that there’s a TON of information in there that only a selected group of users (less is better) should have access to.
How does Microsoft want us to solve this problem?
My first action was to ask Microsoft how to restrict access as it looked like I was missing something. The answer was that it’s not possible. A Microsoft user chimed in that he had the same issue, another user mentioned that he restricted access to these portals via a Conditional Access Policy.
Let’s test this by creating a Conditional Access policy
I went ahead and started building this in my demo tenant. Here’s a brief walkthrough of the steps I took on how to set up two security groups as “Privileged Access Groups” (PAG) that users can get just in time access to via Privileged Identity Management (PIM).
- Create two Azure AD security groups as privileged access group
- SG M365 Defender Admin
- Add users who should have administrative permissions to M365 Defender apps via Eligible assignments
- SG M365 Defender User
- Add users to the group via Eligible assignments
- SG M365 Defender Admin
- Add security groups to M365 Defender AATP Security Groups (to access MDI)
- SG M365 Defender Admin to Azure AATP [tenant name] Administrators
- SG M365 Defender User to Azure AATP [tenant name] Viewers
- Create a conditional access policy
- Users and groups
- All users
- Exclude
- Directory roles: Global Administrator
- Users and groups: SG M365 Defender Admin, SG M365 Defender User
- Cloud apps and actions
- Include selected apps
- Microsoft Cloud App Security (05a65629-4c1b-48c1-a78b-804c4abdd4af)
- Azure Advanced Threat Protection (7b7531ad-5926-4f2d-8a1d-38495ad33e17)
- Include selected apps
- Grant: Block Access
- Users and groups
- In M365 Defender:
- Create two roles:
- M365 Defender Admin: enable all options
- M365 Defender User: enable TVM and Alerts Investigation
- Add AAD Security groups (SG M365 Defender Admin and SG M365 Defender User) to M365 Defender RBAC roles respectively
- Add AAD Security groups (SG M365 Defender Admin and SG M365 Defender User) to M365 Defender device groups
- Create two roles:
Well, we did it … did we really?
After setting everything up, this is what the access matrix now looks like:
| Role | M365 Defender | Defender for Identity | Cloud App Security |
| User | No | No | No |
| User w/ security group | Yes (read access w/out MDO) | Yes (as per RBAC) | No |
| Global Reader | No | No | No |
| Global Reader w/ security group | Yes (read access w/out MDO) | Yes (as per RBAC) | Yes (read access) |
We restricted access to the Global Reader role but as mentioned above there are a few issues:
- Alerts for Defender for Office 365 (MDO) can’t be seen, accessed, or hunted for (via Advanced Hunting),
- Access to M365 Defender and MCAS is read-only if a non-Administrator role is assigned to a user.
On the other hand, users who shouldn’t have access to these portals now get to see these messages when they try to access MDI and MCAS.
How to see MDO alerts in the M365 Defender Portal
For reasons unknown, you need to assign a role from the (old) Security & Compliance Center (protection.office.com) for users to see MDO alerts in the M365 Defender portal.
You can take care of this by doing the following:
- Create a new role manually, assigning a role (e.g. Security Reader) in the M365 Defender Portal under Permissions & roles > Email & collaboration roles > Roles
- Assign an Azure AD role that has access to the M365 Defender portal via the security group setup above (PAG). You can see what roles are passed through from Azure AD to M365 Defender Portal under Permissions & roles > Azure AD roles.
A description of each role can be found at https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/permissions-in-the-security-and-compliance-center?view=o365-worldwide
A potential solution is to add the role (e.g. Security Administrator) to the SG-M365-MDE-ADMIN security group (Security Reader to the SG-M365-MDE-USER role respectively) as a permanent active assigned role.
The second option is a little bit more elegant as an admin wouldn’t have to manually add users to the roles in the M365 Defender portal. This increases the ability to audit who requested access to the portals.
If a user needs full access to any M365 Defender portal they would only need to activate the SG-M365-MDE-ADMIN group via PAG and would receive:
- Membership to the Azure AATP [tenant name] Administrators security group to access MDI,
- The Security Administrator role to have full access to MCAS and M365 Defender (including MDO alerts).
| Role | M365 Defender | Defender for Identity | Cloud App Security |
| Security Reader | No | No | No |
| User Security Group via PAG | Yes (read access) | Yes (read access) | Yes (read access) |
| Admin Security Group via PAG | Yes (write access) | Yes (write access) | Yes (write access) |
Other ideas on how to restrict access to M365 Defender
I thought about other ways on how to restrict access to the three portals as I didn’t like that the M365 Defender portal was still accessible.
In hindsight, it’s most likely not a good idea to restrict access to this portal to users as the Quarantine section is now part of it (under Email & collaboration > Review > Quarantine https://security.microsoft.com/quarantine).
But I’ll add the ideas to this post anyway to give you an idea of what is possible (or not) with conditional access policies as well as using an MCAS policy.
1. Add the App ID of the M365 Defender portal to the conditional access policy
My idea was to use the application ID of the Compliance Center app (which is now the M365 Defender Portal) to add to the just created conditional access policy to completely block access to that portal.
I found the app ID (80ccca67-54bd-44ab-8625-4b79c4dc7775) of the Compliance Center but was
- Unable to add the app to the conditional access policy through the GUI,
- Unable to update the existing conditional access policy or create a new conditional access policy through Powershell because
The problem is that the Compliance Center app is a First Party Application that can’t be added to a conditional access policy.
2. Block access to M365 Defender portal (M365D, MDI, MCAS) via MCAS policy
With some experience of MCAS under my belt, I looked into using a conditional access policy in MCAS to restrict access. First, you need to import both security groups created above into MCAS.
- Settings (top right corner) > User groups > Import user group
- Choose Office 365 (Azure AD)
- Select security groups (e.g. SG M365 Defender Admin and SG M365 Defender User)
- The Office 365 administrator group is imported by default and includes all administrators in the tenant.
Next, edit the Microsoft Defender Security app in MCAS to add security.microsoft.com as a User-defined domain and enable the app to be used for conditional access policies.
- Investigate > Connected apps > Conditional Access App Control apps
- Microsoft Defender Security Center – General > Edit App
- Under user-defined domains add security.microsoft.com
- Check “Use with Conditional Access App Control” box
- Check “Use with Conditional Access App Control” box for all other apps that need to be added to the policy, e.g.
- Microsoft 365 compliance center – General
- Microsoft Cloud App Security – General
- Microsoft Defender for Identity – General
- Security and Compliance – General
Lastly, create the MCAS policy.
- Control > Policies > Conditional access > Create policy > Access policy
- Add name
- Add description
- Filter
- App equal {all M365 Defender apps that need to be blocked – see list above}
- User > From group > does not equal > Office 365 administrator + any other security group
- Actions: Test first (if happy with results set to Block)
- Alerts: Create an alert for each matching event with the policy’s severity (so you know that it works) – can be unchecked
Limitations
Great! Now that we’re done setting everything up, let’s test it out. I quickly found out about the limitations of this setup.
Access control issues
If a user utilizes PIM or PAG to gain access, the MCAS policy blocks even if the user is a member of the security group. MCAS groups (pre-defined Office 365 Administrators group and imported security groups) are only updated every hour!
On the other hand, if you revoke access to the security group or role, the user still might have access to the portals as groups are only updated once an hour.
After the initial sync, groups are updated every hour. (Import user groups from connected apps in Cloud App Security | Microsoft Docs)
Documentation/Audit issues
This is a rather “hidden” way of restricting access and is not integrated with Azure AD roles and security groups. It’s possible to audit who had access but not as easy as analyzing the Azure AD Audit Log.
Summary/Final Words
As you’ve probably noticed restricting access to the M365 Defender portals is not as simple as 1, 2 and 3. There are a lot of nuances, limitations and annoyances with this setup, for example:
- There’s a delay of up to 30 minutes between activating the security group via PAG and eventually seeing MDO alerts in M365 Defender,
- The M365 Defender Portal menu is not updated in real-time depending on what permissions a user has – even with cookies deleted, browser closed and so on. The best solution I came up with was to let it simmer for an hour or overnight and then check again.
I eventually stopped relying on the GUI and instead started using Advanced Hunting which seemed to be much more reliable. To check if a user has access to the MDO alerts you can use the following query:
EmailEvents
| limit 10
Another query to check if a user has access to any table besides the IdentityInfo table (which a normal user has by default) you can use:
search *
| where $table != „IdentityInfo“
To sum this up, I wish there would be one single authorization pane where users can be given access to each Defender product depending on their role. I’ve reached out to a Microsoft program manager who can hopefully pass this feedback on to the M365 Defender Team.