Windows 系統管理

在 Active Directory 中委派權限

Joel Yoker and Rob Campbell

摘要:

• 定義系統管理角色
• 開發 OU 和安全性群組模型
• 使用次要帳戶
• 委派權限的工具

Active Directory 中的委派功能相當強大，不但可以解決一些安全性問題，而且能夠簡化管理工作。藉由在 Active

Directory® 內適當地委派權限，您可以在環境中強制執行指定的角色、限制管理錯誤發生的可能性及其帶來的影響，以及在整個基礎結構中套用最低權限的原則。然而，還有許多依賴 Active Directory 的組織尚未感受到委派的強大功能。在某種程度上，這是因為開發適合您企業的 Active Directory 委派模型表面上看起來好像很複雜。若要開發一個符合您組織獨特需求的委派模型的確有困難之處，但其實有一些非常簡單的模型只要稍加修改，就可以套用到大部分 IT 基礎結構中。

雖然每一個環境都有某方面的不同，實際上大部分的大型企業在許多方面是類似的，而且也都面臨相同的 IT 挑戰。例如，許多組織劃分成幾個地理區域，由不同的 IT 工程小組或作業支援小組發展而成，而且都有獨立的業務單位。許多大型組織也必須處理權限提升、服務帳戶濫用以及「信任」之類的問題。

「信任」是一個很有趣的詞彙，它往往變成擁有多個 Active Directory 樹系的理由。信任問題常肇因於一個部門或地區對另一個部門或地區之系統可用性的影響能力。位於不同地區的組織單位之間往往會有不同的技術層級，而缺乏對特定系統的深層認知，導致無法支援特定的地區或業務單位，也是很常見的。因此，公司的各個部門通常都不願意將其管理權限轉讓給中央單位。

同時，在任何 Active Directory 實作中，系統管理員必須對使用 Active Directory 基礎結構的應用程式定義參與規則。只可惜通常在應用程式安裝指南中引用的一般方法是將服務帳戶設定成 Domain Admins 群組的成員。此方法的問題在於服務帳戶基本上就是通用帳戶。如果對這些帳戶授與網域系統管理員權限，則會對 IT 環境造成重大的威脅。這些服務帳戶容易遭到惡意或粗心的系統管理員不當使用，也有可能遭受在應用程式內引發基礎安全性問題的攻擊者所利用。

這些困難似乎無法克服，它們代表了實作 Active Directory 委派模型的最佳案例。開發委派模型是一種反覆的設計流程，建議您遵循下列步驟進行：

1. 定義組織內的 IT 系統管理角色。
2. 開發組織單位 (OU) 和安全性群組模型。
3. 建立 IT 系統管理員的次要帳戶。
4. 委派權限。

現在就來看看這些步驟的細節。

定義角色

角色定義流程的第一步是徹底了解服務管理和資料管理。這些概念是任何 Active Directory 委派模型的基石。

服務管理的核心是管理關鍵目錄服務基礎結構元件，例如 Exchange 伺服器和網域控制站。資料管理則是管理物件，例如位於這些服務內的信箱和使用者帳戶。在 Active Directory 的範圍內，服務管理員最後負責傳遞目錄服務並確保其可用性，而資料管理員則負責管理使用者和伺服器帳戶、群組以及其他網域資源。

Active Directory 支援透過組織單位 (OU) 進行細微的權限委派。您可以經常修改 OU 來提供現有目錄服務或網域模型內適用於系統管理員的相同權限等級。但務必了解某些功能根本無法委派，且必須由單一受信任群組或實體加以管理。

工作分析也很重要。您必須知道系統管理員執行哪些 Active Directory 工作，以及這些工作如何對應至角色。例如，Active Directory 站台建立是屬於服務管理工作，而安全性群組成員資格的修改通常是屬於資料管理工作。每一個工作的頻率、重要性及難易度都應該加以評估。這些是工作定義的重要部分，因為它們對於是否應該委派權限具有決定性的影響。例行工作的風險有限且容易完成，是很好的委派對象。相反地，很少執行的工作對組織有重大影響，且需要較高技術層級，不是好的委派對象。提升權限 (暫時將帳戶提升至必要的角色或重新指派工作) 反而才是這些工作的正確途徑。

