Windows 系統管理

設計可行的 OU 結構

Ken St. Cyr

摘要:

• 良好 OU 設計的準則
• 常見的 OU 設計模型
• 記錄 OU 設計

別低估設計良好組織單位 (OU) 結構的重要性 — 和複雜性。我發現 IT 部門往往過於偏頗，

不是側重 OU 結構，就是欠缺周詳，兩者都可能使 Active Directory® 模型產生問題。

過度強調 OU 結構會削弱設計 Active Directory 其他區域的注意力，例如規劃網站拓樸或考量網域控制站大小。而過於忽視 OU 規劃，也會阻礙群組原則和委派工作的進行。

我經常見到一種心態，認為 OU 結構很有彈性，萬一發現不適合，日後再更改也無妨。OU 結構確實很有彈性，不過系統管理員常常發現日後變更 OU 結構比當初想像的要困難得多。當然啦，您可以加入新的 OU，但是舊 OU 並不容易清理。

規劃不良的 OU 結構到最後往往是一發不可收拾。如果在目錄中建立一個新物件，而系統管理員不知道要把物件放在 OU 結構的哪裡，他往往是建立新的 OU，或是把物件放在它不屬於的地方。這兩種情況都有危險，建立新 OU 很簡單，但是長期來說要追蹤的話並不容易。毫無節制地建立 OU 會導致 OU 結構混亂，而且東西很容易就在目錄中悄悄蔓延。另一方面，假如您將物件加入不適用的現有 OU 中，新物件可能會收到它不應該取得的原則，或是物件的權限可能會委派給非預定的使用者。

在設計 OU 結構時，應該將這個基本的方程式牢記在心：簡單 + 適應 = 長久之道。如果設計得過於簡單，適應力可能不夠，必須常常變更。如果設計適應度太高，那麼一切就會劃分得過於仔細，而變得太複雜。

關於群組原則、委派和物件管理有三大準則可引導您訂定設計決策。這些準則可總結成三個您應該自問的問題，幫助確保您所建立的 OU 結構，能夠經得起時間和組織變動的考驗。

1. 您需要建立這個 OU，好套用專屬的群組原則物件 (GPO) 嗎？
2. 特定的系統管理員群組在這個 OU 裡面需要具備物件的權限嗎？
3. 這個新 OU 可讓它裡面的物件管理起來更方便嗎？

如果當中有任何一個問題的答案是肯定的，也許就應該建立 OU。如果三個問題的答案全都是否定的，就應該重新考慮一下配置，看看另外一種設計是否比較適合。在深入探討還有說明如何應用這些準則之前，我想先解釋一下這些準則的重要性。

準則 1：群組原則

OU 設計的第一個準則，是把要套用到 OU 的群組原則物件列入考量。GPO 容許您以強制的方式設定使用者和電腦的設定。您可以在 Active Directory 中定義多個 GPO，然後將它們套用到整個網域、不同的 OU，甚或是網域裡面的各個站台。GPO 分成兩種類別，一個用於使用者，一個用於電腦。

您可以在相同的 GPO 內，同時定義電腦原則和使用者原則。GPO 的 [使用者設定] 區段多半是定義使用者在登入時會有的體驗。[電腦設定] 區段也有這類型的設定，但是這個區段也包含了其他與電腦安全性相關的設定，例如，誰登入了本機電腦，或是資料如何加密。

下面是在定義 OU 來支援 GPO 時，必須牢記在心的一些基本原則。首先，別因為使用者和電腦原則可以在同一個 GPO 裡面定義，就認為把使用者和電腦物件放在同一個 OU 裡面是個好主意。將兩者置於同一個 GPO，會使得 GPO 的應用問題更難排解。尤其如果您有啟用回送原則的話，這種情況就更明顯。

其次，許多人都忽略可以在網站層級套用 GPO，因此為了套用 GPO，而設計 OU 結構來塑造網站結構的模型。這是常見的 OU 設計模型，稱為地理模型。稍後我會詳細討論這個模型。不認可地理模型在 OU 設計當中確實佔有一席之地是我的不對，但是您稍後就會看到，我不認為應該把套用 GPO 當作是實作這種模型的主要原因。

