Windows Server

恢复 Active Directory 逻辑删除对象

Gil Kirkpatrick

概览:

• 如何将已删除对象存储在 Active Directory 中
• 使用 LDP 和 ADRESTORE 查找和还原逻辑删除
• 对象属性和 systemFlags

也许这并不是您最喜欢思考的主题，但出现意外数据丢失的情况是一个不争的事实，作为一名 IT 专业人员，您必须准备好各种恢复方案。在 2007 年 4 月一期的《TechNet 杂志》**中，我论述了关于采取恢复

Active Directory® 用户和组的计划的重要性。可在 technetmagazine.com/issues/2007/04/ADRecovery 找到该文章，我在其中介绍了对象链接、复制、删除和授权还原的结构。遗憾的是，授权还原功能要求在目录服务还原模式 (DSRM) 下启动域控制器 (DC)。这样做会导致 DC 在还原操作期间不可用。

还存在另外一种方法，您应有所了解。逻辑删除恢复（与“僵尸”电脑无关）可提供无需使 DC 脱机就能恢复已删除对象的唯一方法，并且还是恢复已删除对象身份信息（如 objectGUID 和 objectSid 属性）的唯一方法。它巧妙地解决了重新创建已删除用户或组、必须修复所有旧访问控制列表 (ACL) 引用（其中包含已删除对象的 objectSid）的问题。不过请记住逻辑删除恢复有其自身的缺陷，相关内容我将在后面讨论，所以您仍需要掌握授权还原技能。

逻辑删除恢复是通过 Windows Server® 2003 Active Directory 引进的，用于简化一些数据恢复方案。在对对象进行物理删除之前，Active Directory 可将已删除对象保留在数据库中一段时间，该功能恰利用了这一点。在这篇文章中，我将详细描述 Active Directory 如何删除和恢复对象，还将演示如何使用标准 Microsoft 工具恢复已删除对象。

逻辑删除是什么？

当 Active Directory 从目录中删除对象时，并没有将对象从数据库中物理删除，而是通过将对象的 isDeleted 属性设置为 TRUE，删除对象的大部分属性、对对象进行重命名，然后将对象移动到对象的命名上下文 (NC) 中的一个特殊容器（名为 CN=Deleted Objects）中，从而将对象标记为已删除对象。此时的对象称为逻辑删除，在普通目录操作下，处于不可见状态。它不在任何 Microsoft® 管理控制台 (MMC) 管理单元中显示，大多数轻型目录访问协议 (LDAP) 实用工具意识不到逻辑删除的存在。无论从哪点看，逻辑删除似乎都消失了。然而，数据仍然存在，只是不可见而已。那么为什么 Active Directory 在数据库中保留逻辑删除这些在别处已删除的对象呢？

虽然逻辑删除对于其他过程不可见，但对于 Active Directory 复制过程是可见的。为了确保在所有承载被删除对象的 DC 上执行删除，Active Directory 将逻辑删除复制到其他 DC。因此逻辑删除被用于在 Active Directory 环境中复制删除。

逻辑删除的生存期

为响应 LDAP 删除协议操作或安全帐户管理器 (SAM) 删除操作，Active Directory 通常从目录中删除对象。此操作称为原始删除，与 Active Directory 复制过程执行的删除操作不同。注意，此处的讨论并未考虑动态对象，该类对象具有不同的删除机制，当它们的生存期 (TTL) 过期时，Active Directory 会将它们直接删除。

当 Active Directory 收到删除操作时，它首先遍历一个检查表以确保允许删除该对象。包含此过程显得有些奇怪，但这是因为它可确保满足以下所有条件：

