Nov 03 2022 12:52 AM
Nov 03 2022 12:52 AM
To work on Microsoft 365 Defender we have set up MSSP access as defined in https://cloudpartners.transform.microsoft.com/download?assetname=assets%2FAzure-Sentinel-Technical-P.... Now we noticed that with the guest users, which have activated the Security Admin role via the access packages and PIM, we can't access the Threat Policies within the Microsoft 365 Defender tenant. We tested it on our lab tenant, and there the behaviour is the same, but for member users the issues does not arise. Is this expected behavior? If so, is there another way that we can manage our client's threat policies without creating member users in their tenant?
Is the limited support for guest users documented anywhere by Microsoft? It is stated in the docs that sec admin has these permissions, but there is no mention anywhere that this would be limited for guest users.
If anyone has more info on this issue, or even a better way of working, sharing it would be greatly appreciated.
Dec 15 2022 07:32 AM
Dec 16 2022 12:38 AM
Jun 01 2023 08:56 PM - edited Jun 02 2023 11:25 AM
FYI, for anyone else having this problem.
This problem is solved by switching the usertype on the B2B user account from "Guest" to "Member"
Once this is done (and you wait a while, 30 minutes maybe) then the Threat Policies and all settings are visible as a privileged B2B user (Security Admin, Security Reader etc)
Jun 04 2023 11:16 PM
@PhilostYes, we figured that workaround out as well, but for us it's a no-go. Being a member type user gives you access to all the customers' internal resource, i.e. Sharepoint. This is a privacy issue and makes this workaround off limits for us as an MSSP. We looked into locking down access via conditional access policies, but it's unmanageable.
We have a ticket running with Microsoft support on this issue, if a real solution comes from it, I'll update here.
Jun 05 2023 12:11 AM - edited Jun 05 2023 11:26 AM
Yeah, it works in our use case as we are multiple tenancies but the same organisation.
As you will already be aware, the root cause is the way Exchange Online Protection still relies on Exchange PowerShell and legacy Exchange Online permissions structure in general. An area/product group with whom it seems progress is challenging. I dare say lots of complexity. Doesn’t help the pure MSSP use case though…