另外，當您就 GPO 的角度來考量 OU 結構時，目標應當是避免複雜化。您一定要確實將 OU 加入 GPO 繼承的流程中，如果 OU 包含的伺服器必須採用跟其他伺服器一樣的原則，不妨將這些電腦物件放在較廣泛的伺服器 OU 下，然後在伺服器 OU 下，針對不同的伺服器類型建立多個 OU (請參閱 [圖 1])。這麼做可以簡化原則的套用作業，因為低層 OU 中的每個電腦物件，會從伺服器 OU 以及其他任何該特定類型伺服器專屬的原則那邊取得原則。

Figure 1** Creating multiple OUs for different server types **(按影像可放大)

另外一項基本原則是確定您沒有建立或連結多餘的 GPO。您可以對一個 GPO 建立一項原則，並將它套用到多個 OU。不過這種做法有時候實用，有時候有害。如果您必須變更 GPO 設定，但是連結 GPO 的系統過於複雜時，可能會不小心將變更誤套到不對的物件上。您建立的連結越多，就越難控制原則的領域。同樣地，您應該避免使用跟其他原則相同的設定來建立額外的原則。如果您經常這麼做，最好能夠考慮修改 OU 結構，套用新的 GPO 繼承模型。

最後，您應該盡可能為使用者物件和電腦物件建立 OU。根據預設，使用者和電腦物件是放置在容器中，但容器並不允許您把 GPO 直接與它們連結。GPO 可以從網域套用到 [使用者和電腦] 容器，但除非您封鎖他處的繼承，否則這些原則將會套用到網域當中的每個使用者和電腦上。在 Windows Server® 2003 中，您可以使用 rediruser.exe 和 redircomp.exe 工具，將使用者物件和電腦物件的預設位置，改成您為它們建立的 OU。

準則 2：委派

您一定要配合網域裡面委派權限的方式來建立 OU 結構。請記住，在 Active Directory 中委派權限時，權限的變更只對物件有效。所以如果您對使用者授與特定電腦物件的完整控制權，該使用者就能夠修改物件屬性，但是在電腦本身不會具有系統管理員權限。

以下是在設計 OU 結構時，關於委派的一些建議作法：

設計時留意權限繼承 比方說，假如您希望第 1 層的系統管理員能夠變更大多數帳戶的密碼，但其中有一個使用者群組很特殊，雖然系統管理員不應具有重設它們密碼的能力，卻仍需要具有變更帳戶顯示名稱的能力。

這時候您有兩種做法可以選擇：第一，您可以建立兩個不同的平行 OU，並將特殊的使用者與一般的使用者相區隔。不過，這也表示如果您想要變更所有使用者的委派選項，必須要在兩個不同的地方變更這些選項。這也與不必連結多個原則的作法相違背 (見 [圖 2])。

Figure 2** Maintaining two separate parallel OUs **(按影像可放大)

另一種做法是建立巢狀 OU，並在內含特殊使用者的 OU 上，設定明確拒絕權限。只要是委派專家都會告訴您，明確拒絕是能免則免 — 但是在這種情況下，魚與熊掌不能兼得，您必須擇其一 (見 [圖 3])。您可以在兩個不同的 OU 上複製和維護設定，或是在其中一個 OU 上設定明確拒絕。就長期來說，明確拒絕實際上是比較理想的決定。

Figure 3** Using an explicit deny permission **(按影像可放大)

注意 AdminSDHolder 這個做法相當可行，但是萬一特殊使用者全都屬於其中一個 Admin 群組 (Domain Admins、Schema Admins、Enterprise Admins 或 Administrators)，那就另當別論了，因為這些群組帳戶權限的處理方法是不一樣的。其用意是為了避免把系統管理帳戶的權限不慎交給其他人。

如果您為系統管理員建立不同的 OU，會發現委派給他們的權限都會無故消失。這都是 AdminSDHolder 在作怪，它是一個特殊的容器，會把存取控制清單定時套用到每個系統管理員帳戶。因此，除非對 AdminSDHolder 容器也進行相同的變更，否則您對系統管理員帳戶所做的任何委派變更都會被還原。所以您不應該為了委派，而將系統管理員帳戶與其他帳戶相區隔。比較慣用的方式是針對群組原則來區隔系統管理員帳戶 — 這在 Windows Server 2008 中尤其如此，因為您在裡面可能擁有多個密碼原則。

