Design a multi-tenant architecture for large institutions
A single-tenant architecture is recommended for smaller institutions. However, for organizations that have over 1 million users we recommend a multi-tenant architecture to mitigate performance issues and tenant limitations such as Azure subscription and quotas and Azure AD service limits and restrictions.
When designing your multi-tenant architecture, consider the following design principles to reduce costs and increase efficiency and security:
Reduce reliance on on-premises infrastructure and multiple identity providers.
Enable users to unlock their account or reset passwords using self-service (for example, Azure AD self-service password reset).
Standardize architecture, configurations, and processes across tenants to minimize administrative issues.
Minimize the need for users to move from one tenant to another
Focus on ensuring student data is secure.
Follow the principle of least privilege: grant only those privileges necessary to perform needed tasks and implement Just in Time (JIT) access.
Enable external users access only through Entitlement Management or Azure AD B2B collaboration.
Delegate administration of specific tasks to specific users with Just Enough Access (JEA) to do the job.
Common reasons for multiple tenants
We strongly recommend organizations with fewer than 1 million users create a single tenant unless other criteria indicate a need for multiple tenants. For organizations with 1 million or more user objects, we recommend multiple tenants using a regional approach.
Creating separate tenants has the following effects on your EDU environment.
May limit the impacts of an administrative security or operational error affecting critical resources.
May limit the impact of compromised administrator or user accounts.
Usage reports and audit logs are contained within a tenant.
Student privacy. Student user objects are discoverable only within the tenant the object resides in.
Resource isolation. Resources in a separate tenant can't be discovered or enumerated by users and administrators in other tenants.
Object Footprint. Applications that write to Azure AD and other Microsoft Online services through Microsoft Graph or other management interfaces can affect only resources in the local tenant.
Quotas. Consumption of tenant-wide Azure Quotas and Limits is separated from that of the other tenants.
Provides a separate set of tenant-wide settings that can accommodate resources and trusting applications that have different configuration requirements.
Enables a new set of Microsoft Online services such as Office 365.
In addition to having more than 1 million users, the following considerations may lead to multiple tenants.
You have a compliance or other requirement that requires data to reside in a specific country or region, and all operations cannot be located there.
You operate under regulations that constrain who can administer the environment based on criteria such as country of citizenship, country of residency, or clearance level.
You have compliance requirements such as student data privacy that require you to create identities in specific local regions.
You have resources, perhaps for research and development, that you must shield from discovery, enumeration, or takeover by existing administrators for regulatory or business critical reasons.
Development cycle of custom applications that can change data of users with MS Graph or similar APIs at scale (for example applications that are granted Directory.ReadWrite.All)
- Resources having requirements that conflict with existing tenant-wide security or collaboration postures such as allowed authentication types, device management policies, ability to self-service, or identity proofing for external identities.
Determine multi-tenant approach
In this section we consider a fictional university named School of Fine Arts with 2 million students in 100 schools throughout the United States. Across these schools, there are a total of 130,000 teachers and 30,000 full-time employees and staff.
We recommend a regional approach when deploying multiple tenants as follows:
Begin by dividing your student and educator community by geographical regions where each region contains less than 1 million users.
Create an Azure AD tenant for each region.
Provision staff, teachers, and students in their corresponding region to optimize collaboration experiences.
Why use regions?
A regional approach is recommended to minimize the number of users moving across tenants. If you created a tenant for each school level (for example grade schools, middle schools, and high schools) you would have to migrate users at the end of every school year. If instead users remain in the same region, then you do not have to move them across tenants as their attributes change.
Other benefits of a regional approach include:
Optimal collaboration within each region
Minimal number of guest objects from other tenants are needed
Helps with compliance needs such as data residency
When a tenant has more than 1 million users, management experiences and tools tend to degrade over time. Likewise, some end-user experiences like using the people picker will become cumbersome and unreliable.
Smaller organizations that choose to deploy multiple tenants without a compelling reason will unnecessarily increase their management overhead and the number of user migrations. Doing so will also require steps to ensure collaboration experiences across tenants.
Collaborate across tenants using Azure AD B2B collaboration
Azure AD B2B collaboration enables users to use one set of credentials to sign in to multiple tenants. For educational institutions, the benefits of B2B collaboration include:
Centralized administration team managing multiple tenants
Teacher collaboration across regions
Onboarding parents and guardians with their own credentials
External partnerships like contractors, or researchers
With B2B collaboration, a user account created in one tenant (their home tenant) is invited as a guest user to another tenant (a resource tenant) and the user can sign in using the credentials from their home tenant. Administrators can also use B2B collaboration to enable external users to sign in with their existing social or enterprise accounts by setting up federation with identity providers such as Facebook, Microsoft accounts, Google, or an enterprise identity provider.
Members and guests
Users in an Azure AD tenant are either members or guests based on their UserType property. By default, member users are those that are native to the tenant. An Azure AD B2B collaboration user is added as a user with UserType = Guest by default. Guests have limited permissions in the directory and applications. For example, guest users can't browse information from the tenant beyond their own profile information. However, a guest user can retrieve information about another user by providing the User Principal Name (UPN) or objectId. A guest user can also read properties of groups they belong to, including group membership, regardless of the Guest users permissions are limited setting.
In some cases, a resource tenant might want to treat users from the home tenant as members instead of guests. if so, you can use the Azure AD B2B Invitation Manager APIs to add or invite a user from the home tenant to the resource tenant as a member. For more information, see Properties of an Azure Active Directory B2B collaboration user.
Centralized administration of multiple tenants
Onboard external identities using Azure AD B2B. External identities can then be assigned privileged roles to manage Azure AD tenants as members of a centralized IT team. You can also use Azure AD B2B to create guest accounts for other staff members such as administrators at the regional or district level.
However, roles that are service-specific such as Exchange Administrator or SharePoint Administrator require a local account that is native to their tenant.
The following roles can be assigned to B2B accounts
B2C IEF Keyset Administrator
B2C IEF Policy Administrator
Cloud Application B2C IEF Policy Administrator
Cloud Device B2C IEF Policy Administrator
Conditional Access Administrator
Directory Synchronization Accounts
External ID User Flow Administrator
External ID User Flow Attribute Administrator
External Identity Provider
Hybrid Identity Administrator
Intune Service Administrator
Privileged Authentication Administrator
Privileged Role Administrator
Restricted Guest User
User Account Administrator
Workplace Device Join
Custom administrator roles in Azure AD surface the underlying permissions of the built-in roles, so that you can create and organize your own custom roles. This approach allows you to grant access in a more granular way than built-in roles, whenever they're needed.
Here is an example illustrating how administration would work for administrative roles that can be delegated and used across multiple tenants.
Susie’s native account is in the Region 1 tenant, and Azure AD B2B is used to add the account as an Authentication Administrator to the central IT team in the tenants for Region 2 and Region 3.
Using apps across multiple tenants
To mitigate issues associated with the administration of apps in a multi-tenant environment, you should consider writing multi-tenant apps. You'll also need to verify which of your SaaS apps support multiple IdP connections. SaaS apps that support multiple IDP connections should configure individual connections on each tenant. SaaS apps that don't support multiple IDP connections might require independent instances. For more information, see How to: Sign in any Azure Active Directory user using the multi-tenant application pattern.
Note: Licensing models may vary from one SaaS app to another. check with the vendor to determine if multiple subscriptions will be required in a multi-tenant environment.
Per-tenant administration is required for roles that are service-specific. Roles that are service-specific require having a local account that is native to the tenant. in addition to having a centralized IT team in each tenant, you will also need to have a regional IT team in each tenant to manage workloads such as Exchange, SharePoint, and Teams.
The following roles require accounts native to each tenant
Azure DevOps Administrator
Azure Information Protection Administrator
CRM Service Administrator
Compliance Data Administrator
Customer LockBox Access Approver
Desktop Analytics Administrator
Insights Business Leader
Lync Service Administrator
Message Center Privacy Reader
Message Center Reader
Service Support Administrator
Teams Communications Administrator
Teams Communications Support Engineer
Teams Communications Support Specialist
Teams Service Administrator
Unique admins in each tenant
If you have an IT team native to each region, you could have one of those local administrators manage the Teams administration. In the following example, Charles resides in Region 1 tenant and has the role of Teams Service Administrator. Alice and Ichiro reside in regions 2 and 3 respectively, and hold the same role in their regions. Each local administrator has a single account native to their region.
Admin roles across tenants
If you do not have a pool of admins local to each region, you might assign the Teams Service Administrator role to just one user. In this scenario, as illustrated below, you can have Bob from the Central IT Team act as Teams Service Administrator in all three tenants by creating a local account for Bob in each tenant.
Delegation of admin roles within a tenant
Administrative units (AUs) should be used to logically group Azure AD users and groups. Restricting administrative scope using administrative units is useful in educational organizations that are made up of different regions, districts, or schools.
For example, our fictional School of Fine Arts is spread across three regions, each containing multiple schools. Each region has a team of IT admins who control access, manage users, and sets policies for their respective schools.
For example, an IT administrator could:
Create an AU for users each of the schools in Region 1, to manage all users in that school. (not pictured)
Create an AU that contains the teachers in each school, to manage teacher accounts.
Create a separate AU that contains the students in each school, to manage student accounts.
Assign teachers in the school the Password Administrator role for the Students AU, so that teachers can reset student passwords, but not reset other users’ passwords.
Roles that can be scoped to administrative units include:
For more information, see Assign scoped roles to an administrative unit.
Settings are configured in each tenant individually. Configure then as part of the tenant creation where possible to help minimize having to revisit those settings. While some common tasks can be automated, there is no built-in cross-tenant management portal.
Managing objects at scale
Microsoft Graph (MS Graph) and Azure AD PowerShell let you manage directory objects at scale. They can also be used to manage most policies and settings in your tenant. However, you should understand the following performance considerations:
MS Graph limits the creation of users, groups, and membership changes to 72,000 per tenant, per hour.
MS Graph performance may be impacted by user driven actions such as read or write actions within the tenant
MS Graph performance may be impacted by other competing IT admin tasks within the tenant
PowerShell, SDS, Azure AD Connect, and custom provisioning solutions add objects and memberships via MS Graph at different rates
If you haven't reviewed Introduction to Azure Active Directory tenants, you may want to do so. then see: