I need a central place to manage both on-demand and ambient (always-on) RBAC assignments for human users. Should these assignments be created directly at the tenant root group, or one level below it in the company-level group? Best practices seem to recommend keeping the tenant root mostly empty, but assigning permissions at the company level means some administrators would not have direct access to the tenant root. I'm relying on inheritance to propagate these permissions to subscriptions and resources, so I'd like to understand the recommended structure.
2 Answers
It depends on what each person actually needs, but most users should not receive permissions at the tenant root. Assigning access at the company-level group will generally inherit down to its subscriptions and resources, while keeping the highest scope more restricted. Apply least privilege and move assignments even lower when users only need access to specific areas. Also keep the number of highly privileged administrators small and maintain an emergency-access account for recovery scenarios.
For ordinary access, place assignments at the lowest scope that satisfies the requirement. Resource-group-level assignments are often a good target, but that requires a consistent hierarchy, automation, and disciplined ownership. If users need access across the entire organization, the company-level group is usually more appropriate than assigning directly at the tenant root.
By ambient permissions, I mean access that is always active rather than something users must request. In this case I’m depending on inheritance to pass those permissions down to the underlying resources.
That matches my current approach. I’m also using on-demand elevation for the global administrator role so those administrators can obtain tenant-root access when it is genuinely required.