• 未将对象的 isDeleted 属性设置为 TRUE。（无法删除已删除对象！）
• 未在对象的安全描述符中设置特定于“专有对象”资源的安全描述符控制标志。（这显示为未记录的“feature”。该专有对象标志是安全描述符结构的 Sbz1 字节的位 1。）
• 未在对象的 systemFlags 属性中设置“disallow delete”位 (0x80000000)。
• 未将对象的 isCriticalSystemObject 属性设置为 TRUE。
• 对象的安全描述符向用户授予了删除对象所需的相应访问权限。（更具体地来说，就是允许用户删除对象本身以及从父对象中删除子对象。）
• 该对象不是现有命名上下文的交叉引用对象 (objectClass = crossRef)。
• 该对象没有任何附属对象。（如果 LDAP 删除操作包含 LDAP "tree delete" 控件对象 ID，Active Directory 将同时自动删除附属对象，除非附属对象的 isCriticalSystemObject 属性设置为 TRUE。这样可防止将关键系统对象被作为树删除操作的一部分无意删除。当然您可以逐一删除这些对象。）
• 该对象不是关键内部对象（例如，它既不是 DC 的 nTDSDSA 对象，也不是 NC 头的上级的占位符对象）。

除了应满足这些条件外，Active Directory 还必须处于合适的状态以处理删除操作。例如，如果 Active Directory 正在重新命名一个域，它将不会删除域信任帐户或 crossRef 对象。

如果已确定对象确实可删除，那么 Active Directory 会继续将该对象转换为逻辑删除。Active Directory 首先删除不必要的对象属性，在逻辑删除中只保留图 1 中指定的以及架构中定义的那些属性。（请参阅“恢复对象属性”部分获取相关详细信息。）然后，它将对象的相对可分辨名称 (RDN) 更改为 CN=<old RDN>\0ADEL:<objectGUID>，其中，\0A 表示 ASCII 换行符字符，<objectGUID> 是以字符串形式表示的 objectGUID。然后，lastKnownParent 属性被设置为对象父容器的可分辨名称 (DN)，isDeleted 属性被设置为 TRUE。随后，Active Directory 删除对象中的所有前向和后向链接属性。最后，如果该对象的 systemFlag 属性不具有“disallow move on delete”位集，那么 Active Directory 会将对象移动到 NC 的 CN=Deleted Objects 容器中。（请参阅“systemFlags 属性和对象行为”侧栏，获取有关该主题的详细信息。）

Figure 1 保存在逻辑删除中的属性

您应注意 CN=Deleted Objects 文件夹是平面的，没有对象层次结构。您也许会认为，这会导致删除具有相同 CN 的两个不同对象时出现名称冲突。然而，事实并非如此。因为 objectGUID 合并到每一个逻辑删除的 RDN，而每一个逻辑删除的 RDN 在 CN=Deleted Objects 容器中是唯一的。

显然，对象不会永远保留在 CN=Deleted Objects 容器中。对于最初使用 Windows® 2000 和 Windows Server 2003 构建的林，其默认逻辑删除生存期为 60 天；最初使用 Windows Server 2003 SP1 构建的林，其默认逻辑删除生存期为 180 天。通过设置 CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=<root domain> 对象的 tombstoneLifetime 属性，可更改逻辑删除生存期。

每隔 12 个小时，每个域控制器就会启动一个垃圾收集进程。（通过为 CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=<root domain> 对象的 garbageCollPeriod 属性设置新值，可对此时间进行更改。）垃圾收集扫描 DC 上的所有逻辑删除，对其中超过逻辑删除生存期的逻辑删除进行物理删除。

使用 LDP 查找逻辑删除

LDP 是类似 Windows 资源管理器的实用工具，同 Active Directory 搭配使用。Active Directory 开发团队设计 LDP 的最初意图是在开发 Active Directory 时，使用 LDP 测试其 LDAP 代码。现在，作为 Windows Server 2003 支持工具的一部分，LDP 已经发展成为一种与 Active Directory 配合使用的强大工具。

虽然逻辑删除对于普通目录操作是不可见的，但是您可在 Active Directory 中使用 LDAP 搜索操作和称为控件的特殊 LDAP 扩展查找逻辑删除对象。控件是在 LDAP 标准中定义的一种机制，用于扩展 LDAP 协议以提供超出 LDAP 标准中定义的功能以外的额外功能，同时保留与其他符合 LDAP 的软件的兼容性。Active Directory 支持 22 个控件，其中包含 Return Deleted Objects 控件。当使用该控件扩展 LDAP 搜索操作时，该控件会检索在其他情形下不可见的已删除对象。

