Active Directory

使用 Catch 的所有子網路，Active Directory 中的

John Policelli

簡介：

• 網域控制站定位器
• 中樞和支點拓撲
• 實作 catch-所有的子網路

內容

用戶端是如何尋找網域控制站
這個問題
Catch-所有的子網路
向上換行

在理想的世界的使用者會被導向適當的網域控制站 (DC) 的 Active Directory 驗證。 不過，這不一定 IP 子網路資訊的定義不正確 Active Directory 中因為大多數組織中的情況。 結果，許多使用者驗證的任意網域控制站，不是最佳的 Active Directory 驗證的。

在這的篇文章中，我提供一個可能的解決方案確保 Active Directory 中沒有完整定義 IP 子網路資訊時，使用者會找到適當的 DC 進行驗證。

用戶端是如何尋找網域控制站

電腦會嘗試尋找網域控制站時, 這樣可以找到適當的 Active Directory 網域控制站是啟始處理序稱為 「 網域控制站定位器 (定位器)。 定位程式會使用儲存在 Active Directory 和 DNS 嘗試尋找網域控制站與所需的角色，而且，會位於最接近用戶端站台的資訊。

在定位器會使用已複寫在樹系的每個網域控制站的樹系根網域中的 [組態] 容器中所定義的資訊。 站台物件 」、 「 子網路的物件和 「 網域控制站伺服器物件是在用戶端電腦中尋找最接近的網域控制站定位器的所有必要的。 站台物件用來表示 Active Directory 站台。 子網路物件會用來表示 IP 位址] 區段，並與適當的站台) 物件相關聯。 網域控制站伺服器物件用來表示網域控制站，並與站台物件相中。

Active Directory 網域控制站將登錄您，指定在其中的 DC 位於的網站的 DNS 記錄。 每個網域控制站登錄的 DNS 記錄的數目取決於 DC 擁有的角色。 例如，DC 的通用類別目錄伺服器將會登錄為通告本身的其他 DNS 記錄。 同樣地，網域控制站持有的操作主機角色將會登錄 DNS 記錄，通告本身為這。

用戶端電腦尋找網域控制站的程序是，如下所示：

1. 在定位器是在用戶端電腦上啟始與本機的 Net Logon 服務遠端程序呼叫 (RPC)。
2. 用戶端會收集資訊，需要選擇一個網域控制站，並將資訊傳遞給 [Net Logon] 服務時。
3. 在用戶端電腦上的 Net Logon 服務會使用所收集的資訊，來建置查詢，以傳送給 DNS 中，以識別適當的網域控制站。
4. 在用戶端電腦上的 Net Logon 服務將資料包傳送至探索到的網域控制站。
5. 目錄服務會攔截查詢，並將它傳遞至 [Net Logon] 服務在網域控制站上。
6. 在網域控制站上的 Net Logon 服務查閱用戶端 IP 位址，在其子網路站台對應資料表，尋找最符合用戶端的 IP 位址，然後傳回之子網路物件至用戶端的下列資訊： 名稱用戶端是位於，在網站或網站最符合用戶端的 IP 位址，名稱中目前的網域控制站是位於，站台和一個位元，指出是否找到的 DC 位於最接近用戶端站台名稱。
7. 用戶端會檢查判斷它是否應該嘗試尋找更好的網域控制站的資訊。 決定，如下所示： 用戶端如果傳回的網域控制站會為最接近的站台，使用此網域控制站 ； 如果用戶端，已找到在 DC 中宣告用戶端站台中 DC 位於，用戶端會使用此網域控制站 ； 如果 DC 不是在最接近的站台，用戶端更新其網站的資訊，以及傳送新的 DNS 查詢，來尋找網站中的新 DC。 如果第二個查詢成功，使用新的 DC。 如果第二個查詢失敗時，會使用原始的 DC。
8. 如果網域的用戶端查詢相同的電腦已加入的網域，則會將在其中電腦所在的站台儲存在用戶端電腦上，登錄。
9. 用戶端尋找 DC 之後，快取網域控制站項目。 如果網域控制站不在最佳網站，用戶端會在 15 分鐘後清除快取，並捨棄快取項目。 它接著會嘗試尋找一個最佳的網域控制站與用戶端位於相同的站台。

在其中一個的用戶端電腦會使用子網路站台對應表中無法表示的 IP 位址的情況下，請 DC 會傳回 NULL 網站名稱，並在用戶端使用傳回的網域控制站，可能位於任何 Active Directory 站台的]。

這個問題

如果網域控制站無法判斷最接近網站，因為 Active Directory 中, 未定義的 IP 子網路資訊驗證，然後就會使用不最佳化的 DC。

[圖 1 ] 說明範例的 Active Directory 站台設計使用中樞和支點拓撲。 從電腦上，在 Active Directory 中定義的子網路的其中一個登入使用者會導向至其最接近的 Active Directory 站台的驗證為網域控制站中。 不過，從子任何其他網路，例如 10.1.4.0/24 電腦登入使用者會被導向到的任何 DC。

[圖 1 範例中樞與支點拓撲] 網站設計