準則 3：物件管理

OU 應該會使物件的管理更具效率。將物件分組到同一個 OU 中，通常比較容易執行大量變更。Active Directory [使用者和群組] 嵌入式管理單元可讓您編輯選定的多個物件的特定屬性。所以如果您必須定期變更一組物件的屬性，把它們都放在同一個 OU 裡面會比較容易。

這種做法在您使用指令碼進行更新的時候也特別管用。如果您要列舉 OU 中所有的物件，然後一一加以處理的話，使用指令碼語言準沒錯。另一個選項是個別搜尋和修改各個物件。只要將物件放到同一個 OU 中進行管理，有時候每個星期可幫您省下好幾個小時的時間。

另一個幫助管理物件的方法，是根據物件的類型，將它們區分到不同的 OU 中。只要針對印表機物件或發佈的共用區，分別建立不同的 OU，那麼當您對 OU 中的其他物件執行管理作業時，就不用剔除這些物件。這套作法也與不將使用者和電腦帳戶組成到同一個 OU 的作法一致。

選擇模型

看完 OU 設計的準則之後，讓我們仔細探討一些常見的設計模型。請注意，礙於篇幅所限，我無法討論太多模型，但其實還有很多模型。您不需受到單種模型的限制，您可以挑出各個模型的一小部分，建造自己的混合模型，來處理特定的需要。

幾乎所有模型在小規模上運作都不成問題，但是隨著企業擴大，掌控環境的能力也會相對降低。因此，請務必先在適當的實驗室環境內徹底測試模型，另外，雖然 OU 結構剛開始時很容易變更，但時間一久就越來越難了。

平淺模型

平淺模型的名稱由來，是因為它幾乎保持平坦。在這種模型中，是由幾個高階 OU 包含大多數的物件 (見 [圖 4])。這個模型大多是運用在只有小型的 IT 工作室、部門分類不多，或是人員傾向於負責多項職能的較小型企業裡面。通常我建議深度不要超過 10 個子 OU，不過 Microsoft 建議的限制是 15 個子 OU，超過這個限制就會折損效能。

Figure 4** The Shallow Model has a few high-level OUs that contain the majority of objects **(按影像可放大)

如果負責人事的人員也負責發薪，那就沒必要為人事和薪資部門建立兩個不同的 OU。在平淺模型中，所有的使用者物件都可以群組成一個大型的帳戶 OU，或是保留在預設的使用者容器內。您的使用者物件至少應該與電腦物件相區隔。

對於這個模型，我也建議您進一步將工作站與伺服器相區隔。這樣一來，您至少可以套用不同的群組原則，而不用定義 GPO 使用 Windows® Management Instrumentation (WMI) 查詢來篩選工作站或伺服器。

保持 OU 結構寬平而不是窄深的好處之一，是 Active Directory 搜尋作業執行起來會快很多。通常我建議深度不要超過 10 個子 OU。這種模型對物件的控制能力不太細微，但管理小型企業的物件，也不需要太細微的控制能力。因此，這種模型很難成功運用在大型企業中，但非常適合較小型公司。

地理模型

在地理模型中，不同的地理區域要建立不同的 OU。這種模型最適合 IT 部門分散，但又不想花錢操作多個網域的公司 (見 [圖 5])。

Figure 5** The Geographic Model separates OUs by geographical region **(按影像可放大)

假設您在亞特蘭大、巴爾的摩和西雅圖都有辦公室。如果每個站台都負責管理自己的使用者和電腦，那麼就委派的角度來說可能很適合。但萬一西雅圖的使用者飛到巴爾的摩受訓，然後鎖定了他帳戶，那怎麼辦呢？巴爾的摩的 IT 人員若沒有收到這名使用者帳戶的權限委派，可能無法幫助這名使用者。巴爾的摩的上午八點是西雅圖的上午五點，表示這名使用者可能需要等幾個小時後，才能向西雅圖辦公室求助。

有些全球性公司都使用「跟著太陽跑」的模型，也就是服務台電話會路由到位在當時是標準上班時間的時區的地點。這表示公司就不用在每個地點設置 24 小時營運的服務台，但仍然能夠在必要時為夜晚工作的員工提供協助，例如解除帳戶的鎖定。