为了演示该工作过程，我使用企业管理员凭据登录 foo.local 域，然后使用 Active Directory 用户和计算机 (ADUC) MMC 管理单元创建用户对象 (CN=John Smith,CN=Users,DC=foo, DC=local)，如图 2 所示。然后再次使用 ADUC 删除该用户对象。

图 2** 使用 ADUC 创建用户 **(单击该图像获得较大视图)

现在，我可以运行 LDP 程序并使用它显示已删除用户的逻辑删除。第一步是将 LDP 连接到特定的 DC，然后使用相应的凭据进行身份验证。要连接到 DC，只需在“连接”菜单上选择“连接”选项。因为我正在 DC 上运行 LDP，所以只需按“确定”即可连接到本地 DC。如果正在远程运行 LDP，则必须指定打算连接到的 DC 的名称。连接成功后，LDP 会显示 rootDSE 的属性 — 这包含描述 DC 本身的状态和配置的属性（请参见图 3）。

图 3** 连接到 DC 的 LDP **(单击该图像获得较大视图)

现在，为了使用域或企业管理员凭据对 DC 进行身份验证，我在“连接”菜单上选择“绑定”。因为我已经作为林的企业管理员登录（默认情况下，域管理员和企业管理员有权列出并恢复 CN=Deleted Objects 容器中的对象），所以我只要使“绑定”对话框中的“用户名”和“密码”保持空白然后按“确定”即可。否则，我可以在“绑定”对话框中输入相应的凭据。

下一步，列出 CN=Deleted Objects,DC=foo,DC=local con- tainer 的内容。正常情况下，您不会看到 CN=Deleted Objects 容器，因为该容器本身被标记为已删除。搜索 CN=Deleted Objects 容器的唯一方法是使用 Return Deleted Objects LDAP 控件。

要对 LDP 使用此控件，请转到“浏览”菜单，然后选择“搜索”。此时会出现图 4 中所示的“搜索”对话框。基 Dn 字段允许您在目录树中指定搜索开始的位置。输入域的“已删除对象”容器的 DN，在本例中，DN 是 CN=Deleted Objects,DC=foo,DC=local。

图 4** “LDP 搜索”对话框 **

在筛选器字段中，我指定了 LDP 将使用的搜索条件。默认值为 (objectClass=*)，它会指示搜索返回所有具有 objectClass 属性值的对象。因为在 Active Directory 中已删除的对象也具有 objectClass 值，所以默认筛选器将返回该搜索范围内的每个对象。在本例中，我将筛选器更改为 (objectClass=user)，将搜索限制为用户对象。这样，在 CN=Deleted Objects 容器大约成千上万的逻辑删除中查找已删除的 John Smith 用户会比较简单。

您可能会发现，在单个搜索操作中，CN=Deleted Objects 容器要比 Active Directory 返回的对象多。要解决此问题，通常您将使用分页 LDAP 搜索，每次返回一组结果。但是，LDP 不允许同时指定分页和扩展搜索。所以，必须优化 LDAP 筛选器来查找希望获取的对象。

使用“范围”单选按钮，可以指定要搜索的目录树范围。基础搜索将仅返回由基 Dn 字段指定的对象。一级搜索将返回直接从属于基 Dn 对象的对象。子树搜索将返回所有从属于基 Dn 对象的对象。由于 CN=Deleted Objects 文件夹是平面的，因此我使用一级搜索来检索所有逻辑删除。

到目前为止，我仅大致介绍了传统的 LDAP 搜索。如果我现在就运行搜索，LDP 将显示一个错误，指出 CN=Deleted Objects,DC=foo,DC=com 不存在，因为它被标记为已删除。我仍必须将 Return Deleted Objects LDAP 控件包括在搜索操作中。为此，我单击“搜索”对话框上的“选项”按钮，然后选择搜索调用类型为“已扩展”，如图 5 所示。通过此选项，我能够为搜索操作指定控件。此处，我还将属性列表更改为 *。这将导致 LDP 显示它检索的每个对象的所有常规属性，而不是 LDP 的默认属性集。

图 5** LDP 搜索 “选项”对话框 **

现在我按下“控件”按钮以显示“控件”对话框。LDP 的“控件”对话框有点难以使用，所以当进行此操作时，请确保认真执行以下步骤以添加 Return Deleted Objects 控件。

