Office 365环境中目录同步的特殊字符|第 1#2 条 |第 11 部分#23

在当前文章和下一篇文章中，我们将回顾基于 Office 365 的环境中目录同步过程的主要特征。我添加两篇专门文章或这个主题的原因是，因为了解“目录同步背后发生的事情”目录同步的“场景”非常关键：

1. 我们对目录同步环境中需要遵循的 Exchange Online 邮箱还原过程“逻辑”的理解。
2. 我们有能力成功处理 Exchange Online 邮箱还原过程以不适当的方式实施的情况，在这种情况下，我们需要知道如何修复邮箱还原邮箱错误。

为什么我们需要了解 Office 365 中目录同步环境的幕后花絮？

这个问题的另一个措辞可能是——为什么我需要阅读有关目录同步和 Office 365 的无聊技术信息？

目录同步环境可以被视为一个复杂的环境，它定义了两个 Active Directory 基础结构的逻辑“绑定”，并且大多数情况下定义了两个独立的 Exchange 基础结构（Exchange 本地 + Exchange Online 在 Exchange 混合环境中）。

为了能够成功处理 Exchange Online 邮箱还原场景，我们需要熟悉目录同步环境的所有组件，并了解这些“组件”如何相互交互。

为了能够了解“大局”，我们需要熟悉目录同步环境中 Office 365 的不同“层”。

第 1 层 - 了解使用目录同步和 Office 365 的逻辑和概念。

在这一层中，我们需要目录同步如何将本地 Active Directory 与 Office 365 目录（Azure Active Directory）“绑定”。

目录同步过程使用以下概念“绑定”两个不同的目录：ImmutableID、软匹配和硬匹配。

第 2 层 - 了解 Active Directory 用户与其 Office 365 用户帐户“副本”之间存在的逻辑和关系概念。

在这一层中，我们需要理解诸如“权限来源”之类的概念，它描述了一个模型，其中本地 Active Directory 是创建和管理对象的“源”。

Office 365 目录充当“副本”，其中包含本地 Active Directory 对象（例如用户帐户、组帐户等）的副本。

换句话说，本地 Active Directory 对 Directory 对象具有读取和写入访问权限，而 Office 365 Directory (Azure Active Directory) 仅对从 Azure Active Directory 复制的对象具有读取访问权限。

第 3 层 - 了解在目录同步中创建新 Active Directory 用户和删除 Active Directory 用户的“流程逻辑”

由于 Office 365 Directory (Azure Active Directory) 被视为本地 Active Directory 的“从属”，因此每个事件（例如创建新的 Active Directory 用户帐户或删除本地 Active Directory 用户帐户）都会导致影响本地 Active Directory 的“波纹”。 Office 365 目录。

第 4 层 - 了解强制需要恢复本地 Active Directory 用户帐户的逻辑，以防我们需要恢复已删除的 Exchange Online 邮箱。

当我们需要在目录同步环境中恢复 Exchange Online 邮箱时，大多数情况下，“Exchange Online 邮箱删除”的原因是删除了本地 Active Directory 用户帐户。

恢复 Exchange Online 邮箱的“正确方法”是恢复已删除的本地 Active Directory 用户帐户。

第 5 层 - 了解 Exchange Online 邮箱恢复错误的根源

如前所述，目录同步环境可以被视为复杂的基础设施。
由于这种“复杂性”，最常见的情况之一是已删除的 Exchange Online 邮箱的还原实施不当的情况。在这一层，我们需要了解这种不当更改在线恢复邮箱场景的情况。

第 6 层 - 了解可用于处理和修复 Exchange Online 邮箱恢复错误的方法。

仅仅知道邮箱恢复错误的原因是不够的。

在这一层中，我们需要熟悉可用于修复不正确的邮箱还原的方法和选项。

本地 Active Directory 用户与其 Office 365“用户副本”之间的关系

目录同步环境简单的含义就是包含多个目录的环境。

目录同步基础设施正在处理“目录”之间的关系，顾名思义，其一般目的是 - 实现一种同步机制，该机制将在两个（或多个）不同目录之间进行关联。

例如，当目录A发生“事情”时，将信息同步到目录B。

因为在目录同步中，涉及到两个或多个目录，最基本的配置设置之一，关系到要实现的“同步模型”。

1．等量或双向同步模型

如果在目录 A 中创建了 NEW 对象，则信息将同步到目录 B，因此，目录 B 中也会创建 NEW 对象。

同样的逻辑以相反的方向实现——当在目录B中创建一个NEW对象时，信息将与目录A同步，因此，目录A中也会创建一个NEW对象。

