Microsoft提供一系列技术和解决方案，用于在其标识基础结构的不同本地和云组件之间进行集成。 通常，客户不清楚哪些技术最正确，并可能错误地认为“最新版本涵盖早期技术版本的所有方案”。
本文介绍当公司经历下面概述的复杂方案并想要合并标识信息时的方案。 理想情况下，具有单个 HR 源、单个 Active Directory 林和单个 Microsoft Entra 租户的组织（每个租户都与同一人员集成）将为Microsoft Online Services 提供最佳标识体验。 但是，在实践中，企业客户可能并不总是处于可能的情况下。 例如，客户可能正在进行合并，或者需要对某些用户或应用程序进行隔离。 拥有多个 HR、多个 AD 或多个 Microsoft Entra 租户的客户必须决定是将这些合并为更少的实例，还是维持它们并行存在。
根据我们的客户反馈，以下是一些常见的方案和要求。
多云和多组织标识出现的场景
- 合并和收购 （M&A） - 是指通常公司 A 购买 B 公司的情况。
- 重塑品牌 - 公司名称或品牌更改，通常电子邮件域名更改。
- Microsoft Entra ID 或 Office 365 租户合并 - 由于合规性或历史要求，具有多个 Office 365 租户的公司可能需要合并。
- Active Directory 域或林合并 - 计划进行 Active Directory 域或林合并的公司正在进行评估。
- 剥离 - 公司部门或业务组出售或独立。
- 用户信息隐私 - 公司要求使某些数据（属性）不被公开显示，并且只有适当的委派组或用户可以读取、更改和更新它。
产生于这些情形的要求
- 通过创建中央目录或 通用目录，将所有用户和组的数据引入单个位置，包括会议安排的电子邮件和状态可用性。
- 通过实现单一登录，维护 单个用户名和密码 ，同时减少在所有应用程序中输入用户名和密码的需求。
- 简化用户上手，使其无需耗费数周或数月。
- 为组织做好准备，以应对未来的收购和访问管理需求。
- 启用和提高跨公司协作和工作效率。
- 使用集中且一致地部署的安全策略减少安全漏洞或数据外泄的可能性！
本文未介绍的方案
- 部分并购。 例如，组织购买另一个组织的一部分。
- 分离或拆分组织
- 重命名组织。
- 合资企业或临时合作伙伴
本文概述了各种多云或多组织标识环境，包括目前Microsoft支持的 M&A 方案，并概述组织如何根据组织如何进行合并来选择正确的技术。
假设并购情景的合并选项
以下部分介绍假设的 M&A 方案的四个主要方案：
假设 Contoso 公司是一个企业客户，其 IT 部门拥有单个（本地）HR 系统、单个 Active Directory 林，以及单个用于其应用的 Microsoft Entra ID 租户，一切运行如预期。 用户会从 HR 系统导入到 Active Directory，然后投影到 Microsoft Entra ID，最后从那里流向 SaaS 应用。 下图演示了此方案，其中箭头显示了标识信息流。 同一模型也适用于云 HR 系统预配 Active Directory 的客户，而不仅仅是使用 Microsoft Identity Manager（MIM）的客户。
接下来，Contoso 已开始与 Litware 合并，后者以前独立运行自己的 IT。 Contoso IT 将处理合并，并预计 Contoso 的 IT 部门将继续让 Contoso 的应用保持不变，但他们希望能够让 Litware 的用户获得对这些应用的访问权限并在这些应用中进行协作。 对于Microsoft应用、第三方 SaaS 和自定义应用，最终状态应该是 Contoso 和 Litware 用户从概念上有权访问同一数据。
第一个 IT 决策是他们希望合并基础结构多少。 他们可以选择不依赖于任何 Litware 的标识基础结构。 他们可以考虑使用 Litware 的基础结构，并在逐步整合的过程中尽量减少对 Litware 环境的中断。 在某些情况下，客户可能希望使 Litware 的现有标识基础结构保持独立，并且不聚合它，同时仍使用它来授予 Litware 员工对 Contoso 应用的访问权限。
如果客户选择保留 Litware 的部分或全部标识基础架构，那么在多大程度上使用 Litware 的 Active Directory 域服务或 Microsoft Entra ID 来为 Litware 用户提供对 Contoso 资源的访问将存在权衡。 本部分基于 Contoso 为 Litware 用户提供的解决方案，探讨可行的选项：
- 方案 A - 不使用 任何 Litware 的标识基础结构。
- 方案 B - 使用 Litware 的 Active Directory 林，但不使用 Litware 的 Microsoft Entra ID（如果存在）
- 方案 C - 使用 Litware 的 Microsoft Entra ID。
- 方案 D - 使用 Litware 的非Microsoft标识基础结构（如果 Litware 未使用 Active Directory/Microsoft Entra ID）
下表总结了每个选项，其中包含客户如何实现这些结果、约束和优势的技术。
| 注意事项 | A1：单个 HR、单个 IAM、单个租户 | A2：独立的 HR、单一的 IAM 和租户 | B3：Active Directory 林信任、单个Microsoft Entra Connect | B4：Microsoft Entra 将其 Active Directory 与单个租户连接 | B5：Microsoft Entra Connect 云同步其 Active Directory | C6：将多个租户并行预配到应用中 | C7：从租户读取数据，B2B 邀请其用户加入 | C8：根据需要使用单个 IAM 和 B2B 用户 | D9：DF 及其非 Azure AD IDP |
|---|---|---|---|---|---|---|---|---|---|
| 迁移工作 | 高 | 中等工作量 | 降低工作量 | 低工作量 | 低工作量 | 没有 | 没有 | 没有 | 没有 |
| 部署工作 | 减少工作量 | 中等工作量 | 中等工作量 | 中等工作量 | 低 | 低 | 高 | 高 | 非常高 |
| 迁移期间的最终用户影响 | 高 | 高 | 中等 | 中等 | 中等 | 没有 | 没有 | 没有 | 没有 |
| 操作力度 | 低成本 | 低成本 | 低成本 | 低成本 | 低成本 | 高 | 高 | 高 | 非常高 |
| 隐私和数据功能（地理位置/数据边界） | 没有（地理位置方案的主要障碍） | 尽管具有挑战性，但隔离有限 | 本地隔离有限，但云端没有这种限制 | 本地隔离有限，但云端没有这种限制 | 本地隔离有限，但云端没有这种限制 | 本地环境和云中环境的隔离性良好 | 本地和云上的有限隔离 | 本地和云上的有限隔离 | 在本地和云上隔离 |
| 隔离（单独的委派和设置不同的管理员模型）注意：在源系统（HR） 中定义 | 不可能 | 可能 | 可能 | 可能 | 可能 | 高度可能 | 高度可能 | 高度可能 | 可能 |
| 协作功能 | 优秀 | 优秀 | 优秀 | 优秀 | 优秀 | 差 | 平均值 | 平均值 | 差 |
| 支持的 IT 管理员模型（集中式模型与分离模型） | 集中式 | 集中式 | 集中式 | 集中式 | 集中式 | Decentralized | Decentralized | Decentralized | 主动去中心化 |
| 局限性 | 无隔离 | 有限隔离 | 有限隔离 | 有限隔离 | 限制的隔离。 无写回功能 | 不适用于 Microsoft Online Services 应用。 高度依赖于应用功能 | 要求应用具备 B2B 功能或意识 | 要求应用具备 B2B 功能或意识 | 要求应用具备 B2B 意识。 整体协作方式的不确定性 |
表详细信息
- 员工努力尝试预测在组织中实现解决方案所需的专业知识和额外工作。
- 运营工作会尝试预测使解决方案保持运行所花费的成本和工作量。
- 隐私和数据功能显示解决方案是否允许支持地理位置和数据边界。
- 隔离体现此解决方案是否具备分离或委托管理模型的能力。
- 协作功能显示解决方案支持的协作级别，更集成的解决方案提供更高的团队合作保真度。
- IT 管理员模型显示管理员模型是否需要集中管理或可以分散。
- 限制：值得列出的任何挑战或问题。
决策树
使用以下决策树帮助你确定哪种方案最适合你的组织。
本文档的其余部分将概述 A-D 的四种方案，其中包含支持它们的各种选项。
方案 A - 如果 Contoso 不希望依赖 Litware 的现有标识基础结构
对于此选项，Litware 可能没有任何标识系统（例如小型企业），或者客户可能希望关闭 Litware 的基础结构。 或者，他们希望将其保留不变，供 Litware 员工用来向 Litware 的应用进行身份验证，但为 Litware 员工在 Contoso 内创建新的身份。 例如，如果 Alice Smith 是 Litware 员工，她可能具有两个身份， Alice@litware.com 并且 ASmith123@contoso.com。 这些身份彼此完全不同。
选项 1 - 合并为单个 HR 系统
通常，客户会将 Litware 员工引入 Contoso HR 系统。 此选项将触发这些员工接收帐户和对 Contoso 目录和应用的正确访问权限。 然后，Litware 用户将拥有一个新的 Contoso 标识，他们可以使用该标识来请求对正确的 Contoso 应用的访问权限。
选项 2 - 保留 Litware HR 系统
有时在短期内可能无法整合人力资源系统，至少在短期内是不可能的。 相反，客户将把他们的预配系统（例如 MIM）连接起来，以便从这两个 HR 系统读取。 在此图中，顶部 HR 是现有的 Contoso 环境，第二个 HR 是 Litware 添加到整体基础设施的。
合并所有标识基础结构的结果
- 减少 IT 基础结构，只管理一个标识系统，除了 HR 系统之外，没有网络连接要求。
- 一致的最终用户和管理体验
合并所有身份基础设施的限制
- 源自 Litware 的 Contoso 员工所需的任何数据都必须迁移到 Contoso 环境。
- 必须将任何来自 Litware 并需为 Contoso 环境使用的 Active Directory 或 Microsoft Entra 集成应用重新配置至 Contoso 环境。 此重新配置可能需要更改配置、用于访问的组或应用本身。
方案 B - 如果 Contoso 希望保留 Litware 的 Active Directory 林，但不使用 Litware 的 Microsoft Entra ID
Litware 可能有许多基于 Active Directory 的现有应用，因此 Contoso 可能希望继续让 Litware 员工在其现有 AD 中保留自己的标识。 然后，Litware 员工将利用其现有身份来认证他们已有的资源并对 Contoso 资源进行认证。 在此方案中，Litware 在 Microsoft Online Services 中没有任何云标识 - Litware 不是 Microsoft Entra 客户，Litware 的云资产都不会与 Contoso 共享，或者 Contoso 将 Litware 的云资产迁移到 Contoso 租户的一部分。
选项 3 - 与已收购的森林建立林地信任关系
使用 Active Directory 林信任，Contoso 和 Litware 可以连接其 Active Directory 域。 此信任使 Litware 用户能够对 Contoso 的 Active Directory 集成应用进行身份验证。 此外 Microsoft Entra Connect 还可以从 Litware 的 Active Directory 林中读取数据，以便 Litware 用户能够使用 Contoso 的 Microsoft Entra 集成应用进行身份验证。 此部署拓扑需要在两个域之间设置网络路由，以及任何 Litware 用户与 Contoso Active Directory 集成应用之间的 TCP/IP 网络连接。 设置双向信任也非常简单，以便 Contoso 用户可以访问 Litware AD 集成应用（如果有）。
建立森林信托的结果
- 所有 Litware 员工都可以对 Contoso 的 Active Directory 或 Microsoft Entra 集成应用进行身份验证，Contoso 可以使用基于 AD 的当前工具来管理授权。
设置森林信任关系的约束
- 需要域加入到一个林的用户与已加入另一个林的资源之间建立 TCP/IP 连接。
- 要求 Contoso 林中基于 Active Directory 的应用能够支持和操作多个林
选项 4 - 将 Microsoft Entra Connect 配置到无需林信任的已获取林
客户还可以将 Microsoft Entra Connect 配置为从另一个林读取。 此配置使 Litware 用户能够向 Contoso 的 Microsoft Entra 集成应用进行身份验证，但不向 Litware 用户提供对 Contoso 的 Active Directory 集成应用的访问权限 - 这些 Contoso 应用无法识别 Litware 用户。 此部署拓扑需要在 Microsoft Entra Connect 和 Litware 的域控制器之间建立 TCP/IP 网络连接。 例如，如果 Microsoft Entra Connect 位于 Contoso IaaS VM 上，则还需要建立指向 Litware 网络的隧道。
使用 Microsoft Entra Connect 预配一个租户的结果
- 所有 Litware 员工都可以对 Contoso 的 Microsoft Entra 集成应用进行身份验证。
使用 Microsoft Entra Connect 预配一个租户的约束
- 需要 Contoso 的 Microsoft Entra Connect 和 Litware Active Directory 域之间的 TCP/IP 连接。
- 不允许 Litware 用户有权访问基于 Contoso 的 Active Directory 应用程序
选项 5 - 在获取的林中部署 Microsoft Entra Connect 云同步
Microsoft Entra Connect 云预配 消除了网络连接的要求，但对于具有云同步的给定用户，只能有一个 Active Directory 链接到 Microsoft Entra ID。Litware 用户可以对 Contoso 的 Microsoft Entra 集成应用进行身份验证，但不能对 Contoso 的 Active Directory 集成应用进行身份验证。 此拓扑不需要在 Litware 与 Contoso 的本地环境之间建立任何 TCP/IP 连接。
在获取的林中部署 Microsoft Entra Connect 云同步的结果
- 所有 Litware 员工都可以对 Contoso 的 Microsoft Entra 集成应用进行身份验证。
在新获取的林中使用 Microsoft Entra Connect 云同步的限制
- 不允许 Litware 用户访问 Contoso 的 AD 应用程序
方案 C - 如果 Contoso 想要保留 Litware 的 Microsoft Entra ID
Litware 可能是 Microsoft Online Services 或 Azure 的客户，或者可能依赖一个或多个基于 Microsoft Entra ID 的应用程序。 因此，Contoso 可能希望让 Litware 员工保留自己的标识，以便访问这些资源。 然后，Litware 员工将利用其现有身份来认证他们已有的资源并对 Contoso 资源进行认证。
此方案适用于以下情况：
- Litware 对 Azure 和 Microsoft 联机服务进行了广泛的投资，包括多个 Office 365 租户，迁移这些租户到另一个租户将会非常昂贵或耗时。
- Litware 可能在将来被拆出，或者是一种独立运行的合作关系。
- Litware 没有本地基础结构
选项 6 - 为每个Microsoft Entra ID 中的应用维护并行预配和 SSO
一个选项是让每个 Microsoft Entra ID 独立提供 SSO，并将用户从其目录 预配 到目标应用中。 例如，如果 Contoso IT 使用 Salesforce 等应用，他们将向 Litware 提供管理权限，以在同一 Salesforce 订阅中创建用户。
并行预配的结果
- 用户可以使用其现有标识对应用进行身份验证，而无需更改 Contoso 的基础结构。
并行预配的约束
- 如果使用联合身份验证，应用程序需要支持同一订阅的多个联合身份验证提供程序。
- 无法用于 Microsoft Office 或 Azure 等应用程序
- Contoso 在其 Microsoft Entra ID 中无法看到 Litware 用户的应用程序访问情况。
选项 7 - 为已获取的租户中的用户配置 B2B 帐户
如果 Litware 已运行自己的租户，则 Contoso 可以从该租户读取用户，并通过 B2B API 邀请其中每个用户加入 Contoso 租户。 （例如，可以通过 MIM 图形连接器完成此批量邀请过程。如果 Contoso 还具有他们希望提供给 Litware 用户的基于 AD 的应用，则 MIM 还可以在 Active Directory 中创建用户，以便映射到 Microsoft Entra 用户的 UPN，以便应用代理可以代表 Contoso Active Directory 中 Litware 用户的表示形式执行 KCD。
然后，当 Litware 员工希望访问 Contoso 应用时，他们可以通过在自己的目录中进行身份验证，然后访问资源租户。
为来自其他租户的用户设置 B2B 帐户的结果
- Litware 用户可以对 Contoso 应用进行身份验证，并且 Contoso 在其租户中控制该访问权限。
为来自其他租户的用户设置 B2B 帐户的约束
- 需要为每个需要访问 Contoso 资源的 Litware 用户创建一个重复帐户。
- 要求应用支持 B2B 功能以进行 SSO。
选项 8 - 配置 B2B，但两个目录共享同一 HR 源
在某些情况下，收购后，组织可能会聚合在单个 HR 平台上，但仍运行现有的标识管理系统。 在此方案中，MIM 可以将用户预配到多个 Active Directory 系统中，具体取决于用户所属的组织哪个部分。 他们可以继续使用 B2B，以便用户对其现有目录进行身份验证，并拥有统一的全局地址列表（GAL）。
从共享 HR 系统数据源设置 B2B 来宾用户的结果
- Litware 用户可以向 Contoso 应用进行身份验证，Contoso 控制其租户中的访问权限。
- Litware 和 Contoso 具有统一的 GAL。
- 对 Litware 的 Active Directory 或 Microsoft Entra ID 没有更改
设置来自通用 HR 系统数据源的 B2B 来宾用户的限制条件
- 需要更改 Contoso 的预配，以将用户发送到 Litware 的 Active Directory，并实现 Litware 域与 Contoso 域之间的连接。
- 要求应用支持 B2B 功能以进行 SSO。
方案 D - 如果 Litware 正在使用非 Active Directory 基础结构
最后，如果 Litware 使用的是另一个目录服务（本地或云中），Contoso IT 仍可以配置 Litware 员工进行身份验证，并且可以使用其现有标识访问 Contoso 的资源。
选项 9 - 使用 B2B 直接联盟（公测版）
在此方案中，假定 Litware 具有：
- 某些现有目录，例如 OpenLDAP、甚至是 SQL 数据库或包含用户及其电子邮件地址的简单文件，可以定期与 Contoso 共享。
- 支持 SAML 的标识提供者，例如 PingFederate 或 OKTA。
- 一个如 Litware.com 的公开路由 DNS 域和在该域内拥有电子邮件地址的用户
在此方法中，Contoso 将为该域配置从其租户到 Litware 标识提供者的 直接联合 关系，然后定期从其目录中读取对 Litware 用户的更新，以邀请 Litware 用户加入 Contoso 的 Microsoft Entra ID。 可以使用 MIM Graph 连接器完成此更新。 如果 Contoso 也有希望向 Litware 用户提供的基于 Active Directory 的应用程序，那么 MIM 可以在 Active Directory 中创建与 Microsoft Entra 用户的 UPN 映射的用户，以便应用程序代理能够在 Contoso 的 Active Directory 中代表 Litware 用户的身份进行 KCD 身份验证。
使用 B2B 直接对接的结果
- Litware 用户使用其现有标识提供者对 Contoso 的 Microsoft Entra ID 进行身份验证，并访问 Contoso 的云和本地 Web 应用，
使用 B2B 直接联盟的约束
- 要求 Contoso 应用能够支持 B2B 用户 SSO。