由於大型組織的許多特性相似，因此可以放心假設一般委派模型可供實作。基於本文的目的，我們將在遵守組織界限及嘗試減少信任問題方面 (例如針對網域控制站之類的泛企業資產的可用性)，提供一組啟用管理功能的範例角色。請注意，此模型只是一個範例，雖然它對於組織內的角色討論是一個很好的開始，但請不要將這份指引照單全收。

Active Directory 已定義一些角色，但某些角色必須重頭開始建立，才能完成委派模型。適合許多大型 Active Directory 環境的一組範例角色包括：Enterprise Admins、Domain Admins 和 Tier4 Admins (適用於服務管理)，以及 Tier3 Admins、Regional Admins、Tier2 Admins 和 Tier1 Admins (適用於資料管理)。如需這些角色及其責任的清單，請參閱 [圖 1]。

Figure 1 定義角色和責任

服務管理員

現在就來看看服務管理員角色的細節。服務管理員管理重要的基礎結構元件，而屬於這一類的所有系統管理員都具有高度權限。因此，在此情況下極力建議使用最低權限策略，這表示僅授與執行必要工作所需的最小一組使用權限。

Enterprise Admins 和 Domain Admins：Active Directory 會定義兩個特殊的系統管理員群組，目錄內的重要功能需要其安全性內容。這些群組 (Enterprise Admins 和 Domain Admins) 負責最上層服務管理。為了降低這種高度權限群組固有的風險，我們極力建議您限制這些群組的成員資格。事實上，Enterprise Admins 群組不應該有永久成員，而 Domain Admins 群組應該只包含少數可管理的受信任者，這些人在組織中擔任全職工作。

當必須執行企業管理工作 (例如 DHCP 伺服器授權或 Active Directory 站台建立) 時，Active Directory 樹系根網域中的 Domain Admins 可藉由管理 Enterprise Admins 群組的成員資格來提升權限。為了避免在 Enterprise Admins 群組中建立永久成員，應該只短期授與這些權限。當然，指定的 Active Directory 樹系中之 Domain Admins 群組的所有成員也必須受到同等的信任。

在開發委派模型時，大部分組織常常落入的陷阱是停用或減損這些內建角色。修改預設角色可能會造成無法預期的結果，而且不保證 Service Pack 修訂或產品升級會保留這些設定。此外，這類修改會在組織之外建立不受支援的環境。較實用的方法是使用內建群組和角色，但限制成員資格。若要這麼做，您可能必須為先前依賴群組 (如 Domain Admins) 中之成員資格的系統管理員建立新角色。

Tier4 Admins：Tier4 Admins 群組應該包含為所有企業服務提供支援的中央服務管理員。因為這是建立的角色，所以可修改目錄服務及系統存取權限，使其符合您組織的特定需求。雖然此群組的成員是服務管理員，但他們有時也可以執行整個樹系的資料管理工作。因為有許多系統類別及不同的責任區域，所以 Tier4 角色在目錄內會分成幾個不同的子群組。例如，若要分開管理特定系統 (例如 Exchange 伺服器)，則應該建立個別的 Tier4 群組。此群組也做為資料管理員的升級點。

使用者通常會想要獲得 Domain Admins 群組中的成員資格授權，理由之一是想要得到指定網域中所有系統的系統管理權限。若要讓這些服務管理員在最低權限模式下執行，秘訣就是要授與企業伺服器的 Tier4 Admins 控制權，而不使其成為 Domain Admins。為了防止權限提升，請不要在網域控制站的 BUILTIN\Administrators 群組中授與 Tier4 Admins 成員資格，因為該群組具有許多無法分開的目錄服務基本權限。例如，指定網域的 BUILTIN\Administrators 群組成員可以管理 Domain Admins 群組的成員資格，讓成員在不需要任何檢查及協調的情況下提升權限。

還記得我們有一條關於不減損預設權限的規則嗎？您可以將 Tier4 群組設定為 Server Operators 和 DNS Admins 內建網域群組的巢狀成員，以降低此風險。這樣您就可以進行網域控制站的本機管理，同時又能限制 Tier4 Admins 提升權限的能力。針對大部分系統 (網域控制站、憑證伺服器等等除外)，您應該將 Tier4 Admins 群組設定為本機 Administrators 群組的成員。您可以利用 [群組原則] 中的 [受限群組] 功能，來自動化巢狀本機群組成員資格的作業。

資料管理員

現在就來探討一下資料管理員角色。這些角色應該以累加權限的方式設計，意指 Tier2 Admin 應該具有 Tier1 Admin 的所有權限以及一些額外的權限，依此類推。基於這個理由，我們將從頭開始了解這些群組。