打开“加载预定义控件”下拉列表，选择“Return Deleted Objects”，然后按“签入”按钮。这将 Return Deleted Objects 控件 (1.2.840.113556.1.4.417) 的对象标识符 (OID) 添加到“活动控件”列表中，如图 6 所示。然后，LDP 将该控件添加到所有的后续扩展搜索操作中。按“确定”以保存控件设置，然后再次按“确定”关闭“搜索选项”对话框。

图 6** 添加 Return Deleted Objects 控件 **

“控件”对话框具有一些特殊行为。具体来说，即使 OID 显示在“活动控件”列表中，也并不一定意味着该控件实际上已生效。有时，您必须签出控件，然后再将其签回，以确保将在下一个 LDAP 操作中可使用此控件。

现在我已准备好运行我的搜索了。我按下“LDP 搜索”对话框上的“确定”按钮，然后 LDP 将检索来自该域 CN=Deleted Objects 容器的所有用户对象。图 7 显示了我的结果。

图 7** 来自 CN=Deleted Objects 容器的结果 **(单击该图像获得较大视图)

检查 LDP 结果

我的搜索返回了两个逻辑删除对象。首先，您可以看到第一个逻辑删除的 DN：CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local。已删除对象的 objectGUID 表示为字符串 (41800281-6bc4-42c3-a99b-b283022b3af8)。在 DN 下面有一个属性列表，显示了 objectClass、cn 和 distinguishedName 等的值。您可以看到 isDeleted 属性的值为 TRUE，这表示该对象实际上已被删除。您还会看到 objectSid 已被保留在逻辑删除中 — 这对于恢复用户和组逻辑删除来说非常重要，稍后我将讲到这一点。lastKnownParent 属性表示在成为逻辑删除之前包含已删除对象的对象的 DN，此属性在恢复逻辑删除时也极其重要。

在我的示例中，LDP 显示了两个逻辑删除对象，两个都是来自 CN=Users,dc=foo,dc=local 容器的名为 CN=John Smith 的用户对象。两个具有相同 RDN 的单独对象怎么会来自同一容器？这个解释起来非常简单。在运行 LDP 搜索逻辑删除之前，我在 CN=Users,DC=foo,DC=local 容器中创建了 CN=John Smith 用户对象，然后又将其删除。然后，我创建了另一用户对象，并且所有属性与 CN=John Smith 用户对象的属性完全相同，我又将其删除。因为我已经删除了第一个 CN=John Smith 用户对象，所以创建第二个用户对象是完全合理的，即使它具有相同的名称也无妨。但它们是单独的、唯一的对象，由它们的 objectGUID 加以区分。因为 Active Directory 将 objectGUID 合并到了逻辑删除的 DN 中，因此它们在 CN=Deleted Objects 容器中显示为单独的对象。

逻辑删除是如何恢复的

Active Directory 提供了将逻辑删除恢复为常规对象的机制。这实际上是一个针对已删除对象的取消删除操作函数。此函数是一个结构特殊的 LDAP 修改操作，必须包括两个特定属性修改：它必须删除 isDeleted 属性（不是仅设置为 FALSE），并且它必须通过更改对象的 distinguishedName 将对象移动到另一容器。新的 distinguishedName 通常（但并不一定）将 lastKnownParent 属性用作容器，保留相同的 RDN，而不包括 Active Directory 创建逻辑删除时添加的 \0ADEL:<objectGUID> 组件。

在恢复逻辑删除之前，Active Directory 进行检查，以确保满足所有特定的必要条件。用户必须具有恢复逻辑删除扩展的访问权限，该权限是在包含逻辑删除的 NC 的 NC 头上定义的。用户不能恢复自己的对象。必须将逻辑删除的 isDeleted 属性设置为 TRUE。与在安全描述符中定义的相同，对象的所有者安全标识符 (SID) 必须具有来自林中某一个域或者受信任域的 SID。

