活动目录的最佳管理模型规定了某种程度的帐户隔离——至少对于任何拥有敏感成员身份的用户组，如域管理员组——在某些情况下，甚至可能需要每个管理员拥有多个管理员帐户，如微软的分层管理模型。 但是，为了生命周期管理的目的，例如... ... ，我们如何跟踪这些帐户的关系呢？ 今天，让我们来看一下活动目录模式的扩展，它可能会有所帮助！

活动目录帐户分类入门

活动目录中的内置管理模型存在非常高的风险，它允许将域管理员和其他敏感帐户暴露给当今大多数企业网络中的凭据窃取行为——比如允许登录到工作站和其他客户端成员计算机，而这些计算机在默认情况下可能已经被入侵了。这就导致了外行人在拥有高度特权的账户和不受信任的资产之间使用各种不适当的接触点。

因此，为了保护你的AD环境，你可以(也应该)采取的最基本的步骤之一就是建立某种形式的帐户隔离。

可以简单地向管理员提供一个可以分配管理特权的额外帐户。 这个管理员帐户，反过来，不应该用于日常任务，如阅读电子邮件或浏览互联网。 这种模式在规模较小的操作中非常普遍(有时非常适合) ，在这些操作中，帮助台 / 系统管理员的责任由相同的员工共同承担。

锁定模式

另一方面，我们发现了微软的活动目录管理层模型。

在它最极端的形式中，这个三层模型是通过专用的、经过适当加固的管理林(俗称“ Red Forest”或 ESEA -- Enhanced Security Administrative Environment)实施的，但它也可以直接在单个林中实现，以便不仅在服务器和工作站之间提供适当的隔离，而且将核心身份管理与应用程序基础设施隔离开来。

我强烈建议任何参与保护、设计或管理活动目录的人熟悉分层模型的概念和原则，尤其是0层等效的概念。

管理员账户遍布各地

假设你已经遵循了上面的所有建议——为所有支持人员提供了单独的管理帐户，目前为止一切正常。 现在，突然之间，你意识到所有这些增加的复杂性给你带来了另一个问题: 管理员帐户生命周期管理。

· 当你的管理员离开公司时，谁会记得检查(并禁用)相关的管理帐户呢?

另一个你可能会遇到的问题是，在对源自管理账户的可疑或异常活动进行分类时，所有这些账户都属于同一个人。

比如说，如果一个域管理员账户在凌晨3:45突然删除了目录中的一大堆对象，并开始更改用户的密码——你可能想要联系实际掌管此账户的员工并要求他们确认这是否是有意的——所以自动将管理员账户的身份转换为相关的常规用户账户的能力可能非常重要。 这就给我们留下了两个需要回答的问题:

· 给定一个管理帐户的标识，返回相关联的用户

· 给定一个用户的身份，返回任何相关的管理员帐户

我见过很多通过比较用户名来实现这一点的尝试，希望组织(通常不强制执行)的命名约定能够挽救局面(“ john-admin 可能属于 john”) ，我也见过几乎同样多的失败案例。 我们需要一个更强有力的方法来解决这个问题。

模式扩展

换句话说，我们需要某种方法来持久化活动目录中用户帐户对象之间的一对多关系。 听起来很熟悉吧？

事实上，活动目录已经有许多属性正是以这种方式工作的。 我们想到的第一个例子是 manager / directreports ——我们称之为 link-value 属性。 当帐户上的 manager 属性设置为 x 值时，x 标识的对象上的 directReports 属性将自动反映更新的帐户的值。 我们将第一个属性(manager)称为这对的前向链接属性，而第二个属性(directReports)是反向链接。

我们可以利用这个机制，通过3个简单的步骤来创建我们自己的映射:

· 在模式中创建一对链接属性

· 创建一个可能包含属性的辅助类

· 将辅助类与现有的 user 对象类关联

属性模式

简单地说，活动目录中的每个对象都由一个内部的、特定于副本的标识(DNT)和一些可能具有值或不具有值的属性组成。 每个属性的行为依次由 Schema 命名上下文中的 attributeSchema 对象绑定。 如果我们想要扩展活动目录的行为，我们需要添加一些attributeSchema！

考虑到这一点，我们首先来看一下 manager 属性的模式定义：