Tier1 Admins：Tier1 Admins 群組應該對先前建立的目錄物件提供一般管理。此群組適用於經驗不足的系統管理員，或是執行隔離的工作 (例如密碼重設) 的系統管理員。在此群組的組織單位內授與其權限來修改使用者帳戶內容、重設使用者帳戶密碼、解除帳戶鎖定、啟用/停用使用者帳戶、新增和重設工作站電腦帳戶，以及修改非系統管理群組的群組物件成員資格。

Tier2 Admins：此群組應該啟用物件的選擇性管理和建立，讓物件只能建立在可供 Tier1 Admins 管理之處 (例如，安全性群組只能建立在「群組 OU」中)。Tier2 Admins 可以新增及修改 Tier1 Admin 帳戶；新增、修改及刪除 OU 的使用者帳戶；刪除「工作站」電腦物件；以及新增、修改和刪除「伺服器」、「連絡人」及「共用資料夾」物件。

Regional Admins：此群組擁有其地區 OU 結構的專用權。不過，他們無法管理該目錄內的其他地區 OU 結構。Regional Admin 帳戶應視為具有高度權限的帳戶，因此這些帳戶會儲存於個別的 OU 階層中，並且由 Tier4 Admin 服務管理員進行管理。Regional Admins 可以不受限制地在其 OU 結構內建立大部分物件 (建立其他組織單位則屬明顯的例外狀況)，但這會帶來其建立的物件無法由下層管理的另一種風險。

Tier3 Admins：許多組織都有中央或高層服務台。此角色會指定資料管理員的清單，為所有 Regional Admins 提供一個資料管理員群組。權限並不會透過目錄委派給這些群組；而是會透過每一個 Regional Admins 群組中的巢狀成員資格來進行委派。這可以為所有資料管理員提供一個最上層的升級點，也為需要升級到服務管理群組的問題提供了進入點。

建置 OU 和安全性群組模型

在組織中定義角色之後，就必須定義 OU 和安全性群組模型。在 Active Directory 中建立 OU 的兩個主要理由如下：權限的委派以及群組原則物件連結點的建立。OU 會定義目錄內的管理領域 (SOM) 且可用來限制不同層級的物件權限。因此，您選擇委派權限的方式將會是影響您如何實作 OU 結構的一個主要因素。

所以，應該直接在網域下建立最上層 OU (或一系列 OU)，以存放所有物件。這個 OU 的功能，是要針對 Tier4 Admins 定義最高層 SOM。藉由建立最上層 OU，目錄服務的權限就可以從 OU 層級而非網域層級啟用。從最上層 OU 委派而不是從網域委派，可降低使用者運用我們先前所提到的內建網域群組來提升權限的風險。

在最上層 OU 下面，您應該建立個別的子 OU 階層來代表擁有獨立資料管理小組的每一個地區或業務單位。每一個地區的子 OU 都應該擁有不可延伸的通用 OU 階層來管理目錄物件。一致性對於持續進行的管理很重要，因為多數權限委派都是自動化的。這是很難達成的任務，因為每一個地區都希望有獨特的 OU。不過 IT 系統管理員必須堅持自己的主張，如果某個地區需要進行延伸，則所有地區的子 OU 結構也都必須延伸。雖然這一開始可能會有困難，但只要組織為物件提供通用儲存區，假以時日，例外狀況就能夠漸漸消失。

最後，建立個別子管理群組和帳戶來移除系統管理員提升其權限的能力 - 針對每一個子 OU 階層的 Tier1 Admins、Tier2 Admins 和 Regional Admins 群組。將這些帳戶存放在個別 OU 中，才能有效限制其管理範圍不會超越適當層級。因此，如果所有 Tier1 Admins 帳戶及關聯的安全性群組都位於他們沒有權限的 OU 中，系統管理員才無法綁架其他管理帳戶或將其他系統管理員的權限升級到其層級。例如，Domain Admins 群組的任何成員都可以使網域中的任何其他使用者帳戶成為 Domain Admin。不過，使用此 OU 模型便可降低這樣的風險。[圖 2] 顯示與安全性群組關聯之 OU 結構的範例。

圖 2** OU 結構及關聯的安全性群組 **

建立次要帳戶

