域控管理员帐户架构扩展

AD帐户分类入门

AD中的内置管理模型存在非常高的风险，它允许将Domain Admins和其他敏感帐户暴露给当今大多数企业网络中——比如允许登录到工作站和其他客户端成员计算机,默认情况下这导致未启动者在高度特权的帐户和不受信任的资产之间使用各种不适当的联系点。

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

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

锁定模式！

另一方面，我们可以找到Microsoft的 Active Directory管理层模型

以最极端的形式，此3层模型是通过专用且经过适当加固的管理林（通常称为Red Forest或ESEA-增强安全管理环境）实施的，但也可以直接在单个林不仅可以在服务器和工作站之间提供适当的隔离，而且还可以将核心身份管理与应用程序基础结构隔离开来。

管理员帐户

想象一下，您遵循了以上所有建议-为所有支持人员提供了单独的管理员帐户，到目前为止，另一个问题: 管理员帐户生命周期管理

谁会记得当您的一位管理员离开公司时检查相关的管理员帐户？

使用属于同一人的所有这些帐户时，您可能会遇到的另一个问题是，对来自管理帐户的可疑或异常活动进行分类时的身份关联。

假设，如果某个Domain Admin帐户在凌晨3:45突然删除目录中的一堆对象并开始更改人员密码-您可能要与实际员工联系并要求他们确认是否是故意的-因此自动将管理员帐户的身份转换为关联的常规用户帐户的功能可能很重要。 这给我们留下了两个我们需要能够回答的问题：

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

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

我已经看到了许多通过比较用户名来进行此操作的尝试，希望该组织的（通常是非强制性的）命名约定可以节省一天的时间，而且我也看到了几乎相同的失败案例。我们需要一种更强大的解决方案…

架构扩展

换句话说，我们需要某种方式在Active Directory中 保持 用户帐户对象之间 的一对多关系 。听起来有点熟？

碰巧的是，Active Directory已经具有许多完全以这种方式起作用的属性。我想到的第一个示例是manager/directReports-这些就是我们所说的 link-value属性。当manager属性上的帐户设置为一个值X，该directReports由所标识的对象的属性上X会自动反映已更新的帐户的价值。我们将第一个属性（manager）称为该对的前向链接属性，而第二个属性（directReports）是反向链接。

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

在架构中创建一对链接的属性

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

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

attributeSchema

简而言之，Active Directory中的每个对象都包含一个内部的，特定于副本的标识（a DNT）以及许多可能带有或不带有值的属性。每个属性的行为又由attributeSchemaSchema命名上下文中的对象限制。如果要扩展Active Directory的行为，则需要添加一些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

… oMSyntax值127

… attributeSyntax值为2.5.5.1

oMSyntax 的值127表示属性值是一个对象引用，并且attributeSyntax2.5.5.1手段LDAP将使用专有名称来表示对象的引用。

上面输出中的另一个兴趣点是boolean isSingleValued。鉴于我们有兴趣建立 一对多 关系，因此将管理员帐户绑定到其主要所有者的前向链接也应为单值，而后向链接则必须为多值。

注意：member/memberOf是一个链接属性对的示例，其中两个链接都是多值的-因为它们旨在表示 多对多 关系

linkID正向链接和反向链接由值配对-正向链接具有偶linkID数值，并且它们对应的反向链接属性将具有相同的值+1。在上面的示例中，manager其linkID值为42，并且足够确定：

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

我们可以选择一些偶数，例如31706，然后将31707分配给backlink属性-这可能会起作用-但是我们冒着获取Microsoft可能在将来的模式更新中使用的ID的风险。我们将陷入困境。

从Windows Server 2003开始，Active Directory linkID通过执行以下操作来支持通过魔术OID 自动生成随机对：

创建linkID值为的前向链接1.2.840.113556.1.2.50

重新加载架构并检索生成的链接

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

剩下的就交给 AD 去做,我们需要提供的其他唯一标识符是这些attributeID值的OID 。如果您的组织已经分配了ISO OID，则需要使用它的扩展名-但是，如果没有，Microsoft将 提供有关如何生成 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属性可用于发现与某个帐户关联的管理员帐户。

classSchema

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

因此，我们的下一步是创建这样的类：

# 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具有两个单独的管理员帐户：

他的Ultra Admin帐户john-ua，用于第0层管理

他的Infra Admin帐户john-ia，用于1级管理

为了使用我们的新属性建立正确的关系，我们可以使用熟悉的工具，例如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

这种连接身份的方法（看似复杂）的真正价值在于它的健壮性和灵活性。所涉及的任何帐户都可以更改其所有其他属性，更新用户名或在目录中移动，而无需破坏我们现在创建的绑定！

我已经在下面的实验室中发布了用于创建此架构扩展 的完整脚本， 如果有人想尝试一下，看看它是否对管理员帐户生命周期管理有帮助:)

*参考来源： iisreset ，FB小编周大涛编译，转载请注明来自FreeBuf.COM