# Discover the schema container
$rootDSE = Get-ADRootDSE
$schemaNC = $rootDSE.schemaNamingContext
# Discover schema master
$schemaMaster = Get-ADObject $schemaNC -Properties fSMORoleOwner | Get-ADDomainController -Identity { $_.fSMORoleOwner }
# Retrieve the 'manager' attribute
Get-ADObject -Filter 'Name -eq "manager"' -SearchBase $schemaNC -Properties *
adminDisplayName                : Manager
attributeID                     : 0.9.2342.19200300.100.1.10
attributeSyntax                 : 2.5.5.1
DistinguishedName               : CN=Manager,CN=Schema,CN=Configuration,DC=corp,DC=iisreset,DC=me
isMemberOfPartialAttributeSet   : True
isSingleValued                  : True
lDAPDisplayName                 : manager
linkID                          : 42
Name                            : Manager
ObjectClass                     : attributeSchema
oMSyntax                        : 127

在上面的输出中，我只列出了属性的一个子集，但本质上包含了我们需要的所有东西，特别是：

· 我们需要创建一个attributeSchema 对象的名称以及

· ... 一个 linkID

· ... 一个attributeID

· ... 一个值为127的 oMSyntax

· ... 一个值为2.5.5.1的attributeSyntax

oMSyntax 的值127表示属性值是一个对象引用，attributeSyntax的值 2.5.5.1表示 LDAP 将使用可分辨名称来表示对象引用。

上面的输出中另一个有趣的地方是布尔值 isSingleValued。 鉴于我们对建立一对多关系感兴趣，我们将管理员帐户与其主要所有者绑定回来的前向链接也应该是单值的，而反向链接必须是多值的。

注意: member/memberof 是链接属性对的一个示例，其中两个链接都是多值的，因为它们是用来表示多对多关系的。

正向链接和反向链接由 linkID 值配对——正向链接甚至有 linkID值，它们相应的反向链接属性将有相同的值+ 1。在上面的例子中，manager的linkID值为42，可以肯定的是：

PS C:\> Get-ADObject -Filter 'linkID -eq 43' -SearchBase $schemaNC |% ldapDisplayName
directReports

我们可以选择一个偶数，例如31706，然后将31707赋给反向链接属性——这可能会有用——但是我们冒着获取一个 ID 的风险，这个 ID 可能会被微软在未来的模式更新中使用，那时我们就有大麻烦了。

自 Windows Server 2003以来，活动目录支持通过一个神奇的 OID 自动生成一个随机 linkID 对，方法如下:

· 使用linkID 值为1.2.840.113556.1.2.50创建前向链接

· 重新加载模式并检索生成的链接

· 使用前向链接的 attributeID 的 linkID 值创建后向链接

剩下的就交给 AD 去做。

我们需要提供的其他唯一标识符是 attributeID 值的 OID。 如果你的组织已经分配了 ISO OID，那么你将希望使用该扩展——但是如果没有，微软提供了如何生成 ISO OID 的指导。

最后，一个最佳实践建议: 在你的模式名称中添加公司特定的前缀，以避免与其他应用程序或基本模式发生排序！ 下面我将使用前缀 iRM 作为 IISResetMe 的简写。

有了这些，现在就让我们开始吧！

# Forward-link attribute to indicate the owner of a non-primary account
$fwdAttrName   = "${orgPrefix}-sourceAccount"
$fwdAttrSchema = New-ADObject -Name $fwdAttrName -Type attributeSchema -OtherAttributes @{
    adminDisplayName              = $fwdAttrName
    lDAPDisplayName               = $fwdAttrName
    oMSyntax                      = 127
    attributeSyntax               = "2.5.5.1"
    attributeID                   = "${orgOID}.1"
    isSingleValued                = $true
    isMemberOfPartialAttributeSet = $true
    adminDescription              = "Account owner"
    instanceType                  = 4
    linkID                        = '1.2.840.113556.1.2.50'
    showInAdvancedViewOnly        = $false
} -Server $schemaMaster -PassThru
# Refresh the schema
$rootDSE.Put('schemaUpdateNow', 1)
$rootDSE.SetInfo()

好了，这就是我们的前向链接，sourceAccount属性——它将用于指示谁是管理帐户的真正所有者。

接下来是反向链接：

