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 方案的合并选项
以下部分涵盖假设 M&A 方案的四个主要方案：
假设 Contoso 是一个企业客户，其 IT 部门具有单个（本地）HR 系统、单个 Active Directory 林、适用于其应用的单个租户 Microsoft Entra ID，并正常运行。 用户从 HR 系统进入 Active Directory，并被引入 Microsoft Entra ID，然后再从此处进入 SaaS 应用。 下图演示了此方案，其中箭头显示了标识信息流。 同一模型也适用于使用云 HR 系统（例如预配 Active Directory 的 Workday 或 SuccessFactors）的客户，而不只是使用 Microsoft Identity Manager (MIM) 的客户。
接下来，Contoso 已开始与 Litware 合并，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 林，但不使用其 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 Connect 将他们的 Active Directory 连接到单个租户 | B5：Microsoft Entra Connect 云同步其 Active Directory | C6：将多个租户并行预配到应用中 | C7：从租户读取内容，并通过 B2B 邀请其用户 | C8：根据需要使用单个 IAM 和 B2B 用户 | D9：通过其非 Azure AD IDP 使用 DF |
|---|---|---|---|---|---|---|---|---|---|
| 迁移工作 | 高 | 中等工作量 | 工作量较低 | 低工作量 | 低工作量 | 无 | None | None | 无 |
| 部署工作量 | 工作量较少 | 中等工作量 | 中等工作量 | 中等工作量 | 低 | 低 | 高 | 高 | 很高 |
| 迁移期间对最终用户的影响 | 高 | 高 | 中 | 中 | 中等 | 无 | None | None | 无 |
| 运营工作量 | 低成本 | 低成本 | 低成本 | 低成本 | 低成本 | 高 | 高 | 高 | 很高 |
| 隐私和数据功能（地理位置/数据边界） | 无（地理位置的主要障碍） | 即使耗费精力也只能达到有限的隔离 | 本地环境的有限隔离，但不是云上的隔离 | 本地环境的有限隔离，但不是云上的隔离 | 本地环境的有限隔离，但不是云上的隔离 | 在本地和云上进行良好隔离 | 在本地和云上的有限隔离 | 在本地和云上的有限隔离 | 在本地和云上进行隔离 |
| 隔离（单独的委派并设置不同的管理模型）备注：如源系统 (HR) 中定义的那样 | 不可用 | 可能 | 可能 | 可能 | 可能 | 可能性很高 | 可能性很高 | 可能性很高 | 可能 |
| 协作能力 | 很好 | 很好 | 很好 | 很好 | 很好 | 差 | 平均值 | 平均值 | 差 |
| 支持的 IT 管理模型（集中式和分散式） | 集中式 | 集中式 | 集中式 | 集中式 | 集中式 | 分散式 | 分散式 | 分散式 | 主动分散式 |
| 限制 | 无隔离 | 有限隔离 | 有限隔离 | 有限隔离 | 有限隔离。 无写回功能 | 不适用于 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 系统
有时聚合 HR 系统可能是不可行的，至少无法在短期内实现的。 相反，客户将连接其预配系统（例如 MIM）以读取两个 HR 系统中的内容。 在此图中，上面的 HR 是现有的 Contoso 环境，而第二个 HR 是 Litware 对整体基础结构的补充。
使用 Microsoft Entra Workday 或 SuccessFactors 入站也可以实现相同的方案，Contoso 可以将 Litware 的 Workday HR 源中引入用户，同时引入现有的 Contoso 员工。
合并所有标识基础结构的结果
- 缩减 IT 基础结构，只需管理一个标识系统，无需网络连接要求，只需要一个 HR 系统。
- 一致的最终用户和管理体验
合并所有标识基础结构的约束
- 如果有 Contoso 员工所需的数据来自 Litware，则必须将该数据迁移至 Contoso 环境。
- 如果有 Contoso 需要的 Active Directory 或 Microsoft Entra 集成应用来自 Litware，则必须将其重新配置到 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 Online Services 投资，其中包括多个 Office 365 租户，这些租户在迁移到另一个租户时会消耗高额的成本或时间。
- Litware 未来可能会被剥离出去，或者可能成为独立运营的合作伙伴。
- Litware 没有本地基础结构
选项 6 - 维护每个 Microsoft Entra ID 中的应用的并行预配和 SSO
一种选择是：为每个 Microsoft Entra ID 独立提供 SSO，并将其目录中的用户预配至目标应用。 例如，如果 Contoso IT 使用的是 Salesforce 这样的应用，则他们将为 Litware 提供管理权限，以在同一 Salesforce 订阅中创建用户。
并行预配的结果
- 用户可以使用其现有标识对应用进行身份验证，而无需更改 Contoso 的基础结构。
并行预配的约束
- 如果采用联合，则需要应用程序支持同一订阅的多个联合提供者。
- 对 Office 或 Azure 这样的 Microsoft 应用不可行
- Contoso 在 Microsoft Entra ID 中无法查看 Litware 的应用程序访问权限
选项 7 - 为获取的租户中的用户配置 B2B 帐户
如果 Litware 已在运行其自己的租户，则 Contoso 可以从该租户中读取用户，并通过 B2B API 将每个用户邀请到 Contoso 租户中。 （例如，可以通过 MIM graph 连接器完成这样的批量邀请过程。）如果 Contoso 还希望 Litware 用户可以使用基于 AD 的应用，则 MIM 还可以在 Active Directory 中创建映射到 Microsoft Entra 用户的 UPN 的用户，以便应用代理可以代表 Contoso 的 Active Directory 中的 Litware 用户执行 KCD。
随后，当 Litware 员工要访问 Contoso 应用时，可以通过对资源租户的访问分配对自己的目录进行身份验证，从而实现此目的。
为其他租户中的用户设置 B2B 帐户的结果
- Litware 用户可以对 Contoso 应用进行身份验证，且 Contoso 控制其租户中的访问权限。
为其他租户中的用户设置 B2B 帐户的约束
- 需要访问 Contoso 资源的每个 Litware 用户都必须使用一个复制帐户。
- 要求应用在 SSO 方面能使用 B2B。
选项 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 域之间建立连接。
- 要求应用在 SSO 方面能使用 B2B。
方案 D - 假设 Litware 正在使用非 Active Directory 基础结构
最后，如果 Litware 使用其他目录服务（无论是在本地还是在云中），Contoso IT 仍然可以配置 Litware 员工身份验证，他们也可以使用其现有标识访问 Contoso 的资源。
选项 9 - 使用 B2B 直接联合（公共预览版）
在该场景下，假定 Litware 具有：
- 一些现有目录，例如 OpenLDAP，甚至用户的 SQL 数据库或平面文件（具有用户可与 Contoso 定期共享的电子邮件地址）。
- 支持 SAML 的标识提供程序，例如 PingFederate 或 OKTA。
- 公共路由的 DNS 域（如 Litware.com）和具有该域中的电子邮件地址的用户
在此方法中，Contoso 会配置从域的租户到 Litware 的标识提供者的直接联合关系，然后定期从 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。