2.“非相等”或单向同步模型

这种类型的同步模型，定义了一种“非平等”的关系模型。在此模型中，一个目录被视为“权限来源”，另一个目录被视为“权限来源目录”的“下级”。 ”

例如 - 如果在目录 A 中创建了一个 NEW 对象，则信息将同步到目录 B，因此，目录 B 中也会创建一个 NEW 对象。

同样的概念在相反的方向未实现，因为在这种情况下，目录 B 充当目录 A 的“副本”。

在目录 B 中添加新用户帐户等更新不会复制（同步）到目录 A。

在这种类型的模型中，大多数时候，我们不应该在目录B中创建任何更新，而是在目录A中创建所有需要的更新，并且有关更新的信息将同步到目录B 。

基于 Office 365 的环境中的目录同步基础架构

在基于 Office 365 的环境中实现的目录同步模型被描述为“非相等”或单向同步模型。

Office 365中的目录同步通过以下方式实现；本地 Active Directory 被视为“权威目录源”。

对象的管理（例如创建新用户帐户或更新现有用户帐户的信息）应仅在本地 Active Directory 中创建。

目录同步服务器 (Azure AD Connect) 是一个软件组件，负责从本地 Active Directory 中“获取”信息，并将信息同步到 Office 365 目录（即 Azure Active Directory）。

为了能够处理在基于目录同步的环境中恢复 Exchange Online 邮箱的情况，或者“修复”目录同步环境中的 Exchange Online 邮箱恢复恢复错误，我们需要熟悉以下主题：

1. 本地 Active Directory 用户对象如何“绑定”到目录同步环境中的 Office 365 用户对象。
2. 当我们创建新的本地 Active Directory 用户帐户时，触发的事件链是什么？
3. 当我们删除本地 Active Directory 用户帐户时，会触发哪些事件链？

目录同步环境中的组件

在下图中，我们可以看到目录同步环境中涉及的组件。

1. 本地 Active Directory - 这是在其中创建和更新用户和组对象的目录。
2. 目录同步服务器访问本地 Active Directory 并“拉取”信息（用户、组、联系人对象等）。

目录同步服务器，访问 Azure Active Directory 并“推送”（同步）信息。

1. Azure Active Directory 可以描述为“Office 365 目录服务”。
   当 Office 365 管理员向特定“同步 Office 365 用户”分配 Exchange Online 许可证时，信息将从 Azure Active Directory 同步到 Exchange Online 基础结构。
2. Exchange Online 基础结构 - 创建并与 Office 365 用户帐户关联的 Exchange Online 邮箱。

目录同步环境中“目录对象”的管理

在目录同步环境中，创建“新对象”（例如用户帐户和组帐户）的任务应该仅在本地 Active Directory 中创建，因为同步模型基于此概念-“单向同步”。

来自本地环境的信息同步到云端，但反之亦然。

稍后，我们将更好地了解这些字符与删除本地 Active Directory 用户帐户等场景有何关系，以及此删除如何影响云基础设施。

注意：该声明并不完全准确，因为对于非常特殊的属性，同步过程是在“发送”来自 Office 365 Directory 的信息并在本地 Active Directory 中更新时实施的。

为了简单起见，我们坚持将同步方向定义为“单向同步”的基本定义。

目录同步和“ImmutableID”的概念

如前所述，Azure Active Directory 充当本地 Active Directory 对象的副本，而且 Office 365 目录需要“了解”Office 365 用户帐户与其位于本地的“主帐户”之间存在的关系。 -本地活动目录。

用于使 Azure Active Directory 能够“理解”特定 Office 365 用户帐户是从本地 Active Directory“复制”（同步）的方法描述为 - ImmutableID。

从 Azure Active Directory 的角度来看，具有 ImmutableID 的 Office 365 的含义是，该 Office 365 用户“绑定”到本地 Active Directory 用户帐户。

Azure Active Directory“理解”她不是该对象的所有者，而只是代表本地 Active Directory 用户帐户的“主机”复制实体。

将本地 Active Directory 用户与 Office 365 用户帐户连接起来的“绑定机制”

如前所述，Active Directory 对象（例如“用户帐户”）从本地 Active Directory 同步到 Azure Active Directory。

例如，名为 John 的本地 Active Directory 用户帐户同步到“云”（Azure Active Directory），并在 Azure Active Directory 中创建名为 John 的新用户目录。

从技术上讲，现在有两个不同的用户帐户，存储在两个不同的目录中。

在目录同步环境中，我们需要定义一个逻辑结构，其中需要将两个不同的用户帐户关联为“一个实体”。