成功委派模型的關鍵在於強制執行最低權限原則。實際上，這表示安全性主體應該只具備執行其給定角色所需的工作能力而已。很可惜，許多 IT 系統管理員都使用相同安全性主體來進行目錄管理和每日例行工作，如瀏覽網站及讀取電子郵件。使用個別帳戶的話，分層系統管理員比較不會不小心損害到目錄服務，或成為駭客透過例行應用程式攻擊目錄系統管理員的受害者。

若要達成此目的但不需要使用者登出後再登入，您可以使用 Secondary Logon 服務 (Runas.exe)。這樣可讓使用者在伺服器和工作站執行指令碼或可執行檔時，提供一組替代認證來提升其權限。

雖然使用最低權限帳戶的概念很簡單，但是組織發現有時候執行起來並不容易，因為舊的 IT 習慣很難改變。防止在每日例行工作中使用特殊權限帳戶的直接方法，就是不在 Exchange Server 中提供郵件存取功能給這些帳戶，亦即透過組織內的系統管理原則強制執行。如此簡易的方法大幅降低這類帳戶用於例行、非系統管理工作的可能性。

委派權限

開發委派模型中的最後步驟，是要在 Active Directory 內實際委派權限。這包含對儲存在目錄內的資料進行存取控制項目 (ACE) 和存取控制清單 (ACL) 的操作。Active Directory 容器上的 ACL 會定義可建立的物件及那些物件的管理方式。委派權限涉及物件的基本作業，例如檢視物件、建立指定類別之子物件或讀取指定類別之物件屬性和安全性資訊的能力。除了這些基本作業之外，Active Directory 還會定義可啟用 [以下列傳送] 和 [管理複寫拓樸] 等作業的延伸權利。

在先前的步驟中，我們曾討論建立安全性群組來對應到已定義的組織角色。這表示每一個角色都有一個子 OU 結構的關聯安全性群組。若要實作委派模型，則需要指派目錄物件的權限給這些群組。此時，您並不想要從頭來過，建立一個高度自訂的環境。因此，請盡量運用內建群組和權限。假設有一個特定角色需要管理樹系的 DNS 記錄。請勿針對 Active Directory 相關的容器和命名內容委派權限 - 整合式 DNS；相反地，請直接運用網域中的 BUILTIN\DNS Admins 群組。此外，可以透過群組原則延伸使用者權限和其他權限，以提供給定角色管理系統之特定類別所需的其他權限。

利用委派來指派權限時，應該限制或甚至完全禁止在目錄內使用 [拒絕 ACE]。萬一發生問題時，這很難疑難排解。較好的方法是利用明確 [允許 ACE] 來授與權限給代表您角色的自訂群組。請記住，使用者定義的角色 (如 Tier4 Admins) 只擁有該角色所定義的明確權限。

繼承對 Active Directory 安全性而言很重要，它定義特定 ACL 如何套用至給定容器或子容器內的子物件。請具體指定繼承範圍，務必確保可繼承的 ACE 盡量套用到目標物件。套用到父物件的可繼承拒絕權限，其優先順序將高於套用到其上二層物件的任何可繼承拒絕權限，這是為何不建議在實際委派中使用 [拒絕 ACE] 的主要原因之一。此外，可繼承權限無法覆寫物件的明確 ACE。因此，建議您限制或禁止分層系統管理員在目錄物件上修改判別存取控制清單的能力 (方法是移除 [寫入 DACL] 權限) (請注意，物件的建立者隱含擁有這些權限)。如果系統管理員有能力變更物件的 DACL，他很可能會這麼做，這是經驗法則。請勿製造機會產生潛在的管理錯誤，讓組織對委派模型所做的努力白白浪費。

您需要使用一些工具來適當實作 Active Directory 委派模型。對大部分大型組織而言，使用內建委派精靈在目錄中指派權限是一項令人怯步的工作，充斥著發生管理錯誤的可能性。所以一定要使用自動化來確定委派模型妥善記錄而且是可支援的，萬一不小心遺失或變更設定時它還能提供修復選項。

實作委派所需的主要工具是 DSACLS.EXE，它是用於物件上操作目錄服務 ACL 的命令列工具。此工具也能夠在父物件上指定 DACL 的繼承旗標 (繼承旗標可以是：包括此物件及子物件、只包括子物件，以及可繼承權限只傳播一個層級)。如果繼承旗標設定不正確，DSACLS 命令最後會失敗，因此在使用此工具時測試很重要。以下是 DSACLS 語法的範例，是關於委派在目標示範 OU 中建立電腦物件的能力：

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

