关联的 Active Directory 关联属性是一种特殊类型的 Active Directory 属性,用于描述对象之间的关系。本文将解释什么是关联属性,以及它们如何工作。
精选相关内容:
是什么让某个属性成为已关联的属性(linked attribute)?
Active Directory 中的每个属性都由 Active Directory 架构分区中的 AttributeSchema 对象来定义。用于定义已关联属性(linked attributes)的 AttributeSchema 对象,是唯一具备已填充的 LinkID 属性的架构对象。因此,在域中识别所有已关联属性就像使用 PowerShell 一样简单:在架构中搜索 LinkID 已填充的对象,如下所示:
Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -LDAPFilter "(LinkID=*)"
已关联的属性(linked attributes)通常以一对形式存在:前向链接(forward link)和后向链接(back link)。其中,前后链接由 LinkID 属性的值来定义:
- 前向链接(forward link)— LinkID 的值始终为正的 偶数 整数。
- 后向链接(back link)— LinkID 的值始终为正的 奇数 整数;事实上,它等于对应前向链接(forward link)的 LinkID 值加 1。
LinkID 值最小的属性是 Member 属性和 MemberOf 属性,它们用于跟踪 Active Directory 中的组成员关系。因此,让我们修改 PowerShell 脚本,仅将输出限制为这两个属性:
输出结果会告诉我们关于这两个属性的一些重要信息:
- Member 属性的 LinkID 值为 2,是一个偶数。这意味着 Member 属性是正向链接(forward link)。
- MemberOf 属性的 LinkID 值为 3,是一个奇数。这意味着 MemberOf 属性是反向链接(back link)。
- 反向链接(back link)MemberOf 的 LinkID 值等于正向链接(forward link)Member 属性的 LinkID 值加 1(3 = 2 + 1)。这意味着 Member 属性和 MemberOf 属性是关联的链接属性(associated linked attributes)。
可以使用一个略有不同的 PowerShell 脚本,直接检索链接特性所关联的正向链接或反向链接的名称,不过它并不会明确告诉你该特性是正向链接还是反向链接。你需要查看 LinkID 的值,并自行判断。
Active Directory 的链接属性如何工作?
既然我们已经明确了链接属性是什么,以及如何识别它们,那么接下来就该探索它们的行为了。
链接属性存储的是两个对象之间关系的信息;而传统的 Active Directory 属性则存储的是关于某个对象的信息。正是这种功能差异反映在 Active Directory 会以不同于其他属性的方式来存储链接属性的值。
链接属性如何被存储
Active Directory 数据存储在 ntds.dit 数据库文件中。常规属性的值存储在一个名为 datatable 的表中。关联(Linked)属性拥有各自专用的表,即恰如其名的 link_table 。如果我们查看一下我的实验室的 ntds.dit 数据库文件快照,就可以看到 Active Directory 如何存储关联的属性值:
link_table 中的对象引用使用的是对象的 distinguished name 标记(DNT)。它实际上是 ntds.dit datatable 中记录的内部主键。这样可以避免对象的 distinguished name 发生更改时,必须更新任何相关的 link_table 条目。
截图突出显示了 link_table 中的三个重要字段:
- link_DNT — 对前向链接对象的引用。
- backlink_DN — 对关联的反向链接对象的引用。
- link_base — 指向前向链接属性的 LinkID 的引用。此字段使用前向链接的 LinkID 值来标识正在跟踪的两个对象之间的关系(不过,如你在截图中看到的那样,表中的数值实际上是 LinkID 值除以 2 得到的结果)。
以这种方式存储已链接属性的实际影响
尽管这种存储方式看起来有点奇怪,但它是一种非常巧妙的设计,会带来一些重要的实际影响:
- 前向链接的数值会被存储;后向链接的数值则会被构建出来。 这很容易就是从这段讨论中最重要的要点: 后向链接实际上并不存储信息。 由于两个对象之间的关联是一个单一实体,Active Directory 不需要存储一个以上的关联副本。当查询前向链接时,Active Directory 只需返回那些满足条件的 link_table 项:被查询对象的 DNT 与 link_DNT 字段中的值匹配,且前向链接的 LinkID 与 link_base 字段中的值匹配。 当查询后向链接时,Active Directory 可以通过返回那些满足条件的 link_table 项来计算其数值:被查询对象的 DNT 与 backlink_DNT 字段中的值匹配,且关联的前向链接的 LinkID(通过从后向链接的 LinkID 中减去 1 得到)与 link_base 字段中的值匹配。
- 前向链接的数值是可写的;后向链接的数值是只读的。 一旦你知道 Active Directory 只存储前向链接的数值,这一点大概就显得很明显了。不过它带来了一个重要的影响:当链接的属性被修改时,Active Directory 会更新前向链接,从而修改拥有该链接的对象。由于后向链接持有的是构建出来的只读值,它永远无法被修改,因此拥有后向链接的对象 拥有 也不会被修改。
为了说明这点为何重要,让我们考虑将用户添加到组中。此更新只会修改组的 Member 属性;用户的 MemberOf 属性不会被修改。由于组对象发生了实质性变化,反映该变化的元数据字段(例如 “ModifyTimeStamp” 和 “WhenChanged” 属性)会被更新。这些相同的元数据字段 不会 在用户对象上被更新。原因是:尽管它的 MemberOf 属性现在将返回不同的值,但 MemberOf 属性本身并没有被修改。 - 前向链接是必需的;后向链接是可选的。 有些关于链接属性(linked attributes)的文章指出,链接属性总是同时具有前向链接和后向链接。虽然这在很多情况下确实如此,但后向链接的存在并不是严格必需。事实上,如果我们使用 PowerShell 来检索链接属性对(linked attribute pairs),就可以看到我实验环境中的并非每一个前向链接都对应一个后向链接:
采用这种方式存储链接属性的好处
还记得我提到过,链接属性的存储方式有点“高明”吗?Active Directory 对链接属性值的存储方式实际上带来了两个非常关键的好处。
首先,只存储前向链接值,并用它们来计算对应的后向链接值,可以减少 Active Directory database 的规模。
另一个关键好处(相对不那么显而易见)来自这样一个事实:Active Directory 会将每个关联(association)单独存储。由于前向链接(forward link)的每个关联都在 link_table 中有各自的条目,因此每个条目都可以维护自己的更新序列号(Update Sequence Number,USN)。这种行为称为 Linked Value Replication(LVR),它使 Active Directory 能够独立复制每一个具体关联。 例如,如果你将一个用户添加到已有 100 个成员的组中,那么只会复制新添加用户对应的条目。这样可以显著减少为将对链接属性(linked attributes)的更改传播出去所需要的复制量。
补充事实
在把这一切都讲完之前,还有一种值得提及的行为:在未启用 AD Recycle Bin 的情况下,从被删除的对象中会移除已关联的属性值。当删除了具有已关联属性的对象时,即使 Active Directory 会在一段时间内以 tombstone 的形式保留该对象本身,与之关联的 link_table 条目也会一并被删除。启用 Active Directory Recycle Bin 会改变这种行为,并在被删除对象的 tombstone 期间保留相关的 link_table 条目。
结论
由于 Active Directory 的已关联属性与其他 Active Directory 属性的存储方式不同,因此它们的行为也不同。尤其是 back link(反向链接)属性更是如此。如果你只能从本文中带走一件事,那就应当是:back link 属于“构建型(constructed)属性”。它们的值并不会被直接存储,因此在很大程度上(尤其是在更新方面)它们确实不会像其他属性那样工作。为了保持一致的用户体验,Active Directory 通常会很好地隐藏其后端行为,但理解这些关于属性及其后果的底层差异,可以避免问题。
Netwrix 如何提供帮助
使用 Netwrix Active Directory security solution 从端到端保护您的 Active Directory。Netwrix Active Directory security solution 它将使您能够:
- 识别 Active Directory 中的安全风险,并优先安排您的缓解工作。
- 加强整个 IT 基础架构中的安全配置。
- 及时检测并遏制甚至是高级威胁,例如 DCSync 和 Golden Ticket 攻击。
- 借助自动化响应选项,对已知威胁实现即时响应。
通过快速的 Active Directory 恢复,将业务中断降到最低。
分享到
了解更多
关于作者
Joe Dibley
安全研究员
Netwrix 的安全研究员,并且是 Netwrix Security Research Team 的成员。Joe 是 Active Directory、Windows 以及各类企业软件平台与技术方面的专家;他/她研究新的安全风险、复杂的攻击技术,以及相应的缓解措施与检测方法。