如果這就是您的模型，那麼對您的營運需求來說，根據地理位置建立不同的 OU，可能不是最佳的選擇。因為您必須為每個 OU 的使用者，委派不同的權限給每個地區的服務台。不過，如果您的地點有它們自己的 IT 部門，那麼地理模型也許就適合貴公司了。

因為網域運作方式的關係，地理模型也很難在單一網域裡面發揮功效。各網域間常常具有不同的安全性模型。只要看一下全企業應用程式 (例如 Microsoft® Exchange)，就不難發現這一點。

亞特蘭大的 Exchange Server 可能會定義不同的郵件原則，但企業內所有的 Exchange Server 也可能都套用相同的 GPO。果真如此，那麼根據地區把 Exchange Server 放在不同的 OU 中，可能會讓您多此一舉的把同樣的 GPO 連結到多個 OU。以委派的角度來看，您必須詢問 Exchange 系統管理員，是否真的需要對 Exchange Server 的電腦物件擁有專屬權限。在大多數情況下，電腦物件都是基於群組原則的目的，而不是委派的目的來而分割成地理 OU。

以類型為主的模型

以類型為主的模型，會依據用途將物件分類 (見 [圖 6])。您上次所建立的使用者物件，是針對一般使用者帳戶、系統管理帳戶，還是服務帳戶所建立？在以類型為主的模型中，對待這些物件的方式各有不同。

Figure 6** The Type-Based Model groups objects according to their functions **(按影像可放大)

在大多數的情況下，您應該針對原則區分不同的使用者物件分類。您的原則很有可能會根據使用者帳戶類型而有所不同。比方說，允許使用者以服務帳戶登入電腦，一般來說是不當的商務作法。服務帳戶密碼通常是在許多人之間共用，因此如果某人使用服務帳戶登入的話，他們的身分識別會保持匿名。若是發生了什麼事，您可能無法追蹤到在事件發生當時登入的使用者身分。在這種情況下，您就得在服務帳戶上設定原則來防止互動式登入。這很適合 [圖 3] 中所示的階層式模型

其優點是您可以利用 GPO 繼承。例如，您可以採用「所有使用者」原則，也就是適合所有使用者物件用的原則。此外，您還可以根據「所有使用者」原則，為服務帳戶另外建置一個不同的原則。這套方法可確保您的服務帳戶與其他每個帳戶擁有相同的基本原則組，以及具備特定的登入限制。

這種方法也適用於使用權限繼承而非 GPO 繼承的委派。假設您希望第 2 層系統管理員能夠重設第 3 層系統管理員帳戶以外的所有帳戶密碼。在平坦的 OU 結構中，您必須委派權限給每個存有使用者帳戶的 OU。但是，在具備階層式結構、以類型為主的模型中，您可以在帳戶 OU 上賦予第 2 層群組「重設密碼」的權限，然後在第 3 層 OU 上，只要取消繼承權限，甚或是設定明確拒絕第 2 層的重設密碼就行了。

這個作法也非常適合電腦物件。您可以區隔伺服器和工作站，以便套用不同的原則。伺服器接下來可進一步細分成職能 (見 [圖 1])。在這種設計中，您可以在伺服器 OU 上，設定影響所有伺服器的高階原則，而仍舊在每個較低層的 OU 上設定個別的原則。

舉個例說，假設您有一個 Microsoft Operations Manager (MOM) 服務帳戶。在這種分層模型中，您可以建立一個 MOM GPO，然後將它套用到 MOM 伺服器 OU。接著在該 GPO 裡面，您可以授權讓 MOM 服務帳戶以服務的身分登入。此舉只適用於該 OU 裡面的 MOM 伺服器。MOM 伺服器還是會從較高層伺服器 OU 取得伺服器 GPO，但是它們也會獲得專門的 MOM GPO，也就是在 MOM OU 連結的 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 文件，並且指定人員負責更新。只要遵守規則讓記錄文件不難更新的話，要延續下去可說不費吹灰之力。

Ken St. Cyr 是 Microsoft 的顧問，在 IT 業界擁有十年的經驗。他自 Active Directory 問世以來就開始設計和實作以 Active Directory 為基礎的目錄解決方案。

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