DSACLS 對於物件類型有區分大小寫。這表示嘗試在 "cn=computer" 上委派 "cn=Computer" 物件類別的權限不會成功 (請參閱 [圖 3])。

圖 3** 因區分大小寫而造成的錯誤 **(按影像可放大)

建立某些物件需要一組特定權限。這必須與物件的 "must contain" 和 "may contain" 屬性有關。我所聽過用來解釋此概念的最佳比喻是漢堡模型。漢堡必須包含肉餅和圓形麵包才叫做漢堡。那些就是漢堡物件類別的 must-contain 屬性。小黄瓜、蕃茄醬、萵苣等項目，則是 may-contain 屬性。如果我們延伸物件類別來定義起司漢堡，必須在 must-contain 屬性的清單中加入起司。

使用者 (User) 物件也是如此的運作方式。假設我們要遵循此模型並使用下列 DSACLS 語法建立使用者 (User) 物件：

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

系統管理員在使用者物件建立期間會遇到幾項錯誤。我們需要授與在使用者物件上設定必要屬性所需的權限，包括密碼的設定。下列另一個 DSACLS 語法將概略說明。

第一步是授與 [一般讀取]/[一般寫入] 給該使用者類別的所有屬性，藉此授與寫入 must-contain 屬性的權限：

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

下一步是授與變更密碼的延伸權限：

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

最後一步是授與權限給 [上次設定密碼] 屬性 (Attribute) 的 [讀取屬性 (Read Property)] 和 [寫入屬性 (Write Property)]：

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

在委派適當權限之後，所定義的角色將只限於管理容器之 DACL 中已定義的物件類別。就先前的電腦物件範例而言，Active Directory 使用者和電腦中的內容功能表，會限制獲委派這些權限的使用者可建立的新物件清單 (請參閱 [圖 4] 中的受限制清單)。

圖 4** 新物件的受限制清單 **

DSACLS 也可以自動化，以提供複雜的權限部署。以下是一些可用來委派權限的 DSACLS 命令，以操作給定容器內之使用者物件的共用地址屬性：

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

諸如此類的範例為大部分委派模型所常見，它們可與先前定義的角色一起使用。

用於實作委派的另一個工具是 DSREVOKE.EXE，這可讓系統管理員在目錄內的物件上尋找及移除特定安全性主體的委派權限。雖然此工具非常有用，但它專屬於安全性主體，而且不會評估安全性群組內的巢狀成員資格。

除了這些命令列工具之外，我們也極力建議您使用 [使用者權限指派] 和 [受限群組] 來搭配 [群組原則]。如前所述，[使用者權限指派] 可讓 IT 系統管理員針對特定目標系統上的不同使用者群組延伸或移除低階權限 (例如從遠端存取及重新啟動系統的權限)。受限群組可用來指定及強制執行樹系內的本機和網域群組成員資格。這些工具搭配使用時提供您要自動化及實作 Active Directory 委派模型所需的一切。

總結

雖然開發 Active Directory 委派模型的工作看起來似乎很複雜，實際上非常簡單的模型就可以套用到大部分 IT 基礎結構。部署實際委派模型時，最重要的步驟之一就是定義明確角色。您應該盡量減少定義的角色數量，以利管理。要取得平衡是相當不容易的，因為太多角色會造成角色沒有全用上，太少角色則使角色劃分困難。

記住，在定義工作時，請按頻率、重要性和困難度加以分類。定義角色之後，請開發一組使用案例來幫助識別每一個角色可以或不可以執行的動作，並將測試流程自動化。仔細規劃的使用案例，可幫助您向組織內的共同關係人說明這些角色，並減少因自動化錯誤而造成的意外。

最後，採取實用的方法來開發委派模型是永遠不會錯的。記住，越簡單越容易獲得支援，一個持久耐用的委派模型才能在 Active Directory 環境內發揮優異的管理權限控管效果。

其他資源

• Design Considerations for Delegation of Administration in Active Directory (英文)
• Best Practices for Delegating Active Directory Administration (英文)

Joel Yoker 是 Microsoft Federal 小組的資深顧問。Joel 和 Rob 專門負責為美國聯邦政府客戶開發及部署安全性解決方案。

Rob Campbell 是 Microsoft Federal 小組的資深技術專家。Joel 和 Rob 專門負責為美國聯邦政府客戶開發及部署安全性解決方案。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.