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.
2 Answers
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.
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.
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.
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.