Lately, I have participated in multiple discussions regarding MSPs access to Microsoft cloud resources in the context of Azure Sentinel and M365 Defender. In the MSP scenario, access to both resources is crucial but what makes it complicated is that there isn’t one solution that covers and grants access to both solutions.

In this blog, I will demonstrate what’s needed to achieve access to both Azure Sentinel & M365 Defender from MSPs point of view. The topic is huge, and for that reason, I decided to publish content on multiple posts. Let’s get started!

Solutions

In my example scenario I have used the following solutions to grant access to the needed resources:

Azure Lighthouse
- For Azure Sentinel access with Privileged Access Groups (PAG)
Azure AD Identity Governance packages
- B2B Guest access
M365 Defender RBAC configured
- Role-based access for necessary groups

There are alternative approaches and Azure AD Identity Governance Packages & Privileged Identity Management PAG groups are not mandatory to achieve the desired outcome. I used those in my example case for better B2B identity management and security (just-in-time access) with Privileged Identity Management PAG groups. The latter one is, in my opinion, an important security factor in this scenario.

Architecture

The architecture picture below is originally made by my good friend @santasalojoosua, who has written an excellent blog about Securing Azure Lighthouse with Azure Policy and Azure Privileged Identity Management, a must-read if you are planning to use Azure Lighthouse in MSP scenario. Quote from Joosua: “One of the best ways to secure any administrative Azure use is removing permanent delegated access from MSP side user accounts to customer tenants – And as always auditing via Azure Monitor, and Azure Policy will provide insights into compliance, and restrict which MSP’s can be enabled for delegated resource management in the first place”.

What I would like to emphasize from the picture below is that Azure Sentinel access is granted through Azure Lighthouse (cross-tenant management) and M365 Defender (M365D) access is granted through Azure AD B2B user identities & groups that are configured in the M365D management portal (security.microsoft.com) ‘permissions & roles’ section.

Configurations

Azure AD Privileged Access Groups

I have two customer environments and I have created corresponding Privileged Access Groups (PAG) for the selected roles in the customer’s Azure subscriptions in the context of Azure Sentinel. If you are wondering where is Logic App Contributor role, I know it’s missing and this role list is not perfect, I was a bit lazy 🙂

The benefit of using PAGs is the MSP admins don’t have permanent access to the customer’s environment. Permissions are elevated when those are needed through PAGs.

To create the PAG group select “Azure AD roles can be assigned…” and once it’s created enabled it for “Privilege Access”. Thomas Naunheim has written an excellent deep-diver about Privilege Access Groups (PAG) if you would like to deepen your information or consider additional scenarios.

Azure Lighthouse

Azure Lighthouse is needed for cross-tenant management scenarios and Azure Sentinel is underneath this category. Depending on roles and responsibilities there are alternative approaches for the delegation, such as subscription level or resource group level. In my example, I used a resource group approach, template parameters found below.

Azure Lighthouse deployment samples can be found from Azure GitHub. The Azure Lighthouse deployment is straightforward but pay attention to permissions and test everything carefully before implementation.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "mspOfferName": {
      "value": "FetaDS Sentinel Managed Service"
    },
    "mspOfferDescription": {
      "value": "Provides a managed services capability for Azure Sentinel"
    },
    "managedByTenantId": {
      "value": "<Insert MSSP tenant ID here>"
    },
    "authorizations": {
      "value": [
        {
          "principalId": "0c30b7cd-875a-4759-a880-b7fbbb0ee75b",
          "principalIdDisplayName": "PAG - LH Azure Subscription Reader - Customer Dsync",
          "roleDefinitionId": "acdd72a7-3385-48ef-bd42-f606fba81ae7"
        },
        {
          "principalId": "51680480-0df0-4c1b-8b1f-bbcca9c08d6f",
          "principalIdDisplayName": "PAG - LH Azure Sentinel Reader - Customer Dsync",
          "roleDefinitionId": "8d289c81-5878-46d4-8554-54e1e3d8b5cb"
        },
        {
          "principalId": "c6693a11-03dc-49c9-82ef-3a0d4fe31445",
          "principalIdDisplayName": "PAG - LH Azure Sentinel Responder - Customer Dsync",
          "roleDefinitionId": "3e150937-b8fe-4cfb-8069-0eaf05ecd056"
        },
        {
          "principalId": "c12d77c8-c89a-4a74-8c5b-5b6af703f260",
          "principalIdDisplayName": "PAG - LH Azure Sentinel Contributor - Customer FDsync",
          "roleDefinitionId": "ab8e14d6-4a74-4a29-9ba8-549422addade"
        }
      ]
    },
    "rgName": {
      "value": "Emea-rg"
    }
  }
}

That’s it!! After Azure Lighthouse deployment the Azure Sentinel cross-tenant management access is ready for testing.

Microsoft 365 Defender

With Azure Lighthouse, you will get access to customer Azure resources based on the permissions defined on the Lighthouse template. Unfortunately, M365 management doesn’t rely on the same permission model and for that reason, you need to use Azure AD B2B context for managing M365 Defender.

For multi-tenant access following steps are needed:

Enabled role-based access control in M365 Defender portal
Grant access to Azure AD groups
Configure Access Packages for access request and provisioning
Manage access request and audits in Myaccess portal

Create Azure AD Groups

Groups and access is created and managed in customer’s Azure AD tenant. In the example scenario I created three (3) groups:

SOC – Tier 1 Analysts Group
SOC – Tier 2 Analysts Group
MSSP Analyst Approvers

M365 Defender RBAC

In M365D, enable RBAC usage and add just created Azure AD groups into admin roles. Tier-2 analyst group has “live response capabilities” addition to Tier-2 group.