打个比方，我们需要实现一种机制，将本地 Active Directory 用户帐户与 Office 365 Directory 用户帐户“粘合”。用户属性的本地 Active Directory 中的每个用户帐户更新将成功同步到“匹配的”Office 365 目录用户帐户，并且“匹配的 Office 365 用户”将分别更新。

用于将本地 Active Directory 对象与云 Active Directory 对象“绑定”的方法，通过使用名为 - ImmutableID 的值实现。

“ImmutableID”这个词听起来奇怪又神秘。然而，“ImmutableID”的概念非常简单。

如果“Office 365 用户帐户”是通过目录同步过程创建的，则将填充 Office 365 用户的“ImmutableID”值。

“ImmutableID”的值使用本地 Active Directory 用户帐户的 GUID 值填充。

现在我们正在处理一个新术语 - GUID！

术语 GUID 代表 - 全局唯一标识符。
我们使用 GUID 值作为一种方法，为每个 Active Directory 对象提供唯一标识。
我们将此标识描述为“唯一”，因为没有其他 Active Directory 对象可以具有相同的 GUID 值。

我们可以将 GUID 值的用途与其他“身份方法”进行比较，例如“社会保障号”或每个网卡具有的 MAC 地址。

我们提到，本地 Active Directory 用户帐户的 GUID 值被复制并保存为 Office 365 用户帐户的 ImmutableID 值。

如果我们想要更准确，在基于 Office 365 的环境中，本地 Active Directory 用户的 GUID 值将转换为 64 位值，然后保存为 ImmutableID 值。

因此，从技术上讲，如果我们尝试将 GUID 值与 Office 365 用户帐户的 ImmutableID 值进行比较，我们会看到明显不同的值。

在下图中，我们可以看到本地 Active Directory 用户帐户和同步的云用户对象之间存在的关系示例。

“John”的 GUID 值作为 John 属性的一部分同步到 Office 365 目录 (Azure Active Directory)。
当“John”时em>云用户帐户”创建后，GUID值将保存在ImmutableID属性中。

请注意，这些值看起来不同！

造成差异的原因是原始 GUID 值正在转换为 64 位格式。

Office 365 用户帐户和 Exchange Online 邮箱之间的绑定。

如果我们将 Exchange Online 许可证分配给“同步 Office 365 用户帐户”（例如上例中的 John），则会创建一个新的 Exchange Online 邮箱并将其“附加”到 Office 365 用户帐户。

Office 365 用户帐户被视为 Exchange Online 邮箱的“所有者”。

完整的绑定基础设施

现在，当我们创建新的本地 Active Directory 用户帐户并将 Exchange Online 许可证分配给创建的 Office 365 新 Office 365 用户帐户时，我们可以定义以下“绑定流”：

• Office 365 用户帐户“附加”到本地 Active Directory 用户帐户。
• 当我们将 Exchange Online 许可证分配给 Office 365 用户帐户时，将创建一个新的 Exchange Online 邮箱并将其“附加”到 Office 365 用户帐户。
• Office 365 用户帐户，被视为 Exchange Online 邮箱的所有者
• 本地 Active Directory 用户帐户被视为与 Office 365 用户帐户相关的“权限来源”。

本地 Active Directory 用户帐户被删除的场景。

1. 如果本地 Active Directory 用户帐户被删除，结果是 Office 365 用户帐户也将被删除。
2. 如果删除 Office 365 用户帐户，则 Exchange Online 许可证将被删除。
3. 当删除 Exchange Online 许可证时，结果是 Exchange Online 邮箱也将被删除！

目录同步和“硬匹配”的概念

我们用于描述本地 Active Directory 用户帐户与其 Office 365 同步用户帐户之间关系的正式术语是 - 硬匹配。

硬匹配的实现依赖于本地 Active Directory 用户帐户的 GUID 值与其敏感 Office 365 用户帐户“合作伙伴”的 ImmutableID 值之间存在的“匹配”。

当我们创建一个新的Active Directory用户帐户，并将信息同步到Azure Active Directory（通过目录同步服务器）时，Azure Active Directory会创建一个新的用户帐户，该帐户将“绑定”到On-Premise Active Directory目录新帐户。

在这种情况下，Office 365 用户 ImmutableID 值将使用本地 Active Directory 用户 GUID 值进行填充。

从现在起，两个不同的用户帐户就相互“绑定”了。换句话说，两个用户帐户之间的关系被定义为“硬匹配”。

硬匹配机制在恢复 Exchange Online 邮箱的场景中的使用