如果涉及的对象位于“配置”或“架构 NC”中，则必须在逻辑删除的 systemFlags 属性中设置 FLAG_CONFIG_ALLOW_RENAME 和 FLAG_ CONFIG_ALLOW_MOVE 位。如果对象位于“配置”或“架构 NC”中，并且已经设置 FLAG_CONFIG_ALLOW_LIMITED_MOVE 标志，则仅可将该对象移动至具有相同祖父的容器中 — 也就是说在移动后，该对象必须保留其增祖父。如果对象位于域 NC 或应用程序分区中，则不应在逻辑删除的 systemFlags 属性中设置 FLAG_DOMAIN_DISALLOW_RENAME 和 FLAG_DOMAIN_DISALLOW_MOVE 位。

正如安全描述符中所定义的，用户必须有修改 RDN（通常是 CN，但并非始终如此）并将对象添加到新的父容器的权限。并且按照架构定义，对于逻辑删除的 objectClass，新父容器必须可以是上一级。虽然在正常情况下不允许移入或移出系统容器（除非 Unlock system subtree 注册表值为非零），但是，允许将逻辑删除恢复到系统容器中。

永远不允许恢复架构对象。但是，这并不会真正成为一个问题，因为您不能从构架 NC 合法地删除对象。

如果所有检查都成功且满足所需条件，Active Directory 将对逻辑删除执行下列步骤来恢复该对象：

• 删除 isDeleted 属性。
• 如果未在修改操作中另行规定，会将 objectCategory 设置为逻辑删除中指出的最特定 objectClass。
• RDN 已更改并且已将该对象写入新的父容器。

恢复后，该对象具有与原来相同的 objectGUID 和 objectSid 属性。这意味着对该对象的外部引用（如在 ACL 中）不必像重新创建已删除对象时那样进行重置。该恢复对象看起来以及操作起来都和删除前一样。不过，还有一个重要差异：还原的对象丢失了在逻辑删除中未保存的全部属性。

使用 LDP 恢复逻辑删除

systemFlags 属性和对象行为

systemFlags 属性是为 top 类定义的可选属性，它使 systemFlags 成为每个 Active Directory 类的可选属性。它是 32 位整数位掩码，用于控制对象移动和删除的行为。下面是一个重要标志梗概：

FLAG_DISALLOW_DELETE (0x80000000)

如果设置了此标志，系统将禁止删除对象或将对象移动到另一个域。

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

不能重命名配置 NC 和架构 NC 中的对象，除非在 systemFlags 属性中设置了此标志。

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

不能移动配置 NC 和架构 NC 中的对象，除非在 systemFlags 属性中设置了此标志。

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

不能移动配置 NC 和架构 NC 中的对象，除非在 systemFlags 属性中设置了此标志。此标志对移动操作的目标容器进行了进一步的限制 — 目标容器必须与当前容器具有相同的“祖父”。

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

默认情况下，可以重命名域 NC 或应用程序 NC 中的对象。但是，如果对象的 systemFlags 属性设置了此标志，系统将不允许重命名该对象。

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

默认情况下，可将域 NC 或应用程序 NC 中的对象移动到另一个容器。但是，如果对象的 systemFlags 属性设置了此标志，系统将不允许移动该对象。

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

如果设置了此标志，系统不会将对象移动到其命名上下文的 CN=Deleted Objects 容器中。它将只设置 isDeleted 属性，重命名该对象并删除要保存的架构中未指定的属性。这意味着并不是所有已删除对象都会出现在命名上下文的 CN=Deleted Objects 容器中；某些对象仍然会保留在原始父容器中。

前面我已经展示了逻辑删除恢复工作的具体细节，现在我要演示怎样使用 LDP 还原已删除的用户 CN=John Smith。首先，我连接到 DC 并进行身份验证。现在，我可以使用 LDP 执行修改操作。在修改操作参数过程中，我可以删除 isDeleted 属性，同时指定一个新的 DN。

因为我打算对逻辑删除进行操作，所以必须指定 Return Deleted Objects LDAP 控件。若要在 LDP 中为修改操作设置此控件，请在“选项”菜单下选择“控件”，在“加载预定义控件”下拉列表中选择“Return deleted objects”，然后按“签入”按钮，最后按“确定”保存控件设置。

现在，在“浏览”菜单中选择“修改”，打开“修改”对话框，输入要还原的逻辑删除对象的 DN。执行此操作最简单的方法是复制和粘贴来自之前执行的搜索操作结果中的 DN。