適當修正程式，以解決此問題的不用說是在 Active Directory 中定義其他的子網路，然後將它們與適當的站台產生關聯。 不過，取得資訊通常面臨問題，才能將這些額外的子網路新增至 Active Directory 的組織 (特別是中型和大型組織)。 更特別地是，Active Directory 系統管理員通常察覺的錯誤和記錄檔，其他的子網路的存在，但是不知道哪些實體 Office 這些子網路屬於，防止識別關聯的子網路的網站。

Catch-所有的子網路

一個更實際問題的解決方案是在 Active Directory 中使用一或多個 catch 的所有子網路。 Active Directory 子網路，用於攔截未在 Active Directory 中定義的子網路的用戶端驗證 catch-所有的子網路。 基本上是 Super-subnet catch-所有的子網路。

如 [圖 1 ] 所示，10.1.1.0/24 子網路是 Active Directory 中定義與 Toronto Active Directory 站台。 假設您會發現在 10.1.4.0/24 和 10.1.5.0/24 子網路上的用戶端會驗證 Active Directory。 您認為這些子網路是根據前置詞 (10.1.x.x Toronto 辦公室。 要確保這些的子網路，以及使用 10.1.x.x 前置詞，任何其他子網路上的電腦驗證 Toronto 網站中的 DC。 您建立攔截的所有子網路，直接從您認為位於 Toronto，辦公室的所有子網路的驗證時，用來 10.1.0.0/16 前置字元的因此，並您確保驗證會使用 DC Toronto 網站中。 catch-所有的子網路之間的對應這個範例會顯示 [圖 2 ] 中的紅色文字。

[圖 2 使用 catch 的所有子網路的集線器的網站

在大部分的組織中，遠端辦公室的 IP 子網路資訊被傳送給 Active Directory 系統管理員。 為中央辦公室、 集線器的位置和資料中心 IP 子網路通常有間距。 攔截所有的子網路，可以用來改善在這些情況下驗證。 因為遠端辦公室，IP 子網路是相當靜態的而且這些子網路) 上通常有良好的掌握您可以建立攔截的所有子網路的其他所有的子網路。

在這個範例中，請您可以建立攔截的所有子網路，使用 10.0.0.0/8 前置字元，以攔截從您認為不屬於遠端辦公室，確保驗證所有的子網路的驗證使用 DC 中央 Toronto 站台]。 catch-所有的子網路之間的對應這個範例會顯示 [圖 3 ] 中的紅色文字。 並如果您想要，也可以使用多個的 catch 的所有子網路如 [圖 4 ，] 所示。

[圖 3 所有位置 A catch 的所有子網路

[圖 4] 使用多個 catch 的所有子網路

請注意，在 [圖 3 ] 和 [catch-所有的子網路使用重疊在遠端站台 (例如，10.0.0.0/8] 涵蓋 [10.1.1.0/24) 中使用的首碼的前置字元的 4。 您可能會猜想是否驗證遠端辦公室中從電腦將仍被導向至在適當的遠端辦公室網域控制站的結果。 答案是肯定的。 當重疊的 IP 子網路都存在於 Active Directory 時，便會使用與最小相符的子網路遮罩，IP 子網路。 例如，10.1.1.0/24 會使用代替 10.0.0.0/8 如果電腦有 10.1.1.5/24 子網路的 IP 位址。 不過，10.1.1.1./32 將會用於代替 10.1.1.0/24 已 10.1.1.5 的 IP 位址之電腦。

向上換行

在您繼續進行，並會實作 catch-所有的子網路之前，您需要留意 catch-所有的子網路的概念不適用於所有的環境。 這類解決方案的可行性會大幅相依於您的 IP 位址配置。

我這裡所提供的範例，在 [IP 位址配置都是相當直接了當的。 不過，當 IP 位址配置變得更複雜的使用 catch-所有的子網路的可行性就比較不可能的。 例如，如果您的環境包含多個網路區段在每個位置卻無法循序您的 IP 位址配置它將會是幾乎無法建立攔截的所有子網路，會提供任何值。 如同所有的解決方案，您需要考慮技術、 商業，和環境因素您環境的特定決定實作 catch-所有的子網路的可行時。

並請注意 catch-所有的子網路的使用會無法解決問題完全遺漏子網路。 事實上，如果您是在您的環境中引入 catch-所有的子網路，很更重要的您明確地在 Active Directory 中定義所有的已知子網路。

catch-所有的子網路的使用會增加的使用者尋找在接近網域控制站的數目。 不過，您的目標應該仍然是，解決這個問題的來源並確保您收到所有的新增、 修改及移除網路子網路的適當資訊，因此您可以維護提供有效的驗證，所有使用者的最新 Active Directory 站台設計。

John Policelli (Microsoft MVP for 目錄服務、 MCTS、 MCSA、 ITSM、 iNet +、 Network + 及 A +) 是成功的一個十年的組合，在架構、 安全性、 策略性的規劃和嚴重損壞修復規劃解決方案著重 IT 顧問。 John 在過去的九個多年來，著重在識別和存取管理已投入，並提供最大的在加拿大的 Active Directory 安裝的某些中認為領導能力。 John 維護在部落格 http://policelli.com/blog.