切勿低估設計良好的組織單位 (OU) 結構的重要性和復雜性我發現 IT 部門經常盲目行事他們有時過分關注 OU 結構有時又不對其進行認真思考總之這會導致 Active Directory? 模型發生問題
過度強調 OU 結構就會忽略 Active Directory 設計的其他方面例如規劃站點拓撲或考慮域控制器大小另一方面如 OU 規劃不受重視組策略和委派將會受到不良影響
我曾聽到的一種托辭是 OU 結構很靈活如果不合適之後可以進行更改的確OU 結構很靈活;不過管理員通常發現後期更改 OU 結構要比他們原來預期的困難當然可以添加新 OU但舊 OU 卻很難清除
計劃欠佳的 OU 結構往往會我行我素如果在目錄中創建了一個新對象但管理員不知道將其置於 OU 結構中的什麼位置他只能選擇要麼創建一個新 OU要麼將該對象放在某個不相干的位置這兩種情況都比較危險創建一個新 OU 很容易做到但從長遠角度來看很難進行跟蹤猖獗的 OU 創建形成了混亂的 OU 結構而且易於讓各種內容蔓延到未記錄的目錄中另一方面如果您將某個對象添加到與其不相干的現有 OU 中則此新對象可能會接收它不應獲得的策略或者該對象的權限可能被委派給非目標用戶
設計 OU 結構時應記住一個基本等式簡單性 + 適用性 = 可持續性如果您的設計過於簡單則它可能並不適用因此將不得不過於頻繁地進行更改如果您的設計適用性過強則所有內容都將被分類這會使情況變得過於復雜
有三個關於組策略委派和對象管理的關鍵原則它們可為您的設計決策提供指導這些原則可被歸結為三個您應自問的問題幫助確保所創建的 OU 結構體經得起時間和組織更改的考驗
是否需要創建此 OU 結構以便可對其應用唯一的組策略對象 (GPO)?
特定管理員組是否需要對此 OU 中的對象具有權限?
此新 OU 是否會使其內部對象管理變得更為輕松?
如果上述任一問題的答案均為是則您可能應創建此 OU如果所有三個問題的答案均為否則您應重新考慮布局並確定其他設計是否更加合適但是在我對此做更深入的探討並為您顯示如何應用這些原則之前我應首先解釋這些原則之所以重要的原因
原則 組策略
OU 設計的第一個原則是考慮將應用於 OU 的組策略對象GPO 允許您強制對用戶和計算機設置進行配置您可以在 Active Directory 中定義多個 GPO並將其應用於整個域各種 OU 乃至域中的站點GPO 分為兩類—一類用於用戶一類用於計算機
計算機策略和用戶策略可在同一 GPO 中定義GPO 的用戶配置大多定義用戶登錄時的體驗這些設置類型也存在於計算機配置中但此部分還包含與計算機安全性相關的更多設置例如誰可在本地登錄到計算機或如何加密數據
以下是您在定義支持 GPO 的 OU 時需要記住的一些基礎知識首先僅僅因為用戶和計算機策略可在同一 GPO 中定義就認為最好將用戶和計算機對象放入同一 OU 中是錯誤的將它們合並到同一 GPO 中會使 GPO 應用更難以進行故障排除當您啟用環回策略時這一點非常明顯
其次許多人會忘記您可以在站點級別應用 GPO因此為與 GPO 的應用目標相符應模擬其站點結構設計 OU 結構這是 OU 設計的一種常見模型稱為地理模型我將進一步探討此模型我必須承認地理模型在 OU 設計中的地位但正如您稍後將看到的我不認為 GPO 應用是實施此模型的主要原因
此外當根據 GPO 考慮 OU 結構時目標應該是消除復雜性請確保將 OU 添加到 GPO 繼承流中如果您 OU 所包含的服務器要求與其他服務器相同的策略請考慮將這些計算機對象置於范圍更廣的服務器 OU 下並在此服務器 OU 下為不同的服務器類型創建多個 OU(請參閱圖 )這可以簡化策略應用程序因為更低層 OU 中的每個計算機對象將從服務器 OU 獲取策略還會獲取特定於此特定服務器類型的任何其他策略
Figure Creating multiple OUs for different server types
另一基礎知識是確保不要創建或鏈接多個不必要的 GPO使用 GPO您可以創建一個策略並將其應用於多個 OU這有時是有益的但也可能是有害的如果您必須更改 GPO 設置而且鏈接的 GPO 系統過於復雜則會偶然將更改應用於錯誤對象您創建的鏈接越多掌握策略范圍的難度就越大同樣您應避免使用與其他策略相同的設置來創建附加策略如果您發現您經常如此則考慮修改您的 OU 結構以應用新的 GPO 繼承模型
最後您應盡量始終為用戶對象和計算機對象創建新的 OU默認情況下用戶和計算機對象被置於容器中這不允許您將 GPO 與這些對象直接鏈接可將 GPO 應用於域中的用戶和計算機容器但除非您在其他位置阻止繼承否則這些策略將應用於域中的每個用戶和計算機在 Windows Server? 中您可以使用 rediruserexe 和 redircompexe 工具將用戶對象和計算機對象的默認位置更改為您為其創建的 OU
原則 委派
您創建 OU 結構的方式與在域中委派權限的方式一致這一點非常重要請記住當在 Active Directory 中委派權限時權限更改僅對對象生效因此如果您為某位用戶授予了對特定計算機對象的完全控制則此人員可以修改該對象的屬性但其並不具有對計算機本身的管理員權限
以下是對您在設計 OU 結構時進行委派的一些建議做法
設計時應注意權限繼承 例如假設您希望第 層管理員能夠更改大多數帳戶的密碼對於特殊的用戶組管理員不應具有重設密碼的能力但他們確實應該可以更改有關這些帳戶的顯示名稱
在此您實際上有兩個選項第一您可以創建兩個單獨的並行 OU然後將特殊用戶與普通用戶分隔開來不過這意味著如果您要更改所有用戶的委派選項則必須在兩個單獨的位置更改這些權限這還與不鏈接多個不必要策略的方法相抵觸(請參閱圖 )
Figure Maintaining two separate parallel OUs
另一個選項是創建嵌套式 OU然後對具有特殊用戶的 OU 實施顯式拒絕權限任何委派專家都會告訴您顯式拒絕不可取—但在此情況下您需要從兩者中選擇一個不利因素相對較少的一個(請參閱圖 )您可以在兩個單獨的 OU 上復制和維護這些設置也可以對其中一個 OU 實施顯式拒絕實際上顯式拒絕是更好的長期決策
Figure Using an explicit deny permission
注意 AdminSDHolder 本示例適用於大多數情況除非特殊用戶全部都屬於一個管理員組(域管理員架構管理員企業管理員或管理員)因為這些組中的帳戶權限的處理方式不同原則是您不希望意外地為某個人授予管理員帳戶權限
如果您為管理員創建單獨的 OU則會發現委派給他們的權限均消失這由 AdminSDHolder 所致它是一個特殊的容器可根據指定間隔將其訪問控制列表應用於每個管理員帳戶結果是如果尚未對 AdminSDHolder 容器進行更改則將取消您對管理員帳戶所做的任何委派更改因此出於委派目的您不應將管理員帳戶與其他帳戶分開但對於組策略最好將管理員帳戶分出來—在您可以擁有多個密碼策略 Windows Server 中這一點尤為突出
原則 對象管理
OU 應有助於對象的管理將對象歸組到同一 OU 中通常更易於執行大量更改Active Directory 用戶和計算機管理單元允許您在選擇多個對象時編輯某些屬性因此如果您必須定期更改某個對象組的屬性則此操作在這些對象全部位於同一 OU 中時更易於完成
當您使用腳本進行更新時這一點也特別有用腳本編寫語言可以非常輕松地枚舉 OU 中的所有對象並逐個進行處理另一個選項是搜索並分別修改各個對象只需將對象放入同一 OU 中進行管理有時便可以節省您每周不必要的工作時間
另一個有助於對象管理的方法是根據類型將對象分到不同的 OU 中為打印機對象或發布的共享創建單獨的 OU可確保您在對 OU 中的其他對象執行管理時不必清除這些對象這一原則與不將用戶和計算機帳戶歸組到同一 OU 中的原則也是一致的
選擇模型
既然我已經提到了 OU 設計的原則那麼我可以進一步查看某些常用設計模型請注意由於篇幅所限還有許多模型我無法在此一一介紹您不要限於僅使用單一模型您可以拾取每個模型的片段來構建您自己的混合模型從而解決特定需求
幾乎任何模型都可以實現小范圍的成功但隨著企業的擴大您對環境的處理能力會逐漸縮減因此請確保首先在充分的實驗室環境中對您的模型進行全面測試請記住盡管您最初可以很輕松地更改 OU 結構但這些結構實施的時間越長就越難以更改
淺模型
淺模型的名稱源自它大多保持平整這一事實在此模型中幾個高級別的 OU 包含絕大多數對象(請參閱圖 )此模型主要在小型企業中運用在此類企業中有一個小型 IT 商店沒有過多的部門或者人員往往扮演多個角色為避免對性能產生負面影響我通常建議子 OU 數不要超過 個盡管 Microsoft 提出的子 OU 限制數是 個
Figure The Shallow Model has a few highlevel OUs that contain the majority of objects
如果人力資源人員同時也是您工資單中的人員則為人力資源和工資單創建兩個單獨的 OU 毫無意義在淺模型中可將所有用戶對象歸組到一個大的帳戶 OU 中也可將其保留在默認用戶容器中最起碼您的用戶對象應與計算機對象分開
對於此模型我還建議您進一步將工作站與服務器分開然後您至少可以應用不同的組策略而無需定義一個使用 Windows? Management Instrumentation (WMI) 查詢過濾出工作站或服務器的 GPO
保持 OU 結構范圍廣泛(而不是深度)的一個優勢是 Active Directory 搜索速度將更快我通常會建議子 OU 數不要超過 個雖然在此模型中您對對象的控制不是非常精准但是如果您管理的是小型企業中的對象則不需要這種精准控制因而此模型很難在大型企業中成功使用但其在小型組織中的效果卻非常好
地理模型
在地理模型中您針對不同的地理區域創建單獨的 OU此模型最適合用於 IT 部門分散但不希望因操作多個域而帶來成本的組織(請參閱圖 )
Figure The Geographic Model separates OUs by geographical region
假設您的辦事處設在亞特蘭大巴爾的摩和西雅圖如果每個站點管理它自己的用戶和計算機則就委派而言這可能是一個很好的方法但如果西雅圖用戶飛到巴爾的摩參加培訓然後封鎖了其帳戶將會怎樣?如果位於巴爾的摩的 IT 人員沒有被委派該用戶帳戶的權限則他們可能無法為其提供幫助如果在巴爾的摩是上午 點那麼在西雅圖就是上午 點這意味著該用戶可能必須等待幾個小時才能在西雅圖辦事處找到可以提供幫助的人員
一些全球性的公司使用全天候模型在其中幫助台呼叫被路由到當前采用標准工作時間的時區中的站點這意味著公司不必在每個站點都運行 小時幫助台但仍可以為夜班員工提供必要的幫助例如解除對其帳戶的鎖定
如果您采用的是這一模型那麼對於您的運營需求而言根據地理位置創建單獨的 OU 可能不是最佳選擇您必須將單獨的權限委派到用戶各個 OU 中的每一區域幫助台不過如果您的站點確實擁有它們自己的 IT 部門則實際上對於您的組織而言地理模型可能是理想之選
此外由於域操作方式的性質很難在單個域中實現地理模型某個域的安全模型往往與其他域的不同當您查看企業范圍的應用程序(如 Microsoft? Exchange)時這一點更為明顯
位於亞特蘭大的 Exchange Server 可能定義了不同的消息策略但該企業中的所有 Exchange Server 可能應用同一 GPO如果是這種情況則按區域將 Exchange Servers 置於單獨的 OU 中將導致您不必要地將同一 GPO 鏈接到多個 OU就委派而言您必須詢問 Exchange 管理員是否確實需要 Exchange Server 計算機對象的唯一權限在大多數情況下被拆分到地理 OU 中的計算機對象是為組策略(而非委派)做此處理
基於類型的模型
基於類型的模型按用途來分類對象(請參閱圖 )當您創建上一個用戶對象時它是用於普通用戶帳戶管理帳戶還是服務帳戶?在基於類型的模型中上述每種對象的處理方式均不同
Figure The TypeBased Model groups objects according to their functions
在大多數情況下您應針對策略區分用戶對象的不同類別您的策略將很可能根據用戶帳戶類型而有所不同例如允許人員使用服務帳戶登錄計算機通常是一個糟糕的業務慣例服務帳戶密碼通常在許多人員之間共享因此如果某個人使用服務帳戶登錄則其身份是匿名的如果發生什麼事情您很難跟蹤到事件發生時所登錄的用戶在本示例中您需要對服務帳戶設置一個防止交互登錄的策略這非常適合層次模型如圖 所示
此時可利用 GPO 繼承為您帶來益處例如您可以具有所有用戶策略它是指用於所有用戶對象的策略另外您還可以針對服務帳戶具有獨立但截然不同的策略(它基於所有用戶策略而構建)這一方法可確保您的服務帳戶與所有其他帳戶具有相同的基礎策略集同時還具有特定的登錄限制
此方法還對委派十分有效在其中您使用權限繼承而非 GPO 繼承假定您希望第 層管理員可以重設除第 層管理員帳戶之外的所有帳戶的密碼使用平面 OU 結構您必須將權限委派給持有用戶帳戶的每個 OU不過在具有層次結構的基於類型的模型中您可以在帳戶 OU 上為第 層的組授予重設密碼權限然後在第 層 OU您只需取消繼承這些權限甚至可以為第 層設置顯式拒絕來重設密碼
這對於計算機對象同樣有效服務器和工作站可以分開從而允許對它們應用不同的策略服務器然後可被進一步細分為多個功能(請參閱圖 )在本設計中您可以對服務器 OU 設置影響所有服務器的高級別策略同時仍對每個低級別 OU 設置單個策略
例如假設您有一個 Microsoft Operations Manager (MOM) 服務帳戶使用此分層模型您可以創建一個 MOM GPO 並將其應用於 MOM 服務器 OU然後在此 GPO 內部您可以授予 MOM 服務帳戶權限從而以服務形式登錄這僅適用於此 OU 中的 MOM 服務器MOM 服務器仍將從高級別服務器 OU 獲取服務器 GPO但它們還將獲得在 MOM OU 鏈接的專用 MOM GPO
記錄設計
設計一個經受得起 Active Directory 環境所遇到的多種變化的 OU 結構非常有意義但是您需要設法跟蹤 OU 的動態特征如果您不具備此條件則會很快失去對環境的掌控如果內容確實需要更改而且需要添加或刪除 OU則就所執行操作必須要有明確的指導以確保您的模型繼續沿襲設計模型從而遵循三個指導原則這就是您為什麼必須對設計進行完整文檔記錄的原因
Microsoft 在 Windows Server 資源工具包中提供了文檔指南如果您的結構是一個較為可靠的框架而且您不想進行太多更改則這些指南會提供很好的幫助但是大多數組織的結構都十分動態需要頻繁更改因此下面提供了一些重要提示以確保您的 OU 結構有完整的文檔記錄而且能夠支持動態環境
確保所有信息均相關 我對有針對性的文檔十分信賴過多的操作性文檔包含如此多的無關信息以致於難以找出相關資料切勿僅僅為了記錄而執行記錄過程您真的需要包括每個 OU 中的對象數或者 OU 訪問控制列表上的每個訪問控制項 (ACE) 嗎?對於 OU 文檔以下信息通常已經足夠
OU 名稱
簡要說明
創建者—或者更多信息或更改的相關聯系人
創建時間
不要使更新變得困難 如果您不得不乏味地更新一些復雜的 Microsoft Word 文檔則拖延輸入更新的可能性會更大當您知道馬上就要有大量更新輸入時拖延輸入少量更改是可以的遺憾的是人們往往忘記這些小部分更改或者只是將其一直拖延下去進而導致作業從未完成過因此更新文檔必須要非常輕松免得您洩氣在大多數情況下只有幾列的簡單 Microsoft Excel? 電子表格將非常有效
針對對象本身進行注釋 OU 對象具有一個描述屬性您可在其中輸入注釋請考慮將注釋置於描述屬性中而不是在設計文檔中編寫它們以便其他人可以立即說出 OU 的用途如果您需要包括更多的詳細信息則在描述屬性中輸入簡要說明然後在 OU 文檔中加入更多詳細信息
自動化文檔 可以編寫一個腳本以將 OU 結構的內容轉儲到文本文件Excel 電子表格乃至 HTML 文件中每天晚上都可以對計劃好的任務運行這一腳本當您將注釋合並到 OU 的說明字段中時這會非常有用之後只需將描述屬性轉儲到文件中您即會自動獲得一個記錄完整始終為最新的 OU 結構如果您每次運行該腳本時都創建一個新文件而不是覆蓋現有文檔則可以保留有關 OU 結構如何隨時間變化的歷史記錄
遺憾的是大多數管理員直到他們確實需要一個完善的 OU 結構文檔時才意識到它的重要性但到那時(凌晨 點)不執行還原幾乎不可能查明哪些其他 OU 已被意外刪除
請不要等到此刻才幡然醒悟強烈建議您在此方面積極行動起來立即啟動 OU 文檔並指定一名人員負責其更新如果您遵循使文檔易於更新這一規則這將只是一個需要反復執行的極小任務
From:http://tw.wingwit.com/Article/os/xtgl/201311/9261.html