下一步，我必须输入待执行的属性操作的列表。恢复逻辑删除需要执行两个属性操作 — 删除 isDeleted 属性以及使用所需的恢复逻辑删除的 DN 替换 distinguishedName 属性。所以，我在“属性”字段中键入 isDeleted，然后选择“删除”单选按钮。按 Enter 按钮后，该属性操作将添加到“条目”列表，如图 8 所示。

图 8** 指定待执行的属性操作 **

然后，我在“属性”字段中输入 distinguishedName，选择“替换”单选按钮，然后在“值”字段中输入该对象的新 DN。在本例中，我使用用户的原始 distuiguishedName，CN=John Smith,CN=Users,DC=foo,DC=local。按 Enter 按钮后，该修改操作将添加到“条目”列表。

因为我必须使用修改操作包括 Return Deleted objects LDAP 控件，所以我必须使用扩展的 LDAP 修改。为此，我选中了“扩展”复选框。设置好所有相关内容后，如图 9 所示，按“运行”按钮以进行更改。LDP 在一个大文本窗口中显示结果。

图 9** 更改 distinguishedName **

当返回 Active Directory 用户和计算机 MMC 管理单元查看 CN=Users 容器时，我将发现曾被删除的用户对象还原到了原处。但是，该对象与原来的对象间存在某些重要的差异，稍后我将进行介绍。

使用 ADRESTORE 恢复逻辑删除

一旦明白了使用 LDP 的方法，恢复逻辑删除就不是很难了，但也不是非常方便。幸运的是，Sysinternals（Microsoft 的附属公司）的优秀员工们开发了一种命令行工具，从而简化了恢复过程。此工具叫做 ADRESTORE，可以从 Microsoft 网站 microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx 获得。安装很简单。只要将可执行文件复制到计算机的相应目录下即可，例如 C:\WINDOWS\SYSTEM32 目录。

ADRESTORE 可以在两种模式下运行。如果您在不带任何参数的情况下运行它，它将列出默认域的 CN=Deleted Objects 容器中的所有逻辑删除。您可以将搜索字符串添加到命令行来选择要显示的对象，例如：

C:\> adrestore John

这样就会显示 CN=Deleted Objects 容器中其 CN 或 OU 属性中包含“John”字符串的所有逻辑删除对象 — 它使用 LDAP 搜索过滤器 cn=*John* 和 ou=*John*。这不是搜索逻辑删除对象最灵活的方式，但它在大多数情况下都可以使用。图 10 显示了在 ADRESTORE 中我的搜索所返回的输出。

图 10** 保存在逻辑删除中的属性 **(单击该图像获得较大视图)

如果您希望恢复逻辑删除，而不仅仅是找到它，那么您需要指定 –r 开关和可选字符串，如下所示：

C:\> adrestore –r John

此命令将提示您恢复每一个匹配的逻辑删除对象。ADRESTORE 总是将对象恢复到逻辑删除的 lastKnownParent 属性指定的容器中 — 无法指定其他容器。

ADRESTORE 为使用 Active Directory 恢复功能提供了方便的命令行界面。虽然不是非常灵活，但它确实比 LDP 便于使用。但 ADRESTORE 仍不能避免恢复逻辑删除时遇到的两个重大问题：恢复对象第一次被删除后从对象去除的属性、恢复从配置 NC 中删除的对象。

恢复对象属性

就数据恢复而言，逻辑删除恢复与执行授权还原相比有一个重要优势：逻辑删除恢复不需要使 DC 处于脱机状态。并且恢复逻辑删除要比仅仅重新创建一个新版本的已删除对象要好得多。如果重新创建某个对象，它将获得新的 objectGUID 和 objectSid（如果它是安全主体，如用户）属性。如此一来，对该对象的所有外部引用（如 ACL）都必须更新才能反映新对象的身份。这是很让人头疼的。