硬匹配概念的一个示例是在基于 Active Directory 的环境中实施“最佳实践”Exchange Online 邮箱还原的过程。

已还原“绑定”到被视为 Exchange Online 邮箱的 Office 365 用户的 Active Directory Active Directory 用户。

当信息到达 Azure Active Directory 时，Azure Active Directory 会“通知”“已恢复的 Active Directory 用户帐户”的 GUID 值与“软删除的 Office 365 用户”的 ImmutableID 值相同（存储在 Azure Active Directory 回收站中的用户）。

由于 GUID 值和 Office 365 ImmutableID 值相同，因此这是这些对象“彼此相关”的明确标志。

事实上，软删除的 Office 365 具有与“新同步的 Active Directory 用户”相同的 ImmutableID，这意味着这两个对象过去曾连接过。

“绑定”两个用户对象的过程被视为 - 硬匹配。

“绑定两个用户帐户”（硬匹配）过程完成后，Azure Active Directory 将自动启动软删除 Office 365 用户帐户的还原过程（图中的数字 2） 。

Office 365 用户帐户的还原过程基于以下逻辑 - 如果本地 Active Directory 用户帐户（Office 365 用户帐户的主帐户）处于“活动状态”，则与此活动关联的 Office 365 用户帐户目录用户帐户也需要处于“活动状态”（从 Azure Active Directory 回收站恢复）。

目录同步和“软匹配”的概念

在目录同步环境中，术语“软匹配”定义了一种场景，其中我们拥有本地 Active Directory 用户帐户和 Office 365 用户帐户，它们具有相同的属性，例如电子邮件地址或用户 UPN（用户主体名称），但他们没有“硬匹配”关系。

换句话说，Office 365 用户帐户 ImmutableID 值为“空”。

例如，电子邮件地址为 [email protected] 的本地 Active Directory 用户和使用相同电子邮件地址的 Office 365 用户 ([email protected])。

理论上，这种情况是“错误的”，因为如上所述，在 Office 365 目录同步环境中，我们应该使用 Azure Active Directory 创建用户帐户等对象。

从理论上讲，“不允许”本地 Active Directory 用户帐户和 Office 365 用户帐户具有相同电子邮件地址的情况。

实现此方案的唯一选择是，如果 Office 365 用户是通过 Office 365 目录 (Azure Active Directory) 创建的，这与在 Office 365 目录同步环境中创建和管理用户帐户的准则相反。

创建目录同步服务器的人知道实际情况可能更加复杂，并且目录同步需要适应这种“非标准”场景。

例如，我们使用非同步环境，并通过 Azure Active Directory 手动创建所有组织用户的场景。

在稍后阶段，我们安装目录同步服务器并开始同步过程。

预期的结果是“碰撞”。

如果两个目录用户（本地 Active Directory 用户和 Office 365 目录用户）具有相同的登录名或相同的电子邮件地址，则这是对标准流程的“违反”，其中目录对象应该只能通过本地 Active Directory 创建。

好消息是，Office 365 目录同步足够智能，可以识别这种情况，并了解该双用户帐户的实体应该作为“同步对”更紧密地“绑定”，即使两个用户帐户之间不存在硬匹配。两个用户帐户。

换句话说，目录同步知道，即使没有“文档”表明这两个 Active Directory 用户帐户彼此相关（有关系），“正确的过程”是将这两个实体绑定在一起通过实施-硬匹配机制。

在下图中，我们可以看到一个场景示例，其中我们有两个不同的用户帐户，其登录名是 - [email protected]

当我们激活目录同步服务器时，目录同步服务器会“通知”Azure Active Directory 有关本地 Active Directory 用户帐户的登录名是 [email protected]。

Azure Active Directory“通知”目录同步服务器她已经拥有具有相同登录名的用户帐户。

目录同步“理解”他需要“附加”这些用户帐户。

目录同步复制 John 本地 Active Directory 用户帐户的 GUID 值，将该值转换为 64 位值，然后将结果复制到 Office 365 JohnImmutableID 值/em> 用户帐户。

John Office 365 用户帐户的状态从“在云中”更改为“与 Active Directory 同步”。 ”
从现在开始，这两个目录用户帐户被视为“情侣”。 ”
本地 Active Directory 用户帐户被视为“主”，因为本地 Active Directory 是权限来源。本地 Active Directory John 用户帐户中的每次更新都将同步并“覆盖”“John Office 365 用户帐户”中的现有信息。

当前文章系列的下一篇文章

Office 365环境中目录同步的特殊字符|第 2#2 条 |第 12 部分#23