Should RBAC assignments live at the tenant root or the company-level group?
Asked by
MellowCedar42
I need a central place to manage both always-on and on-demand RBAC role assignments for human users. Should these assignments be created directly at the tenant root management group, or one level below it under the company-level group? Best practices seem to discourage placing assignments at the tenant root, but using only the company-level group means some administrators may not have access to manage the tenant root itself. I'm also relying on inheritance so permissions flow down to subscriptions and resources.
Answers
It depends on what each user actually needs, but most people shouldn’t require access at the tenant root. Assigning permissions at the company-level group already gives access across its subscriptions and resources. I’d follow least privilege and place assignments even lower when possible, unless someone genuinely needs tenant-wide access. Global administrators can also elevate their permissions when necessary, so keep that role limited and consider maintaining an emergency-access account for recovery scenarios.
Reply to this answer
For permissions that are meant to be inherited broadly, the company-level management group is usually the better boundary. Putting everything at the tenant root makes the scope wider than necessary and can complicate least-privilege controls. Resource-group-level assignments can provide tighter control, but they require a consistent hierarchy, automation, and ongoing discipline.
VividMaple6: By ambient permissions, I mean assignments that are always active rather than requiring someone to request or activate them. The goal is to use inheritance to pass those permissions down to the appropriate resources.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowCedar42: That’s generally how I have it set up. I also use on-demand elevation for the global administrator role so it can be used when access to the tenant root group is required.