$bckAttrName   = "${orgPrefix}-adminAccounts"
$bckAttrSchema = New-ADObject -Name $bckAttrName -Type attributeSchema -OtherAttributes @{
    adminDisplayName              = $bckAttrName
    lDAPDisplayName               = $bckAttrName
    oMSyntax                      = 127
    attributeSyntax               = "2.5.5.1"
    attributeID                   = "${orgOID}.2"
    isSingleValued                = $false
    isMemberOfPartialAttributeSet = $true
    adminDescription              = "Associated admin accounts"
    instanceType                  = 4
    showInAdvancedViewOnly        = $false
    linkID                        = $fwdAttrSchema.attributeID
} -Server $schemaMaster -PassThru
# Refresh the schema
$rootDSE.Put('schemaUpdateNow', 1)
$rootDSE.SetInfo()

这就是我们的反向链接，adminAccounts 属性，它可以用来发现与一个帐户相关联的管理帐户。

类模式

现在，这里的最终目标是将属性对与用户对象类关联起来——但是与其直接修改用户类可以包含的属性集，推荐的扩展基本模式数据类型的方法是创建一个辅助类，并使用该类通过一组行为扩展现有类型。

基于这个原因，我们的下一步是创建这样的一个类：

# Auxiliary class that may contain our attributes
$auxClassName   = "${orgPrefix}-adminAccountExtensions"
$auxClassSchema = New-ADObject -Name $auxClassName -Type classSchema -OtherAttributes @{
    adminDisplayName    = $auxClassName
    lDAPDisplayName     = $auxClassName
    governsID           = "${orgOID}.3"
    mayContain          = @(
        $fwdAttributeSchema.attributeID
        $bckAttributeSchema.attributeID
    )
    objectClassCategory = '3'
    adminDescription    = 'This class adds optional admin account relationship links to user account objects'
    subClassOf          = 'top'
} -Server $schemaNC -PassThru
# Refresh the schema
$rootDSE.Put('schemaUpdateNow', 1)
$rootDSE.SetInfo()

这里有几点需要注意：

· governsID 是一个类模式标识符，等价于attributeID

· objectClassCategory = 3 意思是”这是一个辅助类”

· 我们打算扩展user 的行为，但我们不是从它继承(因此subClassOf = top)

最后，我们需要为最后一次操作再次刷新模式——将它们绑在一起：

$userClass = Get-ADObject -SearchBase $schemaNC -Filter "Name -like 'user'"
$userClass |Set-ADObject -Add @{
  # add our new auxiliary class to 'user'
  auxiliaryClass = $auxClassSchema.governsID
} -Server $schemaMaster

我们的辅助类模式如 AD 模式 MMC 管理单元所示：

让我们看看如何操作

在我的测试环境中，用户 john 有两个独立的管理帐户：

· 他的“超级管理”账户,john-ua, 是第0级管理

· 他的“管理下属”账户,john-ia,是第一级管理

为了使用我们的新属性建立正确的关系，我们可以使用熟悉的工具，比如 ADAC、 dsa.msc 或者——更好的是——老的 Set-ADUser：

$john = Get-ADUser john
foreach($admin in 'john-ua','john-ia'){
    Set-ADUser $admin -Replace @{ 'iRM-sourceAccount' = $john.distinguishedName }
}

接下来，你需要在创建管理帐户期间填充初始关系，所以不要忘记更新配置脚本！

现在这些账户已经正确链接，让我们重新回顾一下我之前提出的问题:

· 给定一个管理帐户的标识，返回相关联的用户

好吧，现在我们可以直接在对象上获得这些信息，这就变得简单了：

PS C:\> $johnIA = Get-ADUser john-ia -Properties iRM-sourceAccount
PS C:\> $johnIA |Get-ADUser -Identity { $_.'iRM-sourceAccount' }

漂亮! 但是反过来呢？

· 给定一个用户的身份，返回任何相关的管理员帐户

非常好——给出源帐户上的反向链接，几乎是微不足道的事情！

PS C:\> $john = Get-ADUser john-ia -Properties iRM-adminAccounts
PS C:\> $john.'iRM-adminAccounts' |Get-ADUser

这种看似复杂的链接身份的方法的真正价值在于它的健壮性和灵活性。 任何涉及到的帐户都可以改变它们的其他属性，更新用户名或者在目录中移动而不会破坏我们现在创建的这种联系！

如果有人想试用这个模式扩展，我已经在我的实验室中发布了用于创建这个模式扩展的完整脚本，看看它是否有助于你执行管理员帐户生命周期管理。

本文翻译自：https://blog.iisreset.me/admin-account-schema-extensions/如若转载，请注明原文地址：