你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
多个 Microsoft Entra 租户的场景
组织可能需要或可能需要调查多个Microsoft Entra 租户的原因有很多。 最常见的方案包括：
- 并购
- 法规或国家/地区合规性要求
- 业务部门或组织隔离和自治要求
- 独立软件供应商（ISV）从 Azure 交付 SaaS 应用程序
- 租户级别测试/Microsoft 365 测试
- 基层/影子 IT/初创企业
合并和收购
随着组织随着时间的推移而增长，他们可能会收购其他公司或组织。 这些收购可能已经建立了现有的 Microsoft Entra 租户，为公司或组织托管并提供 Microsoft 365（Exchange Online、SharePoint、OneDrive 或 Teams）、Dynamics 365 和 Microsoft Azure 等服务。
通常，在收购过程中，两个 Microsoft Entra 租户会合并为一个 Microsoft Entra 租户。 这种整合减少了管理开销，提高了协作体验，并向其他公司和组织提供单一品牌标识。
重要
自定义域名（例如，contoso.com）一次只能与一个Microsoft Entra 租户相关联。 因此，合并租户是优先选择，因为在合并或收购的情况下，所有身份都可以使用同一个自定义域名。
由于将两个 Microsoft Entra 租户合并为一个租户的复杂性，有时租户会被单独搁置，长期或无限期地保持分离。
当组织或公司希望保持独立时，也可能发生这种情况，因为其他组织将来可能会收购其公司。 如果组织将 Microsoft Entra 租户隔离，并且不合并这些租户，那么如果将来合并或收购一个单一实体，所需的工作会更少。
法规或国家/地区合规性要求
某些组织具有严格的法规或国家/地区合规性控制和框架（例如，英国官方、萨班斯·奥克斯利（SOX）或 NIST）。 组织可能会创建多个Microsoft Entra 租户以满足并遵守这些框架。
一些组织在全球各地设有办事处和用户，数据驻留规定更为严格，因此也可能创建多个 Microsoft Entra 租户。 但这一特殊要求通常可在单个 Microsoft Entra 租户内使用 Microsoft 365 多地理位置等功能来解决。
另一种情况是组织需要 Azure 政府（美国政府）或 Azure 中国（由世纪互联运营）。 这些国家/地区 Azure 云实例需要自己的 Microsoft Entra 租户。 Microsoft Entra 租户仅适用于该国家/地区 Azure 云实例，并用于该 Azure 云实例中的 Azure 订阅标识和访问管理服务。
如同先前的情境，如果您的组织有一个需要遵守的法规或国家/地区合规性框架，您可能无需将多个 Microsoft Entra 租户视为默认方案。 大多数组织可以通过使用 Privileged Identity Management 和管理单元等功能，在单个 Microsoft Entra 租户内遵守框架。
业务部门或组织隔离和自治要求
某些组织可能具有跨多个业务部门的复杂内部结构，或者可能需要在组织的各个部分之间实现高度隔离和自治。
出现这种情况时，若单个租户中的 资源隔离工具和指南 无法提供所需的隔离级别，您可能需要部署、管理和操作多个 Microsoft Entra 租户。
在这种情况下，更常见的情况是，没有负责部署、管理和操作这些多个租户的集中式函数。 相反，整个业务全部移交给独立的业务部门或组织的一部分，由其负责运行和管理。 集中式体系结构、战略或 CCoE 风格团队仍可就必须在单独的 Microsoft Entra 租户中配置的最佳做法提供指导和建议。
警告
具有运营角色和职责的组织在运营其 Microsoft Entra 租户的团队之间带来了挑战。 Azure 应优先制定并在两个团队之间达成一致的明确责任分配矩阵（RACI）。 此操作可确保两个团队都能工作并向组织提供服务，并及时向业务提供价值。
某些组织具有使用 Azure 的云基础结构和开发团队。 这些组织依靠一个标识团队来控制企业 Microsoft Entra 租户，以创建服务主体或创建和管理组。 如果没有商定的 RACI，团队之间往往缺乏流程和理解，这会导致团队与整个组织之间的摩擦。 一些组织认为，多个Microsoft Entra 租户是克服这一挑战的唯一途径。
但是，多个Microsoft Entra 租户为最终用户带来挑战，增加了保护、管理和管理多个租户的复杂性，并可能会增加许可成本。 许可证（如 Microsoft Entra ID P1 或 P2）不能跨越多个 Microsoft Entra 租户。 有时，Microsoft Entra B2B 的使用可以缓解某些功能和服务的许可重复问题。 如果计划在部署中使用 Microsoft Entra B2B，请查看每项功能和服务的许可条款以及Microsoft Entra B2B 资格的支持性。
在这种情况下，组织应解决运营挑战，以确保团队可以在单个Microsoft Entra 租户中协同工作，而不是创建多个Microsoft Entra 租户作为解决方法。
从 Azure 交付 SaaS 应用程序的独立软件供应商 （ISV）
将 SaaS（软件即服务）产品交付给客户的 ISV 可能受益于拥有多个Microsoft Entra 租户供其 Azure 使用。
如果你是 ISV，你可能会将企业 Microsoft Entra 租户（包括 Azure 使用）与常规业务活动（如电子邮件、文件共享和内部应用程序）分开。 你可能还有一个单独的Microsoft Entra 租户，其中，Azure 订阅托管并提供你向最终用户提供的 SaaS 应用程序。 此方法很常见且合理，因为它可保护你和你的客户免受安全事件。
有关详细信息，请参阅独立软件供应商 (ISV) Azure 登陆区域注意事项。
租户级别测试/Microsoft 365 测试
Microsoft 云产品、服务和方案中的某些活动和功能只能在一个单独的 Microsoft Entra 租户中进行测试。 一些示例包括：
- Microsoft 365 – Exchange Online、SharePoint 和 Teams
- Microsoft Entra ID – Microsoft Entra Connect、Microsoft Entra ID 保护风险级别和 SaaS 应用程序
- 测试使用 Microsoft Graph API 的脚本，这些脚本可以对生产环境产生影响并进行更改
如果要像前面的方案一样执行测试，则单独的 Microsoft Entra 租户是唯一的选择。
但是，单独的 Microsoft Entra 租户并不用来托管包含工作负载的 Azure 订阅，无论环境如何（例如开发/测试）。 即使是开发/测试环境，也应包含在常规的“生产”Microsoft Entra 租户中。
提示
有关如何在 Azure 登陆区域环境中处理测试 Azure 登陆区域和 Azure 工作负荷或资源的信息，请参阅：
草根/ 影子 IT / 初创企业
如果团队希望快速创新，他们可能会创建一个单独的 Microsoft Entra 租户，以尽快推动创新。 他们可能会有意或无意地避免中心/平台团队的过程和指导，以便访问 Azure 环境以执行其创新。
此方案在初创企业中很常见，在这些情况下，他们设置自己的Microsoft Entra 租户，以便从中运行、托管和运营业务和服务。 通常这是可以预料的，但当初创公司被收购时，新增的 Microsoft Entra 租户会产生一个决策点，让收购方组织的 IT 团队决定接下来的行动。
有关如何应对这种情况的更多信息，请参阅本文中的兼并与收购和独立软件供应商 (ISV) 从 Azure 交付 SaaS 应用程序部分。
重要
我们强烈建议平台团队采用一种易于访问且高效的流程，让团队能够访问企业或主 Microsoft Entra 租户中的 Azure 沙盒订阅或订阅。 此过程可防止影子 IT 情况发生，并避免未来各方遇到挑战。
有关沙盒的详细信息，请参阅资源组织设计领域中的管理组指南。
总结
如方案中详述，组织可能需要多个Microsoft Entra 租户的原因有多种。 但是，当你创建多个租户以满足这些方案中的要求时，它会增加复杂性和操作任务来维护多个租户，并可能会增加许可要求的成本。 有关详细信息，请参阅多租户场景中 Azure 登陆区域的注意事项和建议。