删除对象时，某些属性会被去除，并且不能使用逻辑删除恢复来恢复这些属性。但是 Active Directory 在逻辑删除中保存了一些关键属性，其中最重要的是与身份相关的属性，如 objectGUID 和 objectSid。默认情况下，它也保存了其他许多属性（参见图 1）。保存大部分硬编码属性并不很稀奇，尤其是在有关恢复已删除用户对象的讨论中。但通过设置 Active Directory 构架中相应 attributeSchema 对象的 searchFlags 属性的位 3 (0x00000008)，您可以指定要保存在逻辑删除中的其他属性。在 Windows Server 2003 R2 的架构中，已设置了某些属性的此位（如图 1 所示）。

安装特定应用程序可以更改现有 searchFlags 属性的位 3，甚至可添加设置了位 3 的新属性。例如，Exchange Server 可配置要保存在逻辑删除中的几个其他属性。

Active Directory 不会在逻辑删除中保存前向链接属性或后向链接属性，即使您在架构对象的 searchFlags 属性中指定了此操作也会如此。特别是，Active Directory 不会保存组的 member 属性或用户的 memberOf 属性之类的内容。因此逻辑删除恢复不会为恢复 Active Directory 中的组成员资格提供解决方案。有关此方面信息，请参见我的“灾难恢复：Active Directory 用户和组成员”文章，可在 technetmagazine.com/issues/2007/04/ADRecovery 上找到该文章。因此恢复逻辑删除时，您仍需要提供一个备用机制以便恢复此类信息。

如果希望使用逻辑删除恢复作为数据恢复策略的一部分，您需要确保在逻辑删除中保存了重要的属性，或者需要提供其他方法来保存和恢复重要的属性，例如使用 LDIFDE 或其他备份和还原方案。其他选择包括使用可以提供自动机制来备份和恢复逻辑删除中没有保存并且不能通过逻辑删除恢复的属性的第三方 Active Directory 数据恢复产品。

从配置命名上下文恢复对象。

对逻辑删除恢复的另一项重要限制是，一般而言，您不能恢复从配置 NC 删除的对象。如对象的 systemFlags 属性定义的那样，这些对象受与移动和重命名相关的特殊规则限制。除非通过 systemFlags 属性另行指定，否则配置 NC 中的对象不能移动或重命名，这意味着它们的逻辑删除无法恢复。如图 11 中定义的那样，Active Directory 在创建特定类的对象时强制 systemFlags 属性采用特定值。请注意，Active Directory 将对这些值应用按位逻辑 OR 操作以与添加操作中指定的任何 systemFlags 值相结合。这样，即使应用程序为 systemFlags 属性指定了不同的值，也会正确设置所需的位。

Figure 11 默认 systemFlags 设置

正常情况下，来自配置 NC 的唯一可恢复对象是服务器对象。有趣的是，当 Active Directory 删除服务器对象时，逻辑删除不会被移动到配置 NC 的 CN=Deleted Objects 容器；逻辑删除只是保留在对象所在的位置。这样，对于已删除的服务器对象可能阻碍正确复制的特定情况，就可以通过知识一致性检查器 (KCC)（该进程负责计算 Active Directory 复制拓扑）自动从这些情况恢复。因此，如果您发现自己在试图恢复某个服务器对象，请记住您不会在 CN=Deleted Objects 容器中找到该服务器对象。

在恢复计划中恢复

逻辑删除恢复应是数据恢复工具包的一个重要部分。此机制是无需使 DC 脱机就能恢复已删除对象的唯一方法，同样重要的是，它也是恢复已删除对象的身份信息的唯一方法。它巧妙地解决了重新创建已删除的用户或组以及必须修复所有旧 ACL 引用的问题。

但是，逻辑删除恢复是一项不完整的解决方案。您必须为恢复 Active Directory 没有保存在逻辑删除对象中的属性提供您自己的机制，并且您从配置 NC 恢复已删除对象的能力受到限制。请记住，如果确实选择要恢复已删除的用户或组，则您还必须恢复组成员资格和可能需要的其他任何链接属性。

Gil Kirkpatrick是 NetPro 的 CTO，他自 1996 年起便一直参与开发 Active Directory 软件。他与来自 HP 的 Guido Grillenmeier 一起创办了广受欢迎的 Active Directory 灾难恢复学习班。Gil 还是目录专家会议 (www.dec2007.com) 的创始人。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.