Azure AD – Identity Governance & Access Packages

To establish access to M365 Defender workloads customer needs to invite MSPs accounts as guest to own tenant and grant access to M365 Defender resources. This can be establish from Azure AD side in many ways but in my example I have the following items configured:

In customer Azure AD Identity Governance – Add MSP as a connected organization
In customer Azure AD Identity Governance – Create a resource catalog in Azure AD
In customer Azure AD Identity Governance – Create access packages for MSP resources in Azure AD Identity Governance

Access Packages

I followed Microsoft guidance here and created two access packages, one for Tier-1 analysts and one for Tier-2 analysts. In a nutshell configuration contains:

Requires a member of the AD group MSSP Analyst Approvers to authorize new requests
Has annual access reviews, where the SOC analysts can request an access extension
Can only be requested by users in the MSPs SOC Tenant
Access auto expires after 365 days

Access Request Link

When everything has been set up you can provide a link to MSP to both access packages. MSPs analysts can then request access to the resources defined in the access packages. If approval is configured in the flow the approver needs naturally approve the requests before those are active.

Both access packages grants access to one resource group, and those groups has permissions to M365D management portal.

M365 Lighthouse

Let’s throw one possible alternative solution on the table, M365 Lighthouse (M365 LH). M365 LH was released in 2020 MS Ignite and is currently on private preview mode. I haven’t participated in it and don’t have insights about its capabilities, for now. M365 Lighthouse is designed for Managed Service Providers (MSPs) and it offers a central console where you can manage all your Microsoft 365 (M365) clients in a single dashboard. To the best of my knowledge, the solution contains Device Compliance & Threat Management at the first phase so it’s unknown does it help in MSPs access to M365 Defender.

More information from Microsoft blog.

User Experience

Request Access

When the link is delivered the SOC Analysts from the MSP side can request access to the resources. When access is requested it goes to the approver, in my case MSP Access Approvers group. When approved the accounts are created and permissions granted in the customer Azure AD tenant..

Managing Azure Sentinel Incidents

With Azure Lighthouse deployed you can have a multi-workspace incident view for central incident monitoring and management across multiple multiple Azure Sentinel workspaces.

First, login to Azure environment and elevate access to necessary customer environment through PIM & PAG
Secondly, select all subscriptions from global directory filter
Thirdly, navigate to Azure Sentinel and select all Azure Sentinel workspaces

Enjoy the central incident monitoring and management view

Managing M365 Defender Incidents

If you have enabled brand new capability, M365 Defender integration with Azure Sentinel you stream all M365D incidents into Azure Sentinel and keep them synchronized with bi-directional sync between both portals. Feature description from docs.microsoft.com below. I tested the feature in the private preview phase and it’s really valuable for managing the incidents between the solutions.

Incidents from M365D (formerly known as Microsoft Threat Protection or MTP) include all associated alerts, entities, and relevant information, providing you with enough context to perform triage and preliminary investigation in Azure Sentinel. Once in Sentinel, Incidents will remain bi-directionally synced with M365D, allowing you to take advantage of the benefits of both portals in your incident investigation.

This integration gives Microsoft 365 security incidents the visibility to be managed from within Azure Sentinel, as part of the primary incident queue across the entire organization, so you can see – and correlate – M365 incidents together with those from all of your other cloud and on-premises systems

Common use cases and scenarios (docs.microsoft.com)

One-click connect of M365 Defender incidents, including all alerts and entities from M365 Defender components, into Azure Sentinel.
Bi-directional sync between Sentinel and M365D incidents on status, owner, and closing reason.
Leverage M365 Defender alert grouping and enrichment capabilities in Azure Sentinel, thus reducing time to resolve.
The in-context deep link between an Azure Sentinel incident and its parallel M365 Defender incident, facilitates investigations across both portals.

Considerations (partly from docs.microsoft.com)

Using both mechanisms together is completely supported, and this configuration can be used to facilitate the transition to the new M365 Defender incident creation logic.
- This will, however, create duplicate incidents for the same alerts.
To avoid creating duplicate incidents for the same alerts, it’s recommended to turn off all Microsoft incident creation rules for M365 products (MDE, MDI, and MDO – see MCAS below) when connecting M365 Defender.
- Keep in mind that if you do this, any filters that were applied by the incident creation rules will not be applied to M365 Defender incident integration.
For Microsoft Cloud App Security (MCAS) alerts, not all alert types are currently onboarded to M365 Defender.
- To make sure you are still getting incidents for all MCAS alerts, you must keep or create Microsoft incident creation rules for the alert types not onboarded to M365D.
Take into account that delegated access to M365D allows access to a single tenant per browser.

Azure Sentinel has direct link which can be used to navigate to another tenants (“tid aka TenantID”)

When navigating from Azure Sentinel to M365D with the direct link I have found that it doesn’t work in all scenarios as expected. If you face similar errors:
- Browser re-fresh
- Navigate to the incident tab
- New login to the portal

M365D delegation grants access to M365 Defender and device-related data.
- Depending on how roles and responsibilities are defined in your organization and with MSP more roles and permissions might be needed to cover other security solutions (MDI, MDO, MCAS & ASC)
- Azure AD Security would be the perfect role to cover M365 workloads if read permissions are enough to fill your needs

Securing and auditing the access will be covered in the second post of this topic. Stay tuned!

References

Announcing new Microsoft 365 Lighthouse

Microsoft Defender for Endpoint in the Microsoft 365 security center – Microsoft 365 security | Microsoft Docs

Microsoft 365 Defender integration with Azure Sentinel | Microsoft Docs

Sam's Corner

Site about cloud security

MSSP Access to Azure Sentinel and M365 Defender

Solutions

Architecture