Windows 管理
灾难恢复：Active Directory 用户和组
Gil Kirkpatrick
概览:
- 复制和对象链接结构
- 使用 NTDSUTIL 备份和还原
- 权威还原和非权威还原
Active Directory 是 Windows 网络中最为关键的服务之一。为了避免出现停机时间和损失生产力，对与 Active Directory 有关的问题制订有效的灾难恢复计划是至关重要的。这一点听起来容易，但
令人吃惊的是，有很多管理员甚至没有为最常见的一个 Active Directory® 故障方案 - 意外删除数据 - 制定计划。
意外删除对象是服务失败最常见的根本原因之一。当我参加研讨会和会议时，我常常询问有谁曾经因为意外删除数据而导致 Active Directory 失败。而每次几乎所有人都举手。
要理解为何数据恢复是如此复杂，必须先理解以下内容：Active Directory 如何恢复和复制对象、如何删除对象以及权威还原和非权威还原的结构。
存储对象
Active Directory 是一个实施 X.500/LDAP 数据模型的专门的对象数据库。数据存储（称为目录信息树或 DIT）基于可扩展存储引擎 (ESE)，这是一个索引顺序访问方法 (ISAM) 数据库引擎。从概念上说，Active Directory 将 DIT 存储在两张表中：数据表（包含实际的 Active Directory 对象和属性）和链接表（包含对象之间的关系）。
每个 Active Directory 对象存储在数据表中单独的一行，每个属性一列。数据表包含存储在域控制器 (DC) 上的所有副本的所有条目。在一个常规 DC 上，数据表包含来自域 NC（命名上下文）、配置 NC 和架构 NC 的条目。在全局编录上，数据表包含林中每个对象的条目。
Active Directory 使用可分辨名称标记 (DNT)（一个 32 位的整数）来唯一标识数据表中的每一行。用于内部引用对象的 DNT 比其他标识符如可分辨名称 (DN) 和 objectGUID（一个 16 字节的二进制结构）都小得多。但是与 objectGUID 不同的是，DNT 是一个本地标识符，并且在每个 DC 上都不同。
Active Directory 如何链接对象
Active Directory 管理 DIT 中对象间的两类关系：父子关系（也称为容器关系）和引用关系（也称为链接关系）。为了实施父子关系，Active Directory 在数据表中存储了一个称为父可分辨名称标记（或 PDNT）的附加列。该列始终包含对象的父对象的 DNT。
Active Directory 中的每个属性均由 Active Directory 架构容器中的 attributeSchema 对象定义。Active Directory 中的某些属性定义为链接属性，由 attributeSchema 对象的 linkID 属性中的一个非零偶数值确定。链接属性建立了目录中对象间的关系，可以是单值或多值。组对象的成员属性是多值链接属性的一个例子 — 它建立了组对象及其成员对象之间的链接。
即使看起来组的成员属性包含成员的 DN（例如，通过 Active Directory 用户和计算机管理单元显示），但这不是 Active Directory 存储它们的方式。当您将成员对象的 DN 添加到组的成员属性时，Active Directory 存储对象的 DNT 而并非其 DN。由于即使将对象重命名 DNT 也不会改变，因此可以重命名用户对象，而且 Active Directory 不用对系统中所有的组排序以更新每个成员属性的 DN。这就是 Active Directory 如何在 DIT 内维护引用完整性的原理。图 1 所示为一个经过大大简化的数据表和链接表如何彼此关联的示意图。这些表所示的三个用户对象（Molly Clark、Alexander Tumanov 和 Makoto Yamagishi）都是 Senior Engineers 组的成员。
Figure 1 数据和链接表如何相关
| 数据表 | |||
| DNT | PDNT | 对象类 | Cn |
| 14529 | 14401 | organizationalUnit | 工程师 |
| 14530 | 14529 | 组 | 高级工程师 |
| 14531 | 14529 | 用户 | Molly Clark |
| 14532 | 14529 | 用户 | Alexander Tumanov |
| 14533 | 14529 | 用户 | Makoto Yamagishi |
| 链接表 | |||
| 属性 | DNT | 前向链接 | |
| 成员 | 14530 | 14531 | |
| 成员 | 14530 | 14532 | |
| 成员 | 14530 | 14533 |
这些链接称为前向链接。类似地，Active Directory 还提供了后向链接属性。这为从链接指向的对象返回到引用链接的对象提供了引用，意味着该对象具有前向链接。用户和组的 memberOf 属性是后向链接属性的一个例子。属性 Schema 对象描述了一个后向链接属性，该属性具有 linkID 值，其值比相应的前向链接属性以偶数编号的 linkID 值大 1。 例如，Windows Server® 2003 R2 架构中成员属性的 linkID 值为 2，作为后向链接的 memberOf 属性的 linkID 值为 3。有关详细信息，图 2 提供了一个默认情况下 Windows Server 2003 R2 架构中定义的链接属性列表。
Figure 2 Windows Server 2003 R2 架构中的链接属性
| 前向链接属性 | linkID | 后向链接属性 | 链接的 |
| 成员 | 2 | memberOf | 3 |
| 管理员 | 42 | directReports | 43 |
| 所有者 | 44 | ownerBL | 45 |
| siteObject | 46 | siteObjectBL | 47 |
| nonSecurityMember | 50 | nonSecurityMemberBL | 51 |
| queryPolicyObject | 68 | queryPolicyBL | 69 |
| privilegeHolder | 70 | isPrivilegeHolder | 71 |
| managedBy | 72 | managedObjects | 73 |
| hasPartialReplicaNCs | 74 | ||
| hasMasterNCs | 76 | masteredBy | 77 |
| syncMembership | 78 | ||
| serverReference | 94 | serverReferenceBL | 95 |
| bridgeheadTransportList | 98 | bridgeheadServerListBL | 99 |
| netbootServer | 100 | netbootSCPBL | 101 |
| frsComputerReference | 102 | frsComputerReferenceBL | 103 |
| fRSMemberReference | 104 | fRSMemberReferenceBL | 105 |
| fRSPrimaryMember | 106 | ||
| siteLinkList | 142 | ||
| siteList | 144 | ||
| msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041 |
| msDS-NC-Replica-Locations | 1044 | ||
| msFRS-Hub-Member | 1046 | ||
| msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049 |
| msDS-SDReferenceDomain | 2000 | ||
| msDS-HasInstantiatedNCs | 2002 | ||
| msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015 |
| msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017 |
| msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019 |
| msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021 |
| msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023 |
| msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025 |
| msDS-HasDomainNCs | 2026 | ||
| msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031 |
| msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037 |
| msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039 |
| msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051 |
| msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053 |
后向链接属性总是多值的，由 Active Directory 自动维护。实际上，您不能直接修改后向链接属性。尽管看起来可以通过 Active Directory 用户和计算机 MMC 管理单元修改用户或组的 memberOf 属性，但该管理单元实际上修改的是相应组的成员属性，而 Active Directory 将在后台更新 memberOf 属性。这就是为什么无需有关用户对象的权限即可添加用户到组的原因；因为您实际上修改的是组对象的成员属性。因为每个 DC 都在本地管理其后向链接属性，所以永远不会复制对后向链接的更改。只复制对前向链接属性的更改（如组的成员属性）。
在一个常规 DC 上，数据表包含域对象的条目以及来自配置和架构容器的对象条目。但一些组类型可能包含对位于其他域中对象的引用。Active Directory 如何存储不在其数据表中的对象的 DNT？答案在于基础结构主机 FSMO（灵活单主机操作）角色所有者和称为幻影对象的对象。
幻影对象
当将一个成员从一个域添加到其他域中的组时，Active Directory 在数据表中自动创建一个称为幻影的特殊对象，它包含新成员的 objectGUID、objectSid 和 DN。这提供了可存储在组的成员属性中的 DNT。如果域控制器是全局编录，则将无需创建幻影，因为在其数据表中林中每个对象都已有一个条目。
拥有基础结构 FSMO 角色的 DC 定期根据全局编录检查其数据表中的条目，当它发现有对象被移动、重命名或删除时，它将更新数据表中的幻影并将更改复制到域中的其他 DC。根据引用计数，基础结构主机还会删除域中任何前向链接属性都不再引用的幻影。
幻影允许 DC 管理指向林内其他域中对象的引用，但前向链接属性还可以引用林外的对象 — 例如受信任的域。在这种情况下，Active Directory 在域 NC 中的 CN=ForeignSecurityPrincipals 容器内创建一个称为外部安全主体 (FSP) 的对象。FSP 包含外部对象的安全标识符 (SID) 和标识外部域中对象的其他属性，但没有流程确保 FSP 保持最新。出于数据恢复的目的，我们将象对待其他任何 Active Directory 对象一样对待 FSP。
删除对象
在这里，我将焦点主要放在还原用户及其组成员身份上。但是，同样的原则也适用于恢复其他链接属性。
当 Active Directory 删除一个对象时，它并没有从 DIT 物理删除该对象。相反地，它将该对象的 isDeleted 属性设置为 true 从而将其标记为已删除，这样使得该对象对常规目录操作不可见。按照架构定义，Active Directory 删除所有未指定要保存的属性并将对象的相对可分辨名称 (RDN) 更改为 <old RDN>\0aDEL:<objectGUID>。然后，它将对象移动到 NC 的 CN=Deleted Objects 容器。（配置 NC 中有一些对象类 Active Directory 不移动到“已删除对象”容器。）Active Directory 删除任意指向已删除对象保留的其他对象的前向链接 — 这样在链接表中降低了其引用计数。如果有其他对象包含指向现在已删除对象的前向链接，Active Directory 同样也会删除这些链接。
得到的对象称为 tombstone。Active Directory 将此 tombstone 复制到其中做了同样更改的其他 DC。请注意，Active Directory 不会复制对指向已删除对象的前向链接所做的更改。每个 DC 在本地进行同等更改，因此不需要复制更改。我将在本文稍后的部分讨论恢复组成员身份的后续结果。
Active Directory 维护 DIT 中逻辑上删除的对象由 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 对象的 tombstoneLifetime 属性决定。对每个 DC 的垃圾收集流程将删除比配置的 tombstone 生存期更老的 tombstone。默认情况下，tombstone 生存期对 Windows® 2000、Windows Server 2003 和 Windows Server 2003 R2 是 60 天，对 Windows Server 2003 SP1 是 180 天。
Tombstone 生存期对还原过程有着重大意义。不能还原比 tombstone 生存期更老的备份。因为已删除并从域中作为垃圾收集的对象不再有 tombstone，所以永远不会将删除操作重新复制到还原的 DC。接下来，已删除的对象将作为延迟对象保留在还原的 DC 中，而还原的 DC 将永远不能正确地与域中其他 DC 聚合。
复制对象
无论何时域控制器执行任何类型的更新操作（例如添加对象或修改属性）时，DC 都会为更新操作分配一个唯一的 64 位数字，称为更新序列号 (USN)。Active Directory 使用 USN 标记更新的对象和属性以帮助确定是否需要复制它们。
Active Directory 逐个属性地复制对象。也就是说，如果修改一个对象的属性，Active Directory 将只复制该属性，而非整个对象。要做到这一点，Active Directory 使用复制元数据跟踪它对每个属性所做的更改。一个属性的复制元数据包括：
- 本地 USN，标识本地 DC 上的更改操作。
- 引起更改的 DC 的 invocationID（特别是 DC 相应的 nTDSSettings 对象的 invocationID 属性），标识域控制器上 DIT 的特定生成。
- 源操作位于源 DC 上时的 USN。
- 时间戳，包含进行源更改时的 DC 系统时间。
- 32 位版本序号，每次值更改时递增。
当目标 DC 从其源 DC 合作伙伴请求更改时，它将最近成功进行复制更改的 USN 发送到源 DC，同时附带包含最大源 USN 的最新向量。这些源 USN 是目标 DC 从每个具有所复制 NC 副本的 DC 上所见的最大源 USN 。源 DC 使用此信息以便只发送目标 DC 尚未看见的那些更新。
当目标 DC 处理传入的属性更新时，它将核对每个属性的版本号。如果传入属性的版本号大于 DC 已有的该属性版本，则 DC 将存储该传入值。如果传入版本号等于 DC 已有的版本，则 DC 将比较时间戳并使用时间戳最新的属性。如果时间戳相同，目标 DC 将选择具有最大 invocationID 的值。这样可以确保每个 DC 最终为每个复制的属性确定相同的值。
链接值复制
在 Windows 2000 中，Active Directory 复制多值属性的方式与复制单值属性相同。这对那些多值成员属性可能在不同 DC 上经常更改的大型动态组对象可能带来问题。如果一位管理员添加用户到一个 DC 上的组，而另一位管理员在复制延迟窗口内添加其他用户到另一个 DC 上的组，则 Active Directory 将选择后一个添加并完全丢失前一个添加。Microsoft 在 Windows Server 2003 中使用一个称为链接值复制 (LVR) 的进程处理此问题。
凭借 Windows Server 2003 林的功能级别或过渡林的功能级别，Active Directory 分别复制多值前向链接属性的单个值，每个值拥有其自己的复制元数据。这有效解决了在 Windows 2000 中发现的问题，即在不同 DC 上几乎同步的组成员身份更新可能导致数据丢失。
但是，有一点需要指出。提升林的功能级别不会自动使用新的复制元数据修复现有的多值链接属性。只有那些在提升林的功能级别之后添加的值才有新的元数据。这对恢复组成员身份具有重大影响，您很快就会看到。
备份
Windows 包括非常基本的 NTBACKUP 实用程序，可以使用它来执行 DC 的系统状态备份。域控制器的系统状态包括其注册表、SYSVOL、Active Directory DIT 文件和关键系统文件。大多数第三方备份实用程序也有备份和还原 DC 系统状态的功能。
要执行对磁盘文件的系统状态备份，请使用以下命令：
NTBACKUP backup systemstate /F “<filename>”
此处，<filename> 是要创建的备份文件的名称，应使用 .bkf 扩展名。
执行非权威还原
从备份还原已删除的 Active Directory 对象分为两步：首先，重新启动 DC 进入目录服务还原模式 (DSRM)，然后使用 Windows NTBACKUP 实用程序或同等的第三方产品从系统状态备份还原整个 Active Directory DIT。此过程将覆盖整个 DIT。
有两种方法可以启动 DC 进入 DSRM：如果对 DC 的系统控制台有访问权限，关闭并重新启动 DC，当提示时按 F8 引出 Windows 启动菜单。从菜单中选择“目录服务还原”然后输入 DSRM 密码。
如果远程管理该服务器，则不能访问 Windows 启动菜单。替代方法是，通过从“我的电脑”选择“属性”，单击“高级”选项卡，然后按“启动和恢复”下方的“设置”按钮，更改系统启动选项。按“系统”启动区中的“编辑”按钮编辑 boot.ini 文件，然后添加开关 /SAFEBOOT:DSREPAIR 到行尾，如图 3 所示。（有关 boot.ini 开关的详细信息，请参阅 microsoft.com/technet/ sysinternals/information/bootini.mspx。）
图 3** 设置 DSRM 的启动选项 **(单击该图像获得较大视图)
重新启动服务器时，它将在 DSRM 中出现。请记住，当您要以正常模式重新启动 DC 时，必须从 boot.ini 删除 /SAFEBOOT 开关。
一旦使用 DSRM 密码登录后，就可以再次使用 NTBACKUP 命令还原系统状态备份而无需指定任何参数。（不能从命令行使用 NTBACKUP 还原。）当向导出现时，选择“还原文件和设置”，然后单击“下一步”。然后选择备份文件并选中“系统状态”框，如图 4 所示。
图 4** 使用“备份或还原向导”还原系统状态 **(单击该图像获得较大视图)
如果想在此时启动 DC 返回正常模式，Active Directory 复制进程将把还原的域控制器带回与域中其他 DC 的同步当中，所有还原的数据也将被当前数据覆盖。显然，这不是您的目标。相反地，您需要一种方法将被还原的对象强制复制到域中的其他域控制器。
执行权威还原
NTDSUTIL 还会在备份日期和还原日期之间的每天将每个属性的版本号增加 100,000。除非属性在一天内更新的次数超过 100,000 次（极不可能出现的情形），还原属性的版本号将远大于其他 DC 所持有的版本号，而权威还原的对象将复制到其他 DC。其他从备份非权威还原的对象将最终被其他域控制器的现有数据覆盖。
当完成非权威还原后，但重新启动进入正常模式之前，使用 NTDSUTIL 程序执行要恢复对象的权威还原。无论名称如何，权威还原一个对象并不会“还原”该对象，它只是确保 Active Directory 将对象复制到其他 DC。要做到这一点，NTDSUTIL 将下一个可用的 USN 分配给对象属性的本地 USN。这导致在下一次同步时将对象发送到复制伙伴。要还原单个对象，请确保 DC 以 DSRM 模式启动，并按照如下步骤操作：
- 打开命令窗口，键入：
ntdsutil
- 在 ntdsutil 提示符下键入：
authoritative restore
- 在权威还原提示符下键入：
restore object “<DN of object to be restored>”
- 例如，如果想从 DRNET 域中的 Eng OU 还原 Molly Clark 帐户，需要输入：
restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
- 如果想权威还原整个目录子树（例如一个 OU），则需要如下输入：
restore subtree “OU=Eng,DC=DRNET,DC=com”
- （NTDSUTIL 还提供了一个还原数据库命令用于权威还原整个域以及配置 NC 和架构 NC。还原整个域充满了危险，并且我不建议您使用该选项。如果需要还原整个域，应该还原一个域控制器，然后再次提升域中的其他 DC，如“规划 Active Directory 林恢复”中所述。
- 当提示时，确认权威还原应增加各对象及其属性的版本号。
- 退出 ntdsutil（需要键入 quit 两次）。
- 重新启动 DC 进入正常 Active Directory 模式。
下一次当 DC 与其伙伴进行复制时，将复制您还原的用户。但是还原用户对象只解决了问题的一半。当引入诸如组及其成员之间的对象链接时，情况变得更复杂。在还原期间和还原后可能要面对一些基础问题，在下面的几节我将继续介绍。
首先让我们回顾一下当删除具有后向链接的对象时发生的情形。假设您删除了一个用户对象，它是一个组或多个组的成员。每个具有该用户对象副本的域控制器会将其转换为一个 tombstone 并从链接表中删除所有引用，因而也从用户域中的所有组成员身份删除了该用户对象。（请记住，从组成员身份删除用户不是复制的更改，因为每个 DC 都在本地更新了组成员身份。组成员属性的版本号和本地 USN 保持不变。）短时间之后，将从其他域的链接表中删除幻影对象，再一次不更新组成员属性的复制元数据。
当非权威还原用户域中域控制器上的 DIT 时，将恢复用户对象以及域中组内的所有组成员身份，因此还原的 DC 是本身一致的。当使用 NTDSUTIL 实用程序权威还原用户时，用户对象复制到域中所有其他 DC。
但是因为域中当前组的复制元数据未改变，还原的 DC 上组的成员属性与其他 DC 上组的成员属性不一致。通常情况下没有可以使之聚合的方法。因此，将不会在域中其他 DC 上还原用户的成员身份。
问题：域内的组成员身份未还原
权威还原用户对象不恢复用户的组成员身份。为什么？因为成员身份关系使用组对象的成员属性（前向链接）而非用户的 memberOf 属性（后向链接）进行存储和复制。问题是如何查找用户旧的组成员身份以及在得知其身份后如何正确恢复它们。
Microsoft 对恢复用户组成员身份的进程逐渐进行改良，因此您所使用的技术取决于运行的 Active Directory 版本。下一节主要适用于 Windows 2000 Active Directory。
确定用户旧的组成员身份非常简单：只需在还原的 DC 上检查后向链接属性 — 在这种情况下，是用户对象的 memberOf 属性。memberOf 属性将包含用户域中本地组和全局组的所有成员身份。可以使用 Active Directory 用户和计算机 MMC 管理单元 (ADUC) 或使用 LDIFDE 实用程序（该程序随 Windows Server 附带）列出还原用户的组成员身份。
以下 LDIFDE 命令行将列出 Molly Clark 所属的 DRNET 域中的组，将结果存储在 output.ldf 文件中：
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
请注意，必须使用任何 LDAP 工具启动 DC 进入正常模式，并且再次重申，必须禁用入站复制；否则还原的数据将被覆盖。禁用入站复制最简单的方式是使用 REPADMIN 命令：
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
此处，<dcname> 是正在向其还原的 DC 名称。完成后不要忘记使用 –DISABLE_INBOUND_REPL 重新启用复制。
如果只要恢复几个用户，方法很简单，只需使用 ADUC 手动将用户添加回组。如果要恢复的用户数量较多，可以使用一些工具使某些过程自动化。Microsoft GROUPADD 实用程序（可从 Microsoft 产品支持服务获得）可以接受您创建用来列出用户旧的组成员身份的 LDIF 文件，并依次生成一个重新创建这些成员身份的 LDIF 文件。例如，可以使用此 GROUPADD 命令处理我们在前文示例中为 Molly Clark 创建的 LDIF 文件：
C:\> groupadd /after_restore output.ldf
此命令将以名称 groupadd_<domain>.ldf（其中 <domain> 是将更新其组的域的完全限定域名）为 Molly Clark 在其中具有组成员身份的每个域创建一个新的 LDIF 文件。可以使用如下命令导入上面创建的 LDIF 文件：
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
对于 Windows Server 2003，Microsoft 改进了 NTDSUTIL，利用成员属性中出现的其他元数据支持链接值复制 (LVR)。如果还原的用户对象曾经是域中任何组的成员，而用户的组成员身份使用 LVR 元数据存储，则 NTDSUTIL 将增加成员属性相应值的版本号，从而引起还原的成员身份复制。
Windows Server 2003 SP1 的 NTDSUTIL 版本集成了 GROUPADD 功能，可以在执行用户对象的权威还原时自动创建 LDIF 文件。图 5 所示为一个 NTDSUTIL 新版本，图 6 所示为自动创建的 LDIF 文件的内容。
Figure 6 NTDSUTIL 创建的 LDIF 文件的内容
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
图 5** 内置 GROUPADD 功能的新 NTDSUTIL **(单击该图像获得较大视图)
如果要还原一个包含很多用户和组的整个 OU，手动将用户添加回其所在的组是很麻烦的。恢复还原的组成员身份的另一个方法是权威还原组本身。
但是权威还原组有两个问题。第一个问题是相当明显的：如果还原组，该组中的成员身份将恢复到其在备份时的状态。这意味着自从上一次备份以来所做的所有更改都必须重新应用于该组。第二个问题有些微妙，必须按 Active Directory 复制的方式处理。在权威还原用户和组后，无法确保它们复制的顺序。如果一个组对象在还原的用户对象之前复制到 DC，则复制的域控制器将自动从组删除该用户引用，因为该用户对象尚未存在于该 DC 上。当稍后用户对象复制时，不会将其添加到组。
解决此问题最简单的方法是再对组执行一次权威还原。执行首次权威还原后，重新启动进入正常模式并确保复制正确进行。然后重新启动返回到 DSRM 并运行 NTDSUTIL 执行用户所属组的权威还原。这是为了确保当启动返回到正常模式时，用户对象将在引用它的组对象复制之前完成复制。
问题：其他域内的组成员身份未还原
“此用户属于哪个组”问题实际上比我介绍的更困难。要还原的用户可能同时是本地域和其他域中通用组的成员，而进行非权威还原时，不会还原那些组成员身份。因此您如何得知用户属于其他域中的什么组呢？答案就在全局编录中。除自身域的数据外，全局编录还包含林中其他域数据的只读副本。
要利用全局编录的林范围数据，必须对全局编录执行非权威还原，这意味着您必须以备份全局编录开始。现在，当您运行 LDIFDE 标识用户的组成员身份时，就可以从其他域中找出用户的通用组成员身份。
当您列出要恢复的用户的组成员身份时，连接到全局编录端口 3268 而不是默认的 389，然后指定林的根域作为搜索基准。LDIFDE 将显示恢复的用户的组成员身份，包括其在林中所有域内的通用组中的成员身份。以下是操作方法：
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
如果在全局编录上运行 GROUPADD 或新的 NTDSUTIL，将会生成一个用户域的 LDIF 文件，并为还原用户所属通用组所在的每个域生成一个 LDIF 文件。当导入这些 LDIF 文件时，将还原该用户所有的组成员身份。好了，差不多了 — 接着讨论下一个问题。
问题：恢复其他域中的域本地组成员身份
在 Windows Active Directory 环境中有三种组。全局组只能包含同一个域中的成员，但可以用作其自身域和林中其他域的域本地组内的成员。全局组的成员属性不出现在全局编录中，但这不是问题，因为全局组只能包含来自其自身域的成员。通用组可以包含来自任何域的成员，可以用作林中其他通用组的成员以及用作其自身域和林中其他域的域本地组的成员。通用组的成员属性复制到全局编录。域本地组可以包含来自林中任意域的成员，但不能用作其他域中组的成员。更重要的是，域本地组的成员属性和全局组的成员属性一样，不出现在全局编录中。结果导致恢复其他域中域本地组的用户成员身份很困难。
在 Windows Server 2003 SP1 之前，恢复外部域中域本地组成员身份的唯一方式是在每个域中还原 DC，手动搜索包含该还原用户的所有域本地组的域数据，然后将用户添加回标识的组。在一个拥有众多域的大型环境中，这样会耗时太多。
Windows Server 2003 SP1 版本的 NTDSUTIL 可以帮助处理。当在域控制器上运行 NTDSUTIL 时，该实用程序创建一个包含还原的用户对象的 DN 和 GUID 的文本文件。然后，对于每个外部域，可以非权威还原单个 DC，将该文本文件复制到 DC，然后运行 NTDSUTIL 生成特定于域的新 LDIF 文件，将恢复的用户添加回其所属的域本地组。
要做到这一点，请在每个外部域的 DC 上执行以下步骤：
- 启动外部域中的 DC 进入 DSRM。
- 使用 NTBACKUP 还原包含还原用户的组成员身份的 DIT 副本。
- 将 NTDSUTIL 创建的 .txt 文件复制到当前 DC。
- 打开命令窗口，键入 ntdsutil。
- 键入 authoritative restore。
- 键入 create LDIF file(s) from <file name>（其中，<file name> 是文本文件的名称）。
- 键入 quit 两次以退出 ntdsutil。
- 重新启动 DC 进入正常 Active Directory 模式。
- 键入 ldifde –i –f <ldif filename>（其中，<ldif filename> 是刚才创建的 LDIF 文件的名称）。
现在，您已经还原了所有删除用户的组成员身份。
循序渐进
恢复 Active Directory 用户及其组成员身份（尤其是在一个多域环境中）是很复杂的。正确恢复组成员身份所需的具体步骤取决于运行的 Windows 版本。
如果运行的是 Windows 2003 SP1，则需要采取如下步骤：
- 启动 GC 进入 DSRM 并使用包含删除用户的备份执行系统状态还原。
- 使用 NTDSUTIL 执行已删除用户的权威还原。NTDSUTIL 将创建一个包含还原对象 DN 和 GUID 的文本文件以及一个或多个 LDIF 文件来还原用户的组成员身份。
- 使用 LDIFDE –i –f <LDIF filename>（其中，<LDIF filename> 是步骤 2 中创建的 LDIF 文件的名称）将组成员身份导入当前域和其他域。
- 重新启动全局编录进入正常模式。
- 在每个外部域的 DC 上，启动进入 DSRM 并使用包含还原用户的组成员身份的备份执行系统状态还原。
- 使用创建 ldif 文件命令运行 NTDSUTIL。
- 重新启动 DC 进入正常模式。
- 使用 LDIFDE –i –f <filename>（其中，<filename> 是在步骤 6 中创建的 LDIF 文件的名称）还原外部域中的组成员身份。
- 此时可以选择使用 REPADMIN /syncall 强制复制。
如果运行的 Windows Server 2003 版本没有安装 SP1 或运行的是 Windows 2000，将涉及到其他一些步骤。由于 NTDSUTIL 的较旧版本不创建 LDIF 文件，因此可以使用 GROUPADD 实用程序来创建它们。步骤如下：
- 启动全局编录进入 DSRM 并使用包含删除用户的备份执行系统状态还原。
- 禁用 NIC 或拔掉电缆阻止入站复制。
- 重新启动全局编录进入正常模式。
- 使用 LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf 使用可分辨名称 <dn> 转储用户的成员身份。
- 使用 GROUPADD /after_restore membership.ldf 创建 LDIF 文件。
- 使用 LDIFDE –i –f <filename>（其中，<LDIF filename> 是步骤 5 中 GROUPADD 创建的 LDIF 文件的名称）将组成员身份导入当前域和其他域。
- 使用 REPADMIN /options <dcname> -DISABLE_INBOUND_REPL 重新启用入站复制。
- 在每个外部域的 DC 上，启动进入 DSRM 并使用包含还原用户的组成员身份的备份执行系统状态还原。
- 重新启动 DC 进入正常模式。
- 使用 LDIFDE –i –f <filename>（其中，<filename> 是步骤 5 中 GROUPADD 创建的 LDIF 文件的名称）还原外部域中的组成员身份。
- 此时可以选择使用 REPADMIN /syncall 强制复制。
现在，对早于 Windows Server 2003 SP1 的环境唯一剩下的事就是恢复还原用户的外部域本地组成员身份。唯一的选择就是手动还原域本地组成员身份或从备份还原 DC 并权威还原域本地组。
总结
虽然很容易从 Active Directory 意外删除用户甚至 OU，但正确恢复删除的用户及其组成员身份可能惊人地复杂、耗时并且容易出错。要确保从这类灾难中尽可能快地恢复，必须理解对象链接、复制、删除和权威还原的结构。
您认为您在产品环境中首次尝试此操作时能正确完成所有步骤吗？为了确保下一次不得不恢复 CEO 的用户对象时有所准备，最好制订恢复删除对象的书面计划。并确保在将该计划用于实际数据之前至少练习一两次。您的老板（和 CEO）将会对此非常感激。
其他资源
Gil Kirkpatrick 是 NetPro 的 CTO，自 1996 起便一直参与开发 Active Directory 软件。他与来自 HP 的 Guido Grillenmeier 一起创办了广受欢迎的 Active Directory 灾难恢复研讨会。Gil 也是“Directory 专家大会”的创始人 (www.dec2007.com)。
© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.