Resource isolation in a single tenant

Many separation scenarios can be achieved within a single tenant. If possible, we recommend that you delegate administration to separate environments within a single tenant to provide the best productivity and collaboration experience for your organization.

Outcomes

Resource separation - With Azure AD directory roles, security groups, conditional access policies, Azure resource groups, Azure management groups, administrative units (AU's), and other controls, you can restrict resource access to specific users, groups, and service principals. Resources can be managed by separate administrators, and have separate users, permissions, and access requirements.

If a set of resources require unique tenant-wide settings, or there is minimal risk tolerance for unauthorized access by tenant members, or critical impact could be caused by configuration changes, you must achieve isolation in multiple tenants.

Configuration separation - In some cases, resources such as applications have dependencies on tenant-wide configurations like authentication methods or named locations. You should consider these dependencies when isolating resources. Global administrators can configure the resource settings and tenant-wide settings that affect resources.

If a set of resources require unique tenant-wide settings, or the tenant's settings must be administered by a different entity, you must achieve isolation with multiple tenants.

Administrative separation - With Azure AD delegated administration, you can segregate the administration of resources such as applications and APIs, users and groups, resource groups, and conditional access policies.

Global administrators can discover and obtain full access to any trusting resources. You can set up auditing and alerts to know when an administrator changes a resource if they are authenticated.

You can also use administrative units (AU) in Azure AD to provide some level of administrative separation. Administrative units restrict permissions in a role to any portion of your organization that you define. You could, for example, use administrative units to delegate the Helpdesk Administrator role to regional support specialists, so they can manage users only in the region that they support.

Diagram that shows administrative units.

Administrative Units can be used to separate user, groups and device objects. Assignments of those units can be managed by dynamic membership rules.

By using Privileged Identity Management (PIM) you can define who in your organization is the best person to approve the request for highly privileged roles. For example, admins requiring global administrator access to make tenant-wide changes.

Note

Using PIM requires and Azure AD P2 license per human.

If you must ensure that global administrators are unable to manage a specific resource, you must isolate that resource in a separate tenant with separate global administrators. This can be especially important for backups, see multi-user authorization guidance for examples of this.

Common usage

One of the most common uses for multiple environments in a single tenant is to segregate production from non-production resources. Within a single tenant, development teams and application owners can create and manage a separate environment with test apps, test users and groups, and test policies for those objects; similarly, they can create non-production instances of Azure resources and trusted apps.

The following diagram illustrates the non-production environments and the production environment.

Diagram that shows Azure AD tenant boundary.

In this diagram, there are non-production Azure resources and non-production instances Azure AD integrated applications with equivalent non-production directory objects. In this example, the non-production resources in the directory are used for testing purposes.

Note

You cannot have more than one Microsoft 365 environment in a single Azure AD tenant. However, you can have multiple Dynamics 365 environments in a single Azure AD tenant.

Another scenario for isolation within a single tenant could be separation between locations, subsidiary or implementation of tiered administration (according to the "Enterprise Access Model").

Azure RBAC role assignments allow scoped administration of Azure resources. Similarly, Azure AD allows granular management of Azure AD trusting applications through multiple capabilities such as conditional access, user and group filtering, administrative unit assignments and application assignments.

If you must ensure full isolation (including staging of organization-level configuration) of Microsoft 365 services, you need to choose a multiple tenant isolation.

Scoped management in a single tenant

Scoped management for Azure resources

Azure RBAC allows you to design an administration model with granular scopes and surface area. Consider the management hierarchy in the following example:

Note

There are multiple ways to define the management hierarchy based on an organization's individual requirements, constraints, and goals. For more information, consult the Cloud Adoption Framework guidance on how to Organize Azure Resources).

Diagram that shows resource isolation in a single tenant.

  • Management group - You can assign roles to specific management groups so that they don't impact any other management groups. In the scenario above, the HR team can define an Azure Policy to audit the regions where resources are deployed across all HR subscriptions.

  • Subscription - You can assign roles to a specific subscription to prevent it from impacting any other resource groups. In the example above, the HR team can assign the Reader role for the Benefits subscription, without reading any other HR subscription, or a subscription from any other team.

  • Resource group - You can assign roles to specific resource groups so that they don't impact any other resource groups. In the example above, the Benefits engineering team can assign the Contributor role to the test lead so they can manage the test DB and the test web app, or to add more resources.

  • Individual resources - You can assign roles to specific resources so that they don't impact any other resources. In the example above, the Benefits engineering team can assign a data analyst the Cosmos DB Account Reader role just for the test instance of the Azure Cosmos DB database, without interfering with the test web app or any production resource.

For more information, see Azure built-in roles and What is Azure role-based access control (Azure RBAC)?.

This is a hierarchical structure, so the higher up in the hierarchy, the more scope, visibility, and impact there is to lower levels. Top-level scopes affect all Azure resources in the Azure AD tenant boundary. This also means that permissions can be applied at multiple levels. The risk this introduces is that assigning roles higher up the hierarchy could provide more access lower down the scope than intended. Microsoft Entra (formally CloudKnox) is a Microsoft product that provides visibility and remediation to help reduce the risk. A few details are as follows:

  • The root management group defines Azure Policies and RBAC role assignments that will be applied to all subscriptions and resources.

  • Global Administrators can elevate access to all subscriptions and management groups.

Both top-level scopes should be strictly monitored. It is important to plan for other dimensions of resource isolation such as networking. For general guidance on Azure networking, see Azure best practices for network security. Infrastructure as a Service (IaaS) workloads have special scenarios where both identity and resource isolation need to be part of the overall design and strategy.

Consider isolating sensitive or test resources according to Azure landing zone conceptual architecture. For example, Identity subscription should be assigned to separated management group and all subscriptions for development purposes could be separated in "Sandbox" management group. More details can be found in the Enterprise-Scale documentation. Separation for testing purposes within a single tenant is also considered in the management group hierarchy of the reference architecture.

Scoped management for Azure AD trusting applications

The pattern to scope management of Azure AD trusting applications is outlined in the following section.

Azure AD supports configuring multiple instances of custom and SaaS apps, but not most Microsoft services, against the same directory with independent user assignments. The above example contains both a production and a test version of the travel app. You can deploy pre-production versions against the corporate tenant to achieve app-specific configuration and policy separation that enables workload owners to perform testing with their corporate credentials. Non-production directory objects such as test users and test groups are associated to the non-production application with separate ownership of those objects.

There are tenant-wide aspects that affect all trusting applications in the Azure AD tenant boundary including:

  • Global Administrators can manage all tenant-wide settings.

  • Other directory roles such as User Administrator, Administrator, and Conditional Access Administrators can manage tenant-wide configuration within the scope of the role.

Configuration settings such authentication methods allowed, hybrid configurations, B2B collaboration allow-listing of domains, and named locations are tenant wide.

Note

Microsoft Graph API Permissions and consent permissions cannot be scoped to a group or members of Administrative Units. Those permissions will be assigned on directory-level, only resource-specific consent allows scope on resource-level (currently limited to Microsoft Teams Chat permissions)

Important

The lifecycle of Microsoft SaaS services such as Office 365, Microsoft Dynamics, and Microsoft Exchange are bound to the Azure AD tenant. As a result, multiple instances of these services necessarily require multiple Azure AD tenants. Check the documentation for individual services to learn more about specific management scoping capabilities.

Next steps