Windows Server 2008 R2 網域控制站：針對 RODC 審慎作規劃
Paul Yu
當缺乏實體安全性時，加強資料安全性就變得很重要。Windows Server 2008 和 R2 提供的一些新方法似乎是特別針對像是遠端辦公室這類實體安全性可能不夠嚴密的環境來達成此一目的。唯讀網域控制站 (RODC) 是 Windows Server 系統中一項 Active Directory 網域服務 (AD DS) 的新功能。它們在您一般使用網域控制站 (DC) 的方法上有重大的改變。
因為許多 RODC 的新功能對設計和部署程序的各大層面都有影響，所以了解如何在企業當中運用這些功能很重要。將這些功能引入環境之前，還有一些重要的設計和規劃事項您必須列入考量。RODC 是裝載 Active Directory 資料庫分割完整唯讀副本的 DC，它是 SYSVOL 的唯讀副本，也是限制特定應用程式資料從可寫入的 DC 連入複寫的已篩選屬性集 (Filtered Attribute Set，FAS)。
根據預設，RODC 並不會選擇性地存放使用者和電腦帳戶認證，但是您可以設定它們這麼做。單就這一點，通常就足以在資料中心內部網路中常見缺乏實體安全性的遠端分公司或周邊網路中使用 RODC。RODC 也提供其他較鮮為人知的安全性功能，例如特殊的 Kerberos 票證授權帳戶，這類帳戶會處理與 RODC 本身受到入侵時相關的票證型攻擊。
雖然部署 RODC 多半是基於安全性考量，但它們也提供其他許多優點，像是企業易管理性和延展性。一般說來，RODC 是針對需要本機驗證和授權，但缺乏實體安全性來安全使用可寫入 DC 的環境而設計的。因此，RODC 最常見於資料中心周邊網路或各地分公司。
其中一個可善用 RODC 的範例是，需要 AD DS 卻因為安全性限制而無法在周邊網路運用公司 AD DS 樹系的資料中心。在本例中，RODC 可能符合相關的安全性需求，因此能夠變更公司 AD DS 實作的基礎結構範圍。這類的案例很有可能變得越來越普遍。它也反映了周邊網路目前的最佳作法 AD DS 模型，例如延伸的公司樹系模型。
利用 RODC 擴展到分支
對於使用 AD DS 的 RODC，最常見的環境仍舊是分公司。這類的環境通常是中樞和支點網路拓撲中的端點。它們數量龐大並廣佈各地，而且各自主控少數的使用者人口，透過緩慢不可靠的網路連結連線至中樞站台，並且當地往往缺乏有經驗的系統管理員。
對於已裝載可寫入 DC 的分公司，可能沒有必要部署 RODC。不過在這種案例中，RODC 可能不僅符合現有 AD DS 相關的需求，甚至可能超越需求，因為它提供更牢固的安全性、增強的管理、簡化的架構以及更低的整體擁有成本 (TCO)。對於因安全性或管理性需求而禁止使用 DC 的位置，RODC 可以幫助您將 DC 引入環境並提供眾多有益的本地化服務。
雖然 RODC 的各種新功能和好處讓人躍躍欲試，但是還有其他因素需要考量，像是應用程式相容性問題和服務的影響狀況等。這些因素可能使得 RODC 部署在某些環境下不可行。
比方說，許多啟用目錄功能的應用程式和服務都是自 AD DS 讀取資料，它們應該可以繼續運作並與 RODC 搭配使用。但是如果某些應用程式需要隨時可寫入存取，RODC 就可能行不通。RODC 也有賴可寫入 DC 的網路連線進行寫入作業。雖然寫入作業失敗可能是引起應用程式相關問題最常見的原因，但是還需考慮到其他像是讀取作業沒效率或失敗、讀回寫回作業失敗，以及與 RODC 本身相關的一般應用程式失敗等問題。
在可寫入 DC 的連線中斷或遺失時，除了應用程式問題之外，基本的使用者和電腦作業也可能受到波及。例如，若是無法快取帳戶密碼並且在 RODC 本機快取，基本驗證服務就可能會失敗。要緩和這個問題很簡單，只要透過 RODC 的密碼複寫原則 (PRP) 讓帳戶可以快取，然後透過預先填入來快取密碼就行了。執行這些步驟也需要可寫入 DC 的連線。
可寫入 DC 的連線若無法使用，除了會造成其他驗證問題外，也會嚴重影響到密碼過期和帳戶鎖定。密碼變更要求，以及任何手動取消鎖定已鎖定帳戶的嘗試都得等到可寫入 DC 的連線還原後才會成功。為了確保您的需求及任何服務等級協定 (SLA)，了解這些相依性及後續的操作行為改變都是不可或缺的。
您可部署 RODC 的常規案例有好幾種。它們在沒有現有 DC 的位置，或是目前裝載的 DC 即將遭汰換或升級至較新版本的 Windows 的位置都很實用。雖然每種案例都有特定詳盡的規劃考量，但我們在本文將著重於非特定的方法。不過，這些方法會因 RODC 而非傳統可寫入 DC 而異。
事先規劃
在開始任何正式的 RODC 規劃之前，您應該進行適當程度的審慎查核，並事先作好基本的 AD DS 規劃。這應該包括像是驗證現有 AD DS 邏輯結構，以及確保系統管理模型和 AD DS 實體結構支援現有商務和技術需求等重要工作。您還必須考量硬體需求、軟體升級策略，以及可能的作業系統已知問題，並且要評估 RODC AD DS 必要條件。這是規劃和部署程序不可少的資訊。您會發現這已完整記錄在詳盡的部署檢查清單中。
安裝和管理
RODC 有個重大的管理性功能，稱為系統管理原角色隔離 (ARS)。此功能可在不授與 Active Directory 權限下，委派非服務系統管理員安裝和管理 RODC 伺服器。就 DC 伺服器設計、系統管理的委派，以及部署步驟等傳統考量而言，可說是相當大的轉變。對於需要直接安裝在 DC 上的關鍵應用程式，或是對於裝載單一多用途伺服器的位置，這種角色隔離也變得日益重要。
其他伺服器角色
一般來說，您應該將所有 RODC 運作不需要的角色從伺服器移除。因此，唯一應該新增到 RODC 的角色，是 DNS 和通用類別目錄伺服器角色。您應該在每個 RODC 上安裝 DNS 伺服器角色，如此本機 DNS 用戶端才能在可寫入 DC 的網路連線無法使用時執行 DNS 解析。不過，若是 DNS 伺服器角色未透過 Dcpromo.exe 安裝，您必須在之後安裝它。您必須使用 Dnscmd.exe 將 RODC 登記在裝載 Active Directory 整合區域的 DNS 應用程式目錄分割中。您也應該將 RODC 設定為通用類別目錄伺服器，如此伺服器才能夠單用 RODC 來執行驗證和通用類別目錄查詢。從驗證的角度來看，假如通用類別目錄角色不可行，您可以使用萬用群組快取。RODC 的驗證成功與否最終可能取決於 RODC 的 PRP 組態。
RODC 位置
DC 位置自 RODC PRP 推出以來已發生相當大的變更。RODC 必須能夠從相同網域內執行 Windows Server 2008 或 Windows Server 2008 R2 的可寫入 DC 複寫網域分割，因為只有這些 DC 可以強制 RODC 的 PRP。為了確保適當複寫，可寫入 DC 應該放置在可連結至內含 RODC 站台的最低成本站台的 AD DS 站台中。
如果您無法建立此組態，RODC 複寫將需要視 [橋接所有的站台連結] 選項 (表示站台連結轉移性) 或包含 RODC 的站台連結與可寫入 DC 的站台之間的站台連結橋接而定。如果站台轉移性或站台連結橋皆不可行，您可以建立新站台連結直接連接 RODC 站台和可寫入 DC 的站台。
根據一般的最佳作法，您不應該將其他 DC 放置在與 RODC 同一個 AD DS 站台內，因為用戶端作業可能會變得不一致，而使得用戶端行為無法預測。視不同的 RODC 組態、可寫入 DC 的 Windows 版本，以及其他可寫入 DC 的網路連線是否可用而定，像是驗證，LDAP 讀寫和密碼變更等基本作業可能也會有不同的表現。您也應該將來自同個網域的所有使用者和資源保留在 RODC 站台。RODC 並不會存放信任密碼，而且它們需要跨網域授權才能將驗證要求轉送給每個網域內不同的可寫入 DC。假設可寫入 DC 位於不同的站台內，所有跨網域驗證要求就必須依賴網路連線，而且在網路連線失敗的情況下無法執行。
延展性和複寫
RODC 也提供有利於較大型或較複雜的 AD DS 實作的延展性優點。例如，RODC 提供單向複寫。因此，在分公司部署 RODC 可減少中樞站台 Bridgehead 伺服器的效能負載，這些伺服器通常是處理分公司 DC 的連入複寫。從 TCO 的觀點來看，這可減少您需要建立和管理的連線物件數，也可能減少中樞站台 DC 所需的數目。
RODC 還提供負載平衡改進功能，有助於將輸出連線物件自動均分在中樞站台 Bridgehead 伺服器間。這在舊版 Windows 中都需要定期手動介入。現在，當 RODC 上的知識一致性檢查程式 (KCC) 偵測到中樞站台有新增或移除的 Bridgehead 伺服器時，它就會判斷是否要將複寫夥伴切換到新橋接頭。它是透過執行演算法和隨機負載平衡的方式來完成這個動作。如果 RODC 是新增到分公司地點，KCC 也會平衡現有中樞站台 Bridgehead 伺服器間的輸入連線。
認證快取
RODC 的 PRP 會判斷帳戶在該特定 RODC 上是否可快取。根據預設，PRP 中的「允許」清單會指出您無法快取任何帳戶密碼。另外，它也會明確拒絕快取特定帳戶。此清單優先於手動設定的「允許」設定。如前所述，您可能需要在每個 RODC 上設定 PRP 以允許快取帳戶的密碼。
進行這個步驟時請特別小心，因為修改 PRP 會波及安全性和服務可用性。舉例來說，預設的無帳戶可快取的案例可達成高安全性，但在發生可寫入 DC 的網路連線無法使用時，將無法進行離線存取。相反地，可快取帳戶的百分比很高時 (例如網域使用者群組)，如果 RODC 遭到入侵，安全性相對就低很多，但是對於可快取帳戶則有較高層級的服務可用性。由於不同的基礎結構環境各有獨特的商務和技術需求，因此 PRP 設計將因組織而異。
一旦確立 PRP 模型後，您將需要在每個 RODC 上設定 PRP，以便快取適當的帳戶。最佳的作法是，設定 PRP 的明確允許項目，而不要修改預設拒絕清單。拒絕清單的重要性在於它可防止 RODC 上快取重要的帳戶認證 (例如 AD DS 服務系統管理員)。
PRP 設計另一個重要的層面是決定可快取帳戶是否要預先填入密碼。在預設的情況下，當驗證要求轉送到 Windows Server 2008 或 Windows Server 2008 R2 可寫入 DC 時，可快取帳戶的認證其實是等到初次登入 RODC 後才快取，並且認證會複寫到 RODC。這表示若是可快取帳戶在向 RODC 驗證前，可寫入 DC 的網路連線變得無法使用，成功的登入終將會失敗，即使帳戶已設定為可快取亦然。
若要解決這個問題，您可以在 PRP 完成設定且帳戶標示為可快取時，立即手動預先填入密碼快取。不過這項作業在 Windows Server 2008 或 Windows Server 2008 R2 可寫入 DC 與 RODC 之間也需要網路連線才能進行。您可以在部署過程中，在可快取使用者第一次登入前，事先完成這項作業。
您可以使用這個基本架構設計方針做為 RODC 規劃的基礎。本文探討的重要設計考量，為設計詳盡且全面的 RODC 解決方案提供了有效的出發點。這個程序並不簡單，而且需要相當的時間針對貴組織的獨特環境和需求協調新功能和設計考量。
Paul Yu (Paul.Yu@microsoft.com) 是 Microsoft 諮詢服務的資深顧問，於 Microsoft 服務已有十年之久，他為貿易公司和公家機關提供企業基礎結構解決方案。