Forum Discussion
Sentinel RBAC in the Unified portal: who has activated Unified RBAC, and how did it go?
Following the RSAC 2026 announcements last month, I have been working through the full permission picture for the Unified portal and wanted to open a discussion here given how much has shifted in a short period.
A quick framing of where things stand. The baseline is still that Azure RBAC carries across for Sentinel SIEM access when you onboard, no changes required. But there are now two significant additions in public preview: Unified RBAC for Sentinel SIEM itself (extending the Defender Unified RBAC model to cover Sentinel directly), and a new Defender-native GDAP model for non-CSP organisations managing delegated access across tenants.
The GDAP piece in particular is worth discussing carefully, because I want to be precise about what has and has not changed. The existing limitation from Microsoft's onboarding documentation, that GDAP with Azure Lighthouse is not supported for Sentinel data in the Defender portal, has not changed. What is new is a separate, Defender-portal-native GDAP mechanism announced at RSAC, which is a different thing. These are not the same capability. If you were using Entra B2B as the interim path based on earlier guidance, that guidance was correct and that path remains the generally available option today.
A few things I would genuinely like to hear from practitioners:
- For those who have activated Unified RBAC for a Sentinel workspace in the Defender portal: what did the migration from Azure RBAC roles look like in practice? Did the import function bring roles across cleanly, or did you find gaps particularly around custom roles?
- For environments using Playbook Operator, Automation Contributor, or Workbook Contributor role assignments: how are you handling the fact those three roles are not yet in Unified RBAC and still require Azure portal management? Is the dual-management posture creating operational friction?
- For MSSPs evaluating the new Defender-native GDAP model against their existing Entra B2B setup: what factors are driving the decision either way at your scale?
Writing this up as Part 3 of the migration series and the community experience here is directly useful for making sure the practitioner angle is grounded.
2 Replies
- Mohit_Kumar1
Microsoft
If interested in GDAP Public preview: Configure delegated access with governance relationships for multitenant organizations - Unified security operations | Microsoft Learn. If you are interested in moving to defender - The Unified SecOps Transition — Why It Is a Security Architecture Decision, Not Just a Portal Change | Microsoft Community Hub
Mohit, thank you for these. Both links are directly relevant, and the governance relationships documentation fills in detail the article needed.
A few points I want to confirm before updating the article:
The three‑step handshake I described is directionally correct, but the documentation makes it clear that the governed tenant must first enable receiving governance invitations. That setting is off by default in Tenant Governance settings, and it is an important prerequisite I had not included.
The role requirements are also more specific. The governing tenant needs a Tenant Governance Relationship Administrator to manage the relationship. The governed tenant needs a Tenant Governance Administrator to send the initial invitation. Assigning permissions to a remote tenant group in the governed tenant requires either User Access Administrator in Azure RBAC or User Administrator in Entra RBAC. In environments where those roles are tightly controlled, this becomes a meaningful pre‑migration step.
The security group constraints are also important. Groups used in the relationship template must have SecurityEnabled set to true, IsAssignableToRole set to true, and cannot be Microsoft 365 unified groups. That last point will catch teams who default to M365 groups.
On the Unified SecOps transition blog post, the framing of this as a security architecture decision rather than a portal change is exactly the positioning I have been aiming for. The two‑tier data architecture table is something I plan to reference in later parts, especially Part 5 on the MSSP migration playbook.
One question for you: the documentation describes assigning remote tenant groups to Azure Resource Manager resources in the governed tenant to enable Sentinel management. Is the expectation that this ARM role assignment is required in addition to the Defender portal governance relationship, or does the Defender portal relationship handle Sentinel RBAC once the remote tenant groups are synchronised? The documentation suggests both are needed, but I want to confirm before writing it into the article.
