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

相關文章