Active Directory灾难恢复详解一

系统 Windows
本文介绍了因为意外删除数据而导致 Active Directory 失败,而进行的Active Directory的恢复。

Active Directory的重要性对于系统管理员来说是不言而喻的,下面就介绍了有关Active Directory进行灾难恢复的相关内容。

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 组的成员。

这些链接称为前向链接。类似地,Active Directory 还提供了后向链接属性。这为从链接指向的对象返回到引用链接的对象提供了引用,意味着该对象具有前向链接。用户和组的 memberOf 属性是后向链接属性的一个例子。属性 Schema 对象描述了一个后向链接属性,该属性具有 linkID 值,其值比相应的前向链接属性以偶数编号的 linkID 值大 1。 例如,Windows Server® 2003 R2 架构中成员属性的 linkID 值为 2,作为后向链接的 memberOf 属性的 linkID 值为 3。有关详细信息,图 2 提供了一个默认情况下 Windows Server 2003 R2 架构中定义的链接属性列表。

后向链接属性总是多值的,由 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>&rdquo

此处,<filename> 是要创建的备份文件的名称,应使用 .bkf 扩展名。

欲知更多内容,请点击Active Directory灾难恢复详解二

【编辑推荐】

  1. Active Directory之目录服务
  2. Active Directory迁移工具ADMT
  3. Exchange版本转换基于Active Directory路由
  4. 如何实现Active Directory到Lotus Domino迁移?
  5. Windows Server 2008 Active Directory域服务安装
责任编辑:韩亚珊 来源: 互联网
相关推荐

2011-07-22 17:14:38

Active Dire

2011-07-22 16:51:28

Active Dire

2011-07-22 15:23:55

Active Dire备份

2010-11-01 05:54:41

2011-07-13 16:55:30

Active Dire组策略

2011-07-19 10:09:07

Active Dire回收站

2010-12-23 16:09:48

Active Dire

2011-07-15 10:01:02

Active DireADMT

2011-07-22 15:20:37

Active Dire备份

2011-07-22 15:19:29

Active Dire恢复

2011-07-12 13:26:41

Active Dire

2012-09-17 11:25:32

IBMdw

2012-02-06 09:58:48

2010-06-03 11:35:18

2012-02-23 10:29:45

Microsoft云计算微软

2018-04-18 10:28:15

数据中心灾难恢复DR

2011-07-13 17:48:08

2019-11-06 11:20:39

灾难恢复策略测试

2011-07-22 15:02:15

Active Dire

2011-07-13 17:32:59

点赞
收藏

51CTO技术栈公众号