目錄服務管理

模式及實務

這份指南針對已經部署或可能在資料中心或其他類型企業運算環境中部署 Microsoft 技術的組織，提供有關目錄服務管理功能 (SMF) 的詳細資訊。這是 Microsoft? 作業架構 (MOF) 中定義和說明的 20 多個 SMF 之一。本指南假設讀者熟悉 MOF 和所討論 Microsoft 技術的目的、背景和基本概念。

有關 MOF 和隨伴產品 Microsoft 方案架構 (MSF) 的概觀，請參閱《Introduction to Service Management Functions》指南，這個指南也提供 MOF 內定義每個服務管理函式的摘要。有關每個架構的概念及原則的詳細資訊，請參閱 http://www.microsoft.com/taiwan/solutions/msm/ 上的技術文件。

目錄是資訊或資料來源，用於存放使用者關注之物件的資訊。電話簿存放關於電話用戶的資訊，在檔案系統中，目錄則存放關於檔案的資訊。

目錄服務讓使用者和應用程式可以找到網路資源，例如使用者、伺服器、應用程式、工具、服務和其他網路上的資訊。目錄服務的目的在於確保透過簡單而有組織的程序，使經過授權的要求者可以透過網路存取資訊。

通常，線上目錄的設計會偏重於動態、具備彈性、安全性和個人化。偏重動態的原因在於，使用者和網路資源移動時目錄就會頻繁變更，由於可以藉助程式設計以包含新的資訊類型，所以必須具備彈性。安全性的考量，則是著眼於可以限定目錄中的獨立物件僅能由特定的使用者、群組、或存取類型使用。另外，為了滿足提供特定使用者或群組所需的自訂回應，目錄資訊也必須具備可以進行編輯和編排的個人化功能。

目錄服務管理概觀

在擴充的電腦系統上，目錄服務是最重要的元件之一。雖然使用者和管理員通常不清楚所需物件的確切名稱，但可能知道一個以上的物件屬性，可以查詢目錄以取得符合屬性的物件清單。

目錄服務可以：

目錄服務同時是管理工具和一般使用者的工具，隨著網路中的物件數目不斷增加，目錄服務會變得越來越重要。目錄服務對大量分散式目錄的存取而言，可以視同資訊服務的配發中心 (Hub)。

以往，目錄服務多用於命名和尋找網路資源。這些功能已經加以擴展，而現在目錄服務也成為 Internet/Intranet 基礎結構 (參考目錄、個人和企業電話簿、電子郵件目錄等等) 中的重要元件。

目錄服務也促成電子郵件的傳遞和分散電子郵件系統之間的整合，在應用程式整合方面也日趨重要，例如做為所有應用程式、存取控制以及安全性資訊的集中式儲存機制庫。

現在已出現相當多的新型應用程式，它們不但具備目錄功能，更將目錄視為網路基礎結構的必要部分。目錄已被視為具備特殊用途且可以自訂的資料庫，使用者和應用程式可以安全地連線至資料庫，以尋找、讀取、新增、刪除和修改資料，接著資料會自動散佈到網路上的其他目錄伺服器。

這些具備目錄啟用功能的應用程式需要成熟的目錄服務，才能執行另外三個主要的功能：驗證和授權、命名和尋找，以及管理和網路資源管理。

目錄服務管理的目標在於確保

經過授權的要求者可以透過簡單而有組織的程序，在網路上存取資訊。

目錄服務讓使用者和應用程式可以找到網路資源，例如使用者、伺服器、應用程式、工具、服務和其他網路上的資訊。目錄服務管理負責企業目錄的每日操作、維護和支援。目錄服務管理涵蓋：

關鍵定義

警示： 重大事件的指示，由處理規則定義。

屬性： 電腦特性，通常由登錄機碼或值定義。

驗證： 使用者向系統證明其身份的方法，用於密碼、智慧卡、生物統計等等。

授權：驗證使用者擁有適當權限，可以存取網域中資源的程序。

備份：這個術語通常是指電腦上所有檔案的副本，這個副本會定期製作並保存在磁帶或其他可卸除式媒體上 (也稱為「傾印」)。

用戶端：電腦系統或處理序，使用某種通訊協定並接受伺服器回應，以要求其他電腦系統或處理序 (伺服器) 的服務。用戶端是主從軟體架構的一部分，例如，從檔案伺服器要求檔案內容的工作站就是檔案伺服器的用戶端。

目錄：電腦檔案的集合，系統中最常見的是圖形式使用者介面，提供圖形檔案瀏覽器，其中通常以資料夾 (例如小型的公事包) 表示目錄。

事件：系統或應用程式中的重大狀況，需要通知使用者或新增記錄項目。

防火牆：專用的閘道電腦，具有特殊的安全預防措施。目的是要在其後保護一群管理不甚嚴密的電腦，以防止他人任意萃取資訊。典型的防火牆是使用價格便宜微處理器的 Unix 電腦，不包含重要的資料，其上有數據機和公用網路連接埠，但僅有一條連接到叢集其餘部分的連線接受密切監視。特殊的預防措施可能包括威脅監視、回呼 (Callback)，甚至有完整的鍵入裝置，用於特殊的傳入 ID 或活動模式。

輕量目錄存取通訊協定 (LDAP)：不論目錄廠商或實作方式為何，LDAP 可以讓應用程式使用相同的方法存取目錄。大多數一般用途的目錄可以使用 LDAP 存取。使用 LDAP 的應用程式可以使用簡化的方式存取各種目錄中的多重資訊片段。

中繼目錄：基本上，中繼目錄產品是目錄的目錄。中繼目錄提供了置於各種不同類型目錄上層的通用基礎結構，經由單一的通透性使用者介面導向查詢並傳回目錄的回應。中繼目錄整合並統一了異類目錄。

網路作業系統 (NOS)：使用軟體透過網路與其他電腦通訊的作業系統，如此就可以共用電腦之間的資源，如檔案、應用程式和印表機等。

伺服器：一部電腦提供服務給其他透過網路連線至本身的電腦，最常見的範例是檔案伺服器，具有本機磁碟及來自遠端用戶端要在該磁碟上讀取和寫入檔案的服務要求。

簡易網路監視通訊協定 (SNMP)：SNMP 讓管理應用程式可以監視網路上實體的狀態，發生事件或錯誤時 (也就是伺服器處理序突然停止時)，也可以透過 SNMP 設陷機制，非同步通知管理應用程式。

主要處理序

目錄服務管理程序分為五個主要的處理序和數個子處理序：

圖 1 目錄服務程序流程圖表

目錄類型

下一個章節是有關目前目錄技術或目錄類型的高階討論；其中可能有某些您已經使用的目錄類型，也有一些類型的目錄可能是您將要佈署使用的。

一般用途或標準目錄並非連接到特定的應用程式或服務，也不是只與特定的網路作業系統 (NOS) 相關聯，而且不會為了獨特的目的而部署。這些目錄是為了滿足無數的服務需求而設計。以輕量目錄存取通訊協定 (LDAP) 為例，LDAP 幾乎可以符合所有具備目錄啟用功能應用程式的使用需求。

大多數一般用途的目錄可以透過 LDAP 進行存取。不論目錄廠商或實作方式為何，LDAP 可以讓應用程式使用相同的方法存取目錄。使用 LDAP 的應用程式可以使用簡化的方式存取各種目錄中的多重資訊片段。

特殊用途 (或應用程式) 目錄是指與某特定應用程式 (或應用程式套件) 密切結合的目錄。這類應用程式與一般用途目錄之間的差異在於，這類目錄會與某個應用程式以及其所使用的專屬介面和通訊協定緊密地結合。一般而言，除了專屬設計使用的應用程式以外，幾乎不支援任何其他具有目錄啟用功能的應用程式使用。

此外，NOS 的特定目錄同樣屬於此一類型的目錄：亦即與特定作業系統相結合的目錄。雖然，大多數 NOS 目錄是以其專屬性出發，但現在為支援具備目錄啟用功能應用程式的通用性，大多具備符合 Internet 目錄的規格標準 (即 LDAP)。

本文件中提供的資料主要針對組織目錄部署之後的操作、支援、管理和維護。文件內容之所以如此安排，是由於大多數客戶已經佈署了一個 (含) 以上的一般用途或特殊用途目錄，以因應其商業需求。例如，公司可能擁有與其人力資源管理系統、電話系統、電子郵件系統或企業資源規劃系統相關的線上 (電子) 目錄。

從操作的觀點來看，將所有的目錄方案開始移到單一的管理和操作點是相當重要的。

瞭解部署目錄方案的最佳方法，就是將所有與部署有關的事項一視同仁，除非徹底瞭解、記錄、設置、監視、管理、支援和積累目錄在功能和實務運用等方面的細節，否則就不算完成了目錄方案的部署。

在對目錄施行正面或具有實質意義的控制之前，您必須先認知現有條件、運作方式、組成元件之間的協同作業，或是與其他元件、系統或應用程式間的互動，以及各組成元件的負責人等等。令人覺得不可思議的是，有許多的企業僅止於使用一個或多個目錄服務，卻全然不瞭解這些元件。大多數的目錄佈署作業在開始的時候，就受到了預算、時間和資源等方面的限制，這同時也是本篇文件以及相關控制項目所面臨的問題。

有許多公司企業嘗試在事後記錄部署並且實作適當的控制機制 (監視、委派管理職責、服務台工作項目等)，然而，卻由於商業環境的快速增長和動態變遷，導致執行上的困難。

前面兩段說明了在主動獲取知識和便捷操作的層面上無法完全實行的原因，但這些相關工作必須落實，而且必須在部署的方案失控或不符原本需求等情況發生前就做好。發生危機時有下列症狀：

大多數的公司的系統通常處於運作順暢和充滿危機兩個狀態之間。無論您的處境為何，本文件下面章節內容可以協助您對公司現行作業簡便性的相關問題進行評估，協助您進行必要的變更以達成解決方案的最終目標：充分的可用性 (Availability)、可靠度 (Reliability)、管理性 (Manageability) 以及支援性 (Supportability)，也就是所謂的「ARMS」。

本節旨在說明目錄的使用方法，並對目錄整合的觀念做一簡單的介紹。

由於引進了大量、異類的、一般用途和特殊用途的目錄，管理這些目錄的工作經常令人感到困擾。異類目錄管理的方法和技術仍然昂貴、冗長且尚未標準化。

目錄技術的發展其實已臻成熟，功能可以支援啟用目錄的辨公室自動化 (包括電子商務) 以及一般的企業運算。

以往，目錄服務是用於命名和尋找網路資源。新的目錄服務應用程式包含了企業電子電話簿、Internet 私人/工商分類通訊簿、電子郵件傳遞、整合不同的電子郵件系統，以及使用者資訊集中式儲存機制庫等多種功能。

目錄服務產品利用安全性服務，以追蹤網路資源和資訊的存取權限。由於目錄會將企業中所有的資源以邏輯化的方式具體呈現，所以目錄服務可以做為資源安全性管理的有效方法。此外，目錄服務也可以當做進入網路的單一入口點。使用者可以單次驗證自己進入目錄服務，存取允許範圍內的資源。

一般而言，目錄服務的用途可以區分為下列四大類：

驗證及授權

一些特定的應用程式工具允許網路作業系統和電子郵件程式追蹤使用者、使用者的密碼以及各種與應用程式相關的參照和組態資訊，這類的應用程式工具可以說是一般用途目錄的先驅。

目錄服務與安全性服務已成為網路服務模式中不可或缺的兩個元件。而且，這兩項服務之間仍然有著密不可分的關連性，就是提供驗證及授權的功能安全性及目錄服務兩者是相輔相成的。首先，目錄必須要提供驗證及可以管理使用者存取和修改目錄的存取控制等功能。此外，目錄還提供了合併一般用途安全性機制的作業基礎。

驗證

驗證會叫用安全性服務，進行使用者和應用程式的身分確認或驗證。從歷史的觀點來看，網路作業系統和應用程式早已使用以密碼為基礎的系統專屬驗證方法。然而，企業 Intranet 出現後，再加上 Internet 的成長，就需要一般用途的安全性基礎結構。

目錄必須提供管理目錄資料庫存取的驗證機制。目錄可以透過各種方法驗證用戶端，包括匿名連線、純文字密碼，或複雜的密碼雜湊和工作階段加密常式。雖然這些方法可以有效保護目錄的內容，但是在使用上卻比較偏向於傳統式系統專屬的驗證機制，而比較不像是一般用途的驗證機制。

由於電子商務以及 Internet 上的通訊逐漸普及，遂使得企業又再次注重一般用途驗證機制，「公開金鑰基礎結構」的技術事實上已成為使用者與應用程式驗證的標準。PKI 尤其適用於分散式運算的環境中，PKI 在多種安全性管理應用程式中是十分重要的驗證工具，例如 Secure Sockets Layer (SSL)、Secure/Multimedia Internet Mail Extensions (S/MIME)、Secure Electronic Transactions (SET)，以及 Java 和 Microsoft ActiveX? 控制項的程式碼簽名 (Code Signing) 服務等，都使用 PKI 驗證。由於 PKI 產品會使用目錄以儲存、分配、尋找和擷取數位憑證和公開金鑰 (在某些情況下也可以用於私用金鑰)，所以目錄在支援安全性管理服務方面也扮演了十分重要的角色。

除了用於儲存和管理 PKI 服務的元件之外，目錄還能以輔助服務傳遞的角色協助其他驗證機制的執行。在 Kerberos 5 通訊協定加密處理的鍵值加密系統中，目錄提供了存放唯一識別碼 (UID) 的位置，並向 Kerberos 服務取得將目錄本身的驗證。此外，因為一般用途目錄已廣為使用，安全性管理員可以藉由目錄的繼承特性，對儲存於目錄中的物件強制套用執行公司企業的安全性原則。

隨著相互操作驗證機制的改良，使用者藉由單一登入取得所有作業系統、服務以及網路上應用程式使用授權的理想，已逐漸變得實際可行。雖然，相互操作的驗證機制在目前仍算是一種開發中的新興服務，但仍然可以藉由中繼目錄服務實作異質環境中的 Proxy 登入，使得目錄服務乍看之下似乎已經採取單一簽入的機制。有關中繼目錄的詳細資料、相關的作業能力以及重要性，會在本章稍後加以說明。

授權

安全性管理服務完成網路上用戶端和應用程式的驗證之後，接下來要進行的是資源存取的授權。在已經過驗證的情況下，會以系統專屬的方式執行作業系統、訊息系統 (例如，電子郵件)，以及其他伺服器的授權 (也就是存取控制) 功能檢查。對於已通過驗證的使用者而言，還會檢查其內部的系統以決定特定使用者所能存取的指定資源，例如檔案系統目錄。然而，隨著一般用途驗證機制的出現，目錄對於存取控制的重要性也將減弱。

目錄支援存取控制的方法有下列兩種：

例如，安全性管理員可能會宣告「會計群組中的所有成員都可以使用薪資應用程式」(All members of the accounting group may use the payroll application) 或是「僅限具備 X 管理薪資等級的員工才能簽核差旅費請款單」(Only employees with managerial salary grades of "X" can approve travel reimbursement forms)。雖然，以上兩個方法都可以代表授權控制的形式，但後者對授權和強制套用原則而言，似乎是一個較為簡單而有一致性的作法。

隨著目錄標準的團體持續研究標準存取控制清單 (ACL) 的各種機制，開發人員有兩種選擇。他們可以撰寫平台專屬的存取控制機制，並建立必須依存於特定平台的產品，也可以撰寫其專屬的目錄啟用，但可由應用程式指定的存取控制機制。

當您必須優先考慮作業平台的獨立性時，上述第二種作法比較具有折衷性，同時可以兼顧使用的方便性 (可以藉重目錄所提供的管理和可調節大小的基礎結構) 以及應用程式的彈性 (允許開發人員自行編輯符合應用程式需求的特定授權需求條件)。從另一個角度來看，撰寫符合作業平台存取控制機制的產品是一種較為省時省力的做法，但缺點在於對某個平台的依存性會造成多重平台上的支援難度。

命名和尋找網路資源

目錄的主要用途和傳統的角色在於尋找功能，而命名和尋找網路資源是目錄在網路上的重要功能。

命名和尋找資源的功能有下列三個主要方面：

標準命名

目錄可以對公司企業建立標準的命名規格。而在命名規格的內容中則提供了可以歸類和尋找的網路應用程式、服務及人員。

標準命名的優點在於區分實體和邏輯。它省略了瞭解網路特性細節 (例如，建築物、路由器、集線器、子網路、IP 位址等視實況而有所不同) 的必要性，命名規格以使用者 (或應用程式) 一目瞭然的文字描述網路的資源。其結果可以讓使用者和應用程式以整體性而非地理區域性的方式，瀏覽網路及其中的資源，使用者和具備目錄啟用功能的應用程式可以在不需明白網路配置細節的情況下，搜尋和找到所需的資源。您只需使用名稱就可以進行搜尋。另一種作法是您也可以指定屬性進行搜尋。目錄的此一功能已將資源從某種特定的拓樸方法中解放出來，並賦予資源與其所在位置無關的獨立性。

位置的獨立性

位置的獨立性對網路的許多方面都造成了深遠的影響，目錄以下列兩種方式實現了 (資源) 位置的獨立性：

雖然，目錄本身並不會包含所有的資訊，但會知道儲存資訊的所在位置，並且會在適當的時機協助儲存資訊的服務套用相關的資訊。此一作業能力同時改善了使用者和系統管理者的作業環境。使用者和應用程式都會有單一的參照點，系統管理員則能以集中方式管理和控制公司企業的桌面、軟體使用授權和資源分配。此外，管理員還能在不須重新設定主要應用程式組態或親自開啟每個桌面的情況下，移動、平衡負載或更換作用中的服務。這種不須重新設定組態處理服務的作業能力，簡化了系統管理員的工作，並使網路變得更加易於管理和設定其大小。

以企業的桌面為例，位置的獨立性代表使用者可以從任何裝置連線到網路，同時保留個人偏好和設定。

目錄也可以讓其他項目 (例如應用程式或網路服務) 找到所需的資源。在分散式應用程式中，指定的應用程式可能需要尋找和使用軟體元件，例如 COM 或 CORBA 物件。在目錄中包含物件的定義、屬性和方法，開發人員就可以開發出以目錄集中管理和修改的分散式應用程式，而無須變更和重新分配主要的應用程式。

同樣地，應用程式也可以在目錄中搜尋其所需的元件，而不須確切地知道這些元件的實際位置。即使該元件的實際位置改變了，應用程式在執行上也不會發生問題。

同質的特性群體

除了提供標準的命名規格和具備位置獨立的特性以外，目錄還可以儲存有關成員和企業組織的相關資訊。此一額外的資訊允許目錄的基礎結構具有群體的感覺，可以提供客戶、供應商、合作夥伴、同事和小組相關資訊，進而產生新的企業使用範例。目錄可以跨越時區和地理區域的限制，包含橫跨內部 Intranet 與外部 Extranet 中所有使用者的參與使用。

在某些情況下，目錄還可以自動加入群體中的成員。例如，公司內的所有秘書或某棟大棟中的所有工作人員。在其他的情況下，使用者可以自行選擇他們所要加入的群體，例如嗜好和興趣相同的好友團體清單。

長久以來，目錄在電子群體中一直扮演著密切關聯的角色；第一個群體軟體 (Groupware) 應用程式 Community 就是以電子郵件為基礎的簡單非同步通訊應用程式。時至今日，同步連線 (即時訊息) 又將訊息系統推向另一個更進步的階段。隨著較高階的即時協同作業的出現，例如：視訊會議、群組編輯工具以及 Internet 電話傳輸等商用產品的問世，目錄將會持續地扮演這些網路服務的會合點，讓人們和應用程式依照名稱和屬性尋找通訊的對象。

異類目錄和中繼目錄

中繼目錄 (Metadirectory) 產品基本上是目錄的目錄，提供總結各種目錄的通用基礎結構，透過單一透明化的使用者介面導向查詢和傳回回應。中繼目錄的功能整合並統一了異類目錄。

在可預見的未來，客戶將需要支援多個目錄，因為很多目錄都提供特定的功能。中繼目錄服務會滿足每個企業目錄產品必須處理的基礎實作問題。

中繼目錄可以透過獨立的目錄服務提供很多優勢給大型且高度分散的組織：

然而，中繼目錄的優點會隨著目錄的數目和/或目錄基礎結構複雜性的減少而逐漸消失。所以必須評估 IT 組織，判斷是否應該實作中繼目錄。

為了能深入瞭解中繼目錄的的技術，本文涵蓋下列中繼目錄的概念：

中繼目錄的同步處理

同步處理可以讓中繼目錄彙總中繼目錄資料庫的內容。

在使用同步處理的方法時，中繼目錄必須和其他的連線目錄建立良好的關係才能相互作業。透過目錄之間的關係進行的管理控制對日常目錄基礎結構的管理上將會是一個重要的議題。經由同步處理和複寫等方式彙整目錄內容的工作，其本身就已經是一項十分具有挑戰性的工作了。主要的問題在於何人建立或刪除了聯結目錄中的物件，以及其所使用的方法為何。

這些都是基本的問題，當問題涉及企業要如何實作和指定控制時，就必須考量中繼目錄服務是否具備足夠彈性的問題。網路規劃人員必須在中繼目錄以及所要相互作業的連線目錄之間建立兩者間的特定關係。

控制物件

企業目錄包含各式各樣的物件。這些物件代表各種資源，包括人員、實體位置、應用程式 (例如資料庫和郵件伺服器) 及系統 (例如伺服器和工作站)。問題是：系統管理員要如何在企業目錄中建立可以代表整個網路上實際存在的物件和屬性？

如果連線目錄從企業目錄集中管理，目錄服務管理員就可以在企業目錄中建立物件。然後企業目錄將這些物件傳播到連線目錄中。

然而，其他部門可能需要在局部管理其他的連線目錄。在這種情況下，連線目錄必須能夠在企業目錄中建立物件。

在其他的情況下，例如使用者識別碼等對應物件可能已經同時存在於企業目錄和連線目錄中。因此，企業目錄必須也能夠在連線目錄的現有物件和企業目錄的物件之間建立穩固的關係。中繼目錄必須具備可以在上述所有情況中建立物件的能力。如果要清楚瞭解這些不同的變化，可以把中繼目錄想成具有下列三種角色中的一個：主要目錄、從屬目錄或對等目錄。

主要目錄角色

在主要目錄角色中，中繼目錄會在連線目錄中建立物件並管理連線目錄。主要目錄角色讓公司可以使用企業中繼目錄來集中管理和控制連線的目錄。下圖說明主要目錄的角色。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 2 主要目錄的角色

在這種情況下，中繼目錄服務允許企業目錄完全管理整合目錄的內容。中繼目錄服務會自動將系統管理員在企業目錄中所做的變更傳播到受影響的目錄中，例如新增和刪除使用者。企業目錄變成用於管理連線目錄的管理工具，進而取代了該目錄或應用程式環境原有的目錄管理工具。

主要目錄的角色事實上引發了一個重要的同步處理議題，例如，如果連線目錄的使用者以該網路或應用程式環境中原本所提供的目錄管理工具在其連線目錄中做了一些變更，則要如何處理同步化的問題呢？在這種情況下，中繼目錄必須再次發揮其彈性處理的作業能力，允許由系統管理員決定所要採取的最佳處理方式。

從屬目錄的角色

有許多的 IT 組織希望集中控制所有的系統，但這個目標通常很難達成。

在許多的企業中，享有自治權的部門和單位都各自掌控著其專屬的系統。對集中化的資訊技術部門而言，強迫這些單位參與資訊技術整合並減低其自治主控權的計劃，幾乎是一件不可能且困難重重的工作。此外，還有一些系統，例如人力資源的資料庫，即使目錄服務管理員必須從中取得一些資訊，也不可能獲得完整的存取授權。

即使在這種情況下，至少要讓某些目錄資訊仍然可以從區域管理的目錄中流向中繼目錄，再由中繼目錄轉向其他連線目錄上的作法，依舊有其重要性存在。舉例而言，有許多公司想要使用 HR 資源資料庫當作是所有使用者物件的主要來源。該使用者物件可以使用原本提供於該網路或應用程式環境中的管理工具予以建立。因此，中繼目錄必須能夠接受在連線目錄中所建立的物件。中繼目錄只要從該連線目錄中匯入這些物件，再將其含括於企業目錄中，然後再視實際需要傳播至其他的連線目錄上就可以了。

中繼目錄會使用其本身的資料存放區同步處理連線目錄中所有的區域性變更，以確保資料的完整性。

在這種情況下，由於只反映了在連線目錄中建立的物件，所以中繼目錄扮演著從屬伺服器的角色。下圖就說明了此一情況。下圖說明這種情況。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 3 從屬伺服器的角色

與對等目錄間的關係

在兩種角色中，中繼目錄或連線目錄都真的會在中繼目錄資料庫中建立物件。在後續維護目錄時，這兩個角色都很重要。大多數企業都已經在很多系統中建立了數個目錄物件，其中很多代表相同的資源或人員。

拿使用者識別碼來做為例子。如果公司有電子郵件、大樓安全識別證和人力資源 (HR) 資料庫，很可能某一名員工會同時存在於其中幾種環境中，但不一定包含所有的環境。也很可能這些系統使用的命名慣例不盡相同。每個個別的目錄也將包含使用者屬性；其中某些將十分類似 (例如地址和電話號碼)，而有些將有差異 (例如應用程式特有的屬性)。

若要期望所有這些連線目錄的管理員變更現有的命名慣例或接受他們需要管理的一大堆新屬性，並不十分合理。這類變更可能技術上不可行，或不實用。例如，某些應用程式特有的目錄無法支援公司可能在中繼目錄中所使用豐富的命名慣例或廣泛的屬性。最佳實務是保留本機命名慣例和目錄結構。

中繼目錄必須能夠在中繼目錄中的物件和不同連線目錄中的現有物件之間建立關係。這種關係通常稱為對等關係或關聯，因為它使現有物件相等或在其之間建立關聯。下圖說明對等關係。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 4 對等關係

例如，中繼目錄可以把連線目錄中使用不同命名規格的物件等同於中繼目錄中的物件，以建立兩者之間明確的固定關係。

再如上圖所示，中繼目錄可以辨識中繼目錄中定義的 Jeff Smith 和 STMP 位址中定義的「jsmith」，以及 HR 資料庫中定義的「Jeff Smith」是同一個人。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 5 對等關係的功能

屬性控制

存在於中繼目錄名稱空間中的物件，視其與連線目錄之間的關係也可以扮演下列三個角色之一：主要、從屬或對等。中繼目錄不會強迫這些物件的屬性要繼承相同的關係。在某些時候，即使中繼目錄對某個目錄上的物件具備主要角色時，連線本機的系統管理員或使用者仍必須該連線目錄的本機上控制物件的屬性。

同時，系統管理員又必須要能彈性控制中繼目錄中的物件屬性。例如，在許多情況下使用者物件的地址和電話號碼屬性最好是可以讓使用者自訂的屬性。基於事實，讓中央系統管理員更改使用者的住家地址和電話號碼似乎是一件完全不合理的事情。

即令是由目錄服務管理員在中繼目錄名稱空間中以集中作業方式建立了使用者物件，然後再傳播至連線目錄上 (從安全性管理的角度來看是合理的)，但仍應該讓使用者自己擁有控制部份物件屬性的權限。此一需求可以在中繼目錄中予以設定，或是在連線目錄的本機上予以設定。下圖顯示了此一層級的屬性控制。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 6 屬性控制

HR 資料庫就是一個彈性屬性控制對企業中繼目錄實作有利的一個例子。有許多公司想要將 HR 資料庫當成是建立使用者的一個可靠來源。當公司僱用新進的員工，並將其加入 HR 資料庫中時，HR 資料庫可以當作是主要物件來看，但事實上是將使用者物件建立於中繼目錄之中。但是，中繼目錄會賦予使用者個人屬性，包含其住址、電話號碼和緊急連絡人等屬性資料項目的控制權。當使用者在中繼目錄中變更這些屬性時，即使此時 HR 資料庫為主要物件，其相關的變更仍然會傳回至 HR 資料庫中。

篩選物件及屬性

不論指定連線目錄與中繼目錄之間所存在的關係為何，有一個必須考慮的重要層面就是有哪些資訊以及有多少資訊要加入中繼目錄之中。此外，一定有一個方法可以控制有哪些 (以及有多少) 資訊要傳播至其他的整合目錄之中。

由於各個物件各有其特定的工作，若要將每個目錄中的所有資訊全部傳播至其他的目錄上並不是一個有意義的作法。專屬於某個目錄中的物件可能對另一個目錄而言是沒有意義的。而且某些連線目錄的物件對中繼目錄而言也是無意義的，傳播這些物件也只是徒增不必要的目錄叢集罷了。有一些資料，例如薪資的資訊或是網路的路由表格，是不需要傳播至其他連線目錄上的。

中繼目錄必須要能控制重要性的等級，並且能夠依個案為基礎進行匯出的工作。其作業上的彈性必須足以包含指定連線目錄中的所有內容，或者是其內容中某個特定的子集。中繼目錄同時也必須能夠讓系統管理員可以選擇性地將中繼目錄中的內容傳播至指定的連線目錄上。尤其重要的是，中繼目錄服務在匯出和匯入時，必須要能夠同時支援物件以及物件屬性這兩個層級的工作。

中繼目錄可以使用由系統管理員所定義的篩選器，篩選所要匯入的物件並且過濾不要匯入的物件。下圖顯示了在匯入時使用物件篩選功能的情形。例如，系統管理員可能想要將 NetWare NDS 中所有的使用者物件匯入至中繼目錄中，但不想將 Netware 儲存於該目錄中的路由資訊也一起匯入。所以中繼目錄必須在進行匯出作業期間支援使用這一類的物件篩選器。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 7 匯入作業期間使用物件篩選功能

同樣地，中繼目錄也要可以使用由系統管理員所定義的篩選器，篩選所要匯入的屬性以及過濾不要匯入的屬性。例如，系統管理員可能想要從 HR 資料庫中匯入使用者的名稱、地址、電話號碼以及其職稱，但是要排除使用者的薪資和福利等相關的資訊。所以，中繼目錄必須要在進行匯出作業期間，同時支援使用這些屬性篩選器。下圖顯示了在匯入時使用屬性篩選功能的情形。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 8 匯入作業期間使用屬性篩選功能

目錄資訊仲介

資訊仲介處理允許中繼目錄以不實際擁有資料的方式存取另一個目錄中的資料。中繼目錄會被當作是所需資料的指標。

同步處理方法提供了一套功能強大的作業工具，在目錄合併時用於處理目錄內容的彙整。由於中繼目錄可以跨越多個位置執行資料的複寫和同步處理、能夠搜尋除了中繼目錄以外的其他核心目錄服務，因此具備較高的效能。透過數個位置進行資料複寫同時還可以避免單一位置系統故障的問題，進而提昇了整體系統的可靠度。

除了上述的優點外，同步處理和複寫並不一定是保持目錄整體性的最佳方法。建立多份目錄資料的副本再透過網路進行複寫，會因為龐大的資料量而導致效率低落的情況，尤其是當所複寫的資料不是使用者經常要存取的資料時，反而造成網路資源的浪費。

解決這些問題的常見方法如下：

舉例而言，LDAP 第 3 版中就提供了用戶端的參照功能。在此作業模式下，如果目錄伺服器中沒有用戶端所要搜尋的資料時，目錄伺服器會將用戶端轉介到另一部伺服器上。而用戶端就可以向所轉介的伺服器提出要求，以自動繼續執行其搜尋的工作。

這些用戶端導向的方法雖然有用，但並不完全符合企業目錄基礎結構的需求。LDAP 的參照方式對於轉介用戶端到另一個目錄的情況固然很好，尤其是轉介到企業以外的目錄而言，但其並沒有解決可以合理化 (複寫) 目錄內容的基礎結構需求。此外，將資料彙總的工作完全轉嫁到用戶端和應用程式上的作法，開發人員仍然存在有令企業組織無法以整合方式管理大量目錄的基礎結構方面的問題。

因此，將中繼目錄當作是資訊仲介的方式遂變成較為可行的方式。仲介 (Broker) 服務同時含有靜態以及動態的作業元件。

靜態的仲介功能基本上就是定義於 X.500 標準中的連鎖 (Chaining) 觀念。連鎖藉由允許目錄伺服器以用戶端或伺服器的身份存取另一個目錄中的資料，而使得與連線目錄的即時連線得以實現。當某個目錄知道其他目錄伺服器中所包含的資訊時，該目錄就能以該目錄伺服器用戶端的身份存取該項資料。下圖說明了這個觀念。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 9 靜態目錄資訊仲介處理

目錄用戶端向中繼目錄伺服器提出要求存取實際上包含於某個應用程式或 NOS 專屬目錄服務中的某些資訊。由於該用戶端已經知道該應用程式或 NOS 目錄中的內容，所以中繼目錄會幫用戶端存取其所需的資訊，然後再將所取得的資訊傳回給用戶端。而此一連鎖的，或稱之為仲介的要求，對用戶端而言為一通透性的要求。

連鎖可以發生在單一目錄中或兩個不同的目錄之間。它完全視所使用的通訊協定為標準通訊協定或是廠商專屬通訊協定的整合式介面。使用此種方式，中繼目錄能以通透方式提供用戶端另一個目錄中的資訊存取權，因而減少了複寫和同步處理的需求。

然而，靜態仲介處理的要求，或稱連鎖要求，並沒有完全解決某些複寫和同步處理的需求，反而有其自身的問題存在。例如，介於目錄間的連線必須為有效而且可用，此外，跨越 WAN 和 LAN 的效能會是一大問題。

如果 WAN 或 LAN 的連結因故停止作用，則將無法透過仲介處理存取所需的資料。難然，資料的連鎖可以解決此一問題，但同步處理副本和同步處理快取內容之間的差異反而又衍生另一個議題。

跨越 WAN 或甚至在較大型 LAN 之間的搜尋作業可以說是問題重重。如果要製作一個含有仲介內容的目錄資訊邏輯集合，以便輕鬆地搜尋整個大型企業的目錄，可以說是一項困難的工作。其原因在於仲介處理的作業模式無法保證其效能的可靠性，以及能夠跨越存取整個 WAN 或較大型 LAN 中的目錄。

資訊仲介處理同時也包含支援較為動態和及時功能的作業能力。當一般用途事件與物件模型結合在一起的時候，目錄服務就可以仲介處理多種的動態功能。應用程式可以登錄某些特定類型的目錄事件，像是登入或變更已知物件中的某些特定屬性。而這些事件又可以觸發某些特定的作業，例如資料庫的查詢或是重新設定與已知路由器或切換器相關聯的參數。

中繼目錄的資訊流

中繼目錄可以和連線目錄進行資料的複寫或同步處理，也可以當做仲介，以透明方式代表用戶端和其他服務存取其他目錄中的資料。

在使用同步處理方法時，目錄服務管理員可以將連線目錄中的內容匯入至中繼目錄中。當資料匯入之後，中繼目錄本身會與連線目錄進行同步處理。而當系統管理員在中繼目錄中做了變更，中繼目錄會將這些變更傳播至連線目錄上。同樣地，當區域管理員在連線目錄中做了變更，則中繼目錄也會反應這些變更。中繼目錄也會視情況，將連線目錄中的資訊傳播至其他的連線目錄上。

在使用仲介處理的方法時，中繼目錄資料庫中的登錄 (通常稱之為別名) 則是提供指向其他連線目錄中資料的指標。當用戶端搜尋所要存取的資料時，中繼目錄就會提供仲介的服務，代替用戶端或其他的服務以通透的方式擷取其所需的資料。

中繼目錄可以同時與多個連線目錄執行這些管理及存取的作業，進而建立一個較其組成目錄總和還大的大型目錄，如下圖所示。

圖 10 中繼目錄的資訊流

一般使用者可以不管資源所在的目錄為何，而直接到中繼目錄中搜尋其所需的資源；使用者也可以視情況許可，在中繼目錄中修改或放置其資訊。

目錄聯結

中繼目錄可以說是組織中所有目錄的聯結。此一「聯結」的功能可以建立組織中所有資源的一個總體藍圖。藉由聯結的建立，中繼目錄得以建立有關組織的一個確切「大型藍圖」、包含組織內的成員以及與其有關的其他資源。

下圖使用人員/使用者物件為例說明這個觀念。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 11 目錄聯結

每一個連線目錄中的物件只定義了某些使用者的觀點以及專屬於該系統的屬性。例如，電子郵件目錄只在 Fred 與電子郵件系統產生關聯時定義 Fred。它並不會去考慮是否在 HR 或網路目錄中已經定義了 Fred 在企業組織中其他方面的關係。另一方面，在中繼目錄中 Fred 的物件完整代表 Fred，從每個連線目錄彙總所有他的屬性，組譯出一個物件代表 Fred 與他和企業的關係。中繼目錄經由兩個目錄整合的方法建立聯結：同步處理和仲介處理。

區域資料集可以支援應用程式，並得以用於進行資料區域控制。不論是從地理區域和商業方面來看，或是從效能和應用程式的觀點來看，此一資料的分配都是正確可行的。

雖然聯結由來自許多來源的資料組成，其虛擬聯結的功能不亞於其為所有資料資訊的實體聯結。中繼目錄資料庫包含來自其他目錄的資料，也可能真的取代某些目錄。也會與存放在其他目錄中的資料進行同步處理。在某些情況下，中繼目錄也可能包含指向其他目錄中資料的指標，而不是資料本身。

目錄名稱空間的整合

名稱空間是一套用於定義如何命名目錄中物件名稱的規則。一般而言，在各種目錄的實作中，最明顯的差異就是名稱空間的不同。例如，目錄會在階層架構中所容許的層級數目以及每個名稱部份的長度 (字元數目) 兩方面有所差異。

為了有效支援各種目錄服務的需求條件，中繼目錄必須在其資料存放區內支援多種目錄名稱空間的使用。尤其是，中繼目錄資料庫應該支援中繼目錄的名稱空間，以及每一個連線目錄成本所使用的名稱空間。

中繼目錄名稱空間實為企業組織中所有目錄的一個交集點，從此一交集點開始，進而形成企業或是全球性的一個全域目錄。

除了中繼目錄的名稱空間以外，每一個連線目錄各自有連線目錄的名稱空間。瞭解連線目錄本身和中繼目錄資料庫中連線目錄名稱空間兩者之間的差異是一個十分重要的觀念釐清。中繼目錄資料庫中的連線目錄名稱空間包含連線目錄中部份或全部的內容，而連線目錄則是使用者真正擷取資訊所在的目錄。

每個連線目錄名稱空間只包含來自連線目錄特定類型的物件和屬性。換言之，每一個連線目錄名稱空間只會支援原本用於建立內容的環境所使用的名稱空間。下圖說明了此一觀念。

圖 12 多重名稱空間的支援

您可以將各種不同的名稱空間想像成是中繼目錄資料庫中不同的資料「檢視方式」。而中繼目錄名稱空間則是由系統管理員設計用於提供企業目錄的一個內含式的檢視區域。各種連線目錄名稱空間提供了中繼目錄資料庫中各個特定類型物件和屬性的一個獨佔檢視方式，且與連線目錄中這些物件和屬性的呈現方式一致。系統管理員所看到的連線目錄名稱空間的內容將會與顯示於連線目錄本身中的內容完全相同。以下即為使用連線目錄名稱空間的主要理由：

試想系統管理員使用中繼目錄管理連線目錄的情況。如果該連線目錄發生了問題，系統管理員並不須深入處理整個中繼目錄的名稱空間，而只需單獨處理該連線目錄就可以了。系統管理員可以從中繼目錄看出發生問題的位置，然後直接去處理問題。連線目錄名稱空間可以讓系統管理員處理中繼目錄中特定的系統子集。

在完全啟用目錄管理的作業模式下，必須支援多重名稱空間。多重名稱空間的支援提供系統管理員在實際將物件整合到中繼目錄名稱空間之前，能有一個放置連線目錄物件的位置。而系統管理員即能以連線目錄的原生格式，檢視連線目錄以及中繼目錄的名稱空間。例如，當中繼目錄啟動執行時，NOS 和特定應用程式的目錄就會以一次一個的方式，逐漸整合到中繼目錄中。系統管理員就能以不損害中繼目錄的方式，將目標目錄的內容整合到中繼目錄的名稱空間之中。

對使用集中式目錄管理的作業模式而言，多重名稱空間的支援也是必要的。由於同時可以支援中繼目錄的名稱空間以及每個連線目錄的名稱空間，使得中繼目錄資料庫中可以包含原本不存在於中繼目錄名稱空間中的目錄物件。在不將這些物件傳播至其他的連線目錄的情況下，中繼目錄確實提供系統管理員一管理連線目錄名稱空間中物件的位置。

身分識別管理的問題

中繼目錄同時也提供了一個解決身分識別管理問題的方案。本章節中的資訊延續前一章節的討論。

如下圖所示，身分識別為有關人員、應用程式以及散佈於整個 IT 組織中目錄和資料庫內各項資源的資訊摘要。以與人員有關的身分識別資料為例，計有名稱、信箱、薪資以及職稱。應用程式的識別資訊則有可以讓用戶端找到伺服器所在位址的網路位址。此外，還提供了一份該應用程式所提供的服務清單。網路資源，例如印表機，也一樣有識別的屬性：所在位置以及其所支援提供的列印功能。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 13 身分識別管理工作上的挑戰

身分識別管理工作上的挑戰

由於身分識別資料的種類繁多，而這類資料駐留的位置不只一個，引起了幾個管理工作上的挑戰：

通用身分識別管理的方法

大多數的大型公司已經開始注重某些形式的識別管理專案；常見的做法有：

全域通訊錄應用程式。 同步處理公司內不同電子郵件目錄之間的信箱資訊，以便讓使用者能找到寄信的對象，並可以透過不同的系統傳送郵件。

僱用/解僱方案。將新進員工的相關資訊傳播到所有的系統上，以便系統使用識別資料快速建立所需的相關服務，當員工離開公司時，為了防範安全性方面的漏洞，系統也必須能夠快速地執行反向程序。

電子商務應用程式。 啟用同步處理以處理位於防火牆外的企業目錄識別資訊，例如 Extranet 的使用者以及供應商的數位憑證。

單一簽入。 管理許多不同平台和應用程式上的使用者名稱、密碼以及存取權限的資訊。

方案需求條件

以往曾經有許多公司嘗試建立保有所有企業識別資訊的單一目錄，絕大多數的案例都是失敗的，以下歸納出幾個簡單的原因：

這樣說來，識別資料仍然會繼續地存在於多個分散的位置，公司也仍然必須繼續尋求讓不同目錄服務和應用程式儲存機制協同作業的可行方法。假設必須同時存在許多識別儲存機制，一個好的識別管理方案必須有下列功能：

連接的需求條件

能夠連線愈多目錄服務、資料庫和應用程式的識別管理方案，代表解決方案的功用愈強。如下圖所示，儲存機制可以取得另一個儲存機制上的未知資料。如果識別管理方案具備下列作業能力，就可以連接到另一個儲存機制：

圖 14 連接的需求條件

全方位的方案應該能用下列方法連接到資料：

資訊管理流程

資訊管理流程是管理儲存機制間識別資訊流動的程序。為了管理儲存機制間識別資訊的流動，資訊管理流程必須能夠：

事件變更處理

任何時候，只要系統管理員、使用者或應用程式新增、刪除或修改儲存機制中的識別資料，就表示事件發生變更，原先未管理的識別資料會很快地變成未經組織的資料。因些，識別管理方案必須具備偵測變更、執行必要的資料格式轉譯，然後更新所有受影響儲存機制的功能。例如，當系統管理員在人力資源 (HR) 資料庫中增加了一個新進員工，這個變更事件必須讓該新進人員所使用的系統做出相關反應。下圖中，該變更會傳播到其他的目錄和應用程式。

圖 15 變更事件的處理

資料彙總功能

由於識別資訊存在於大多數企業的整個環境內，含有許多其他儲存機制識別資料彙總的目錄就更有價值。此一中繼目錄的觀念是由 Burton Group 所首創，該組織使用「聯結」(Join) 這個名詞代表企業識別資料的一個彙總觀點。

藉由中繼目錄的使用，應用程式可以在一個位置上使用單一存取方法和安全性模式，而不是使用來源儲存機制互動的方式，存取各式各樣的資料。

由於中繼目錄中的資料能以索引形式儲存，所以同時也可以發揮最大的效能。由於不需前往資料的來源處取回資料，所以可以避免在執行時期 (Run Time) 透過廣域網路 (WAN) 與資料來源進行連線的可能情況。若要發揮最高的功能，資料彙總必須具備下列作業能力：

圖 16 中繼目錄中的資料彙總

追蹤相關的物件

當系統管理員在佈署識別管理方案時，必須告訴識別管理流程引擎：Jeff Smith、jsmith 和 smithj 其實全代表同一個人。如下圖所示，而當識別資料進行定期重組之後，引擎還必須能夠追蹤其間的關係。方案不能因為樹狀目錄結構中發生位置變更的事件，而無法追蹤使用者的相關識別資料 (例如使用者從會計部門調至銷售部門)。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 17 相關物件的追蹤

整合性管理

整合性管理是確保識別資料不會損毀，或防止變更導致儲存機制不同步的程序，整合性管理必須具備下列功能：

擁有權

企業識別管理中很重要的一點在於擁有權的關係辨識，而且必須維持存在於應用程式與資料之間的關係。例如，某人的信箱名稱為架設該信箱的電子郵件系統所擁有。在大多數的公司中，HR 系統會同時保有現職和離職員工的相關資料。如果沒有適當的企業識別管理基礎結構，由於沒有其他的應用程式可以存取和更新電子郵件和 HR 的資料，則依預設會保留這些擁有權的關係。然而，如果有部署使用適當的同步處理連接器和資訊流，情況就不一樣了。

如下圖所示，這裡信箱資訊會透過某種連接器與 HR 的目錄進行同步處理。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 18 擁有權關係的管理

如果該連接器並未正確設定，使用者可能會在 HR 系統中變更其信箱的屬性，而連接器會覆寫電子郵件目錄中信箱的值，因而造成令人費解的困擾。解決這個問題並不想像中那麼單純，只需防止變更回寫至電子郵件的目錄中就可以了。HR 系統可能擁有該項資訊，例如當該員工上級經理的名稱發生變更時，就必須將這項變更資訊回寫至電子郵件目錄中。

其他的屬性，像是員工的辦公室編號，並不見得會有明確定義的擁有權，而應該屬於任何人均可以變更的資料。

由於擁有權是方案的必要條件，系統管理員必須在屬性層級中定義並強迫擁有權的關係，依照擁有權規則進行和產生的變更可以通過，否則就會將變更終止或駁回。例如，當某位員工變更了 HR 目錄中的信箱屬性，識別管理方案就會將屬性值設回電子郵件目錄之中。

錯誤管理

識別流程管理技術的主要條件，就是具備將變更傳播至多個儲存機制上的作業能力。但是當引擎進行多重更新時，必然存在更新失敗的可能性，進而導致不同儲存機制中出現資料不一致的情況，如下圖所示。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 19 錯誤管理

例如，當某位員工的職稱、薪資和公費支用上限發生變更，但中繼目錄卻無法更新應用程式中的使用者職稱時，就會造成識別資料出現令人困擾的情況。此時系統管理員必須調查問題發生的原因，並進行修正的工作。

在資料庫系統中，這個問題可以藉由「異動」的方式解決，交易可以確保所有的更新均順利執行，或是以單元進行復原。不幸的是，大多數的目錄服務和應用程式發展介面並不支援資料庫的異動功能。這表示識別管理方案必須以其他方式解決這個問題，例如使用登入狀態探尋機制，持續地要求變更直到變更確認為止，以確保所有的儲存機制均達到反應變更的狀態。

參考完整性

另一個同樣對資料庫與識別管理方案都造成困難的問題，就是維持儲存機制之間的參考完整性。參考完整性可以視為是維持不同位置上相關資料組成值之間關係的必要措施。例如，識別管理方案必須能夠確保列於人力資源資料庫中員工的職稱，與採購系統中同一位員工支用上限是一致的。資料庫解決這個問題的方法是使用預存程序和觸發等功能，讓系統管理員在每次資料值變更時執行商業的規則。

今日的目錄服務尚無法提供類似的功能。因此，識別管理方案必須具備執行商業規則的作業能力，也就是拒絕執行不符合參考完整性要求條件的變更。事實上，也只有中繼目錄方案可以滿足上述所有的需求。

如果 Internet/Intranet、專屬的電子郵件，以及其他的目錄中，只包含像是位於某處的某人之類的識別資訊，則中繼目錄就可以含有關於任何地方的任何人的識別資訊。基本上，中繼目錄可以讓您整合任意數量的異質識別儲存機制，而且幾乎沒有格式限制的問題。因此，中繼目錄是企業內識別資訊的物件根目錄。中繼目錄提供合理化且統一化的識別物件檢視區，而且該物件含有各種目錄中的屬性。此一整合的結果可以降低管理的成本、減少重複性、降低不一致的情況，並且讓識別資訊更容易取得。中繼目錄具備足夠的彈性自我調整以適應企業的組織、結構、政策以及管理風格等方面的需求；而且擁有足夠的動態性以因應變更。

來源

中繼目錄從公司企業內部的其他連線目錄以及儲存機制中收集識別資訊。近來，所有的電子郵件、資料庫以及其他的目錄應用程式都可以匯出內容。而中繼目錄可以透過檔案交換、電子郵件，或直接在線上以通訊協定所驅動的傳輸方式收集這些資料，系統管理員以及一般使用者可以自行加入其他的中繼目錄識別資訊。

內容

目錄通常被視為包含人員的識別資訊，例如電子郵件地址，不過這個觀念十分狹隘。中繼目錄可以包含更多真實世界中的各種物件。這些物件可能是：

中繼目錄唯一的要求是這些物件必須是以某種階層結構組織過的物件。例如，某位成員可以描述成存在於 Internet 或國家/地區中，某個企業組織中的某個部門內的一員。或者是，在某個多國組織的企業中，某位員工可能是企業組織樹狀目錄中，某個國家/地區內某部門中的成員。

員工不一定必須位於階層架構中最低層的位置。例如，配屬於某位員工使用的筆記型電腦或是文件，就可能位於企業樹狀目錄中員工以下的一個目錄項目。

管理

中繼目錄內容以及安全性的管理可以是集中式、分散式，或是兩者合併的方式。可以將中繼目錄設定成將某些項目的變更限定於只發生於連線目錄上，然後再另行匯入中繼目錄中。而其他項目的變更則可以先發生於中繼目錄中，然後再傳播到其他的連線目錄上。不同的人員可以管理中繼目錄的不同部份。此一層級的控制，不僅擴展了項目本身，而且還擴展至各個單獨的屬性上。因此，一般使用者可以自行管理其專屬的識別資訊，例如：電話號碼或地址等。中繼目錄並不會強制使用任何管理模型。它可以讓您建立一個可以實際符合您企業組織、安全性要求以及存取控制需求的目錄。

精確地記錄目錄服務的部署是管理、支援、操作和維護目錄方案的基礎。在您可以有效管理、操作、支援或維護所有的工作之前，必須先瞭解工作對象的本質、操作的方法、分工的權責以及正常負荷下的功能運作。

六個 Sigma 值，節錄自 Mikel Harry 和 Richard Schroeder 所著的一書 (Six Sigma.Doubleday Press，2000 年 2 月) 有以下的陳述：

這些值代表您必須瞭解所擁有的東西，所得到的相關值才能以有意義的方式影響您的看法和做法。這些值 (答案) 同時也解釋了 IT 資產所應付的責任。以下章節會討論文件的記錄及操作。

操作及記錄

精確地記錄目錄及其支援服務是很重要的。完整而精確記錄目錄的架構和結構描述是維護健全目錄的第一個步驟。

記錄並不是一件只做一次的程序；目錄記錄是一項活躍的工作，一旦有變更發生，就必須隨時更新。除了一般公司目錄管理的每日例行性的需求外，每當遇到商業上的新品採購和舊品停用時，就會出現影響比較大的問題。

良好的記錄提供許多好處：

作業小組所建立和使用的記錄通常可以依照其來源，例如硬體和軟體廠商、服務台、應用程式開發和支援等加以分類。

明確指出目錄架構中所要記錄的各個相關組成是很重要的。而這些工作至少應該包括 (但不限於) 下列事項：

下列範例列出了必須包含的項目。

硬體和軟體廠商的手冊

保存和維護目錄產品與方案的所有廠商產品手冊 (硬體和軟體皆同) 都是很重要的。您可以將這些文件儲存在支援企業的文件庫，讓所有負責操作、管理或維護目錄的個人、群組或部門可以自由存取。同時，隨著軟硬體的更新保持這些文件處於更新的狀態也是必要的。

操作手冊

操作手冊會依群組的工作目標而有不同的形式。在下一個章節中，我們會列出幾個範例，說明如何依照群組的需求，將文件編譯成其所需的工作手冊。

服務台

舉例來說，假設有一個服務台 (Tier-1 支援) 負責回應客戶的問題，並當作是監視系統中的高階監視者。則必須為這個群組建立一套詳盡的文件。文件應該包括：

當然，這完全需視服務台的能力、企業組織的大小，以及是否有其他的支援群組監視和反應目錄問題等因素而定。

目錄操作

目錄操作 (Tier-2 支援) 為負責伺服器維修、備份與還原、監視 (效能、健全程度等) 的群組。

目錄操作應該提供清楚、一致和最新的手冊，其中詳細說明：

目錄架構

目錄架構包含系統架構設計師、工程師和協力廠商顧問或系統整合人員，協助目錄的設計、部署、支援和更新等事項。這個群組必須能夠取得正式操作手冊中的下列資訊：

您所建立的支援組織並非與上述的範例完全相同，但重要的是一定要讓每一個支援層級都有最新的資訊，才能在最佳的狀況下工作以支援目錄方案的正常運作。

從細節以至總體的文件 (實際的設計)

先瞭解目錄部署的實體配置 (架構) 是很重要的。如果某人有一個以上的目錄，而且想邁向中繼目錄方案以簡化和集中管理，並且合併一些服務以便更有效地支援具備目錄啟用的應用程式，則必須小心地記錄此一範圍內所有的目錄方案。

最有可能協助進行此一步驟的助力，應該是像系統整合公司、加值轉售業者以及協助初始設計和部署的顧問或目錄廠商等公司團體。最好的情況是得到實體設計 (基礎結構設計、架構配置、伺服器位置、服務等) 的圖表，作為目錄設計與部署交接的一部份。如果沒有的話，最好向相關人員取得該專案所有或任何的相關文件。

有許多種工具和公用程式可以協助製作目錄方案的圖表。舉例來說，多年來大家都使用 Microsoft Visio? Technical Edition 繪圖和圖表軟體，建立電腦繪圖和網路部署。雖然這是絕佳的選擇，仍然有很多其他可用的程式可以做出很好的圖表，而且也十分容易使用和更新。不論如何取得這些資訊，最重要的是資訊必須精確並維持最新狀態。

從總體到細節的文件 (邏輯設計)

瞭解目錄中資料的邏輯流向 (處理序、應用程式、自動化工具等) 如同瞭解實體設計 (伺服器在網路上的位置) 一樣，是同等重要的。如果無法確切知道目錄實體和邏輯方面的工作方式，將無法主動積極地監視效能、整合性與可靠度等方面的指標。此外，遭遇問題時，也將無法精確地進行疑難排除的工作。

已經將實體架構記錄於圖表之後，接下來要做的就是回到記錄文件的工作上：

除了記錄目錄組成的所有處理元件之外，還必須深入對照瞭解資料如何經過系統，以及目錄處理程序和應用程式之間的相互關係。若要深入瞭解哪些是要記錄至文件中的重要資訊，至少應該知道下列資訊：

監視目錄元件為什麼要監視？

對已部署的目錄方案而言，監視是其健全狀況的唯一指示。經驗證明不主動開始監視的公司「一定」會遭遇危機 (可以預見並避免的災難)，而且很快就會進入不佳的狀態，常常需要回應客戶遭受故障或服務中斷影響的問題。客戶或一般使用者報告服務中斷的次數有多少 (通常是打電話到服務台指出連線或存取系統或服務時發生了問題)？其實您只要花一點心思和時間建立主動監視配置，就能節省許多時間和金錢，並且能大幅提高客戶的滿意度。

目錄是運算環境的核心和靈魂、讓客戶使用登入網路、驗證，以便存取服務和應用程式，並查詢網路上的其他使用者和資源。這些核心目錄服務如果中斷，會導致使用者和應用程式無法存取，也會造成生產力和金錢的損失。

藉由監視目錄，您可以在發生中斷時立即得知，在某些情況下甚至可以預見中斷的狀況。利用更精密的監視工具，您還可以預見故障、瞭解降低效能的位置，並將擷取到的資訊用於系統調整。

監視系統有三個元素：

下圖介紹這些元素，詳細內容詳述於後。

如果您的瀏覽器不支援內嵌框架，請按一下此處，在單獨的頁面檢視。

圖 20 現用監視系統的元件

裝置及應用程式檢查。這是負責定期檢查受監視的服務、裝置、主機、應用程式或其他系統狀態的功能或處理序。定期檢查時，如果裝置沒有回應，會發出警示並指出失敗的裝置及失敗原因。

事件關連模組。這個元素負責接收檢查模組的輸入內容，並且根據這些內容找出主要原因。接著會抑制其他事件可能造成的任何事件，例如路由器失敗可能會影響所有主機、系統或裝置對該裝置的傳輸，導致暫時無法使用。抑制間接事件後，模組會建構一或多個警示，轉寄給通知模組。

通知模組。這個模組收到關連模組傳來的警示後，會向適當的 (預先撰寫程式) 負責人或負責單位發出通知這個模組也可能會通知預先撰寫程式的自動回應系統，重新啟動失敗時要執行的指定服務或其他修復動作。

上圖的監視系統，是一個概念模式。工作人員或軟體應用程式可以執行任何模式元素。它的目標是儘可能自動執行這些元素，形成一個有內聚力而且可預測的解決方案，以滿足特定的監視需求。

基本上有三種監視器：硬體錯誤監視器、軟體錯誤監視器以及效能監視器。

硬體錯誤是硬體或網路故障後發生的直接結果 (也就是說，目錄伺服器當機或遺失磁碟後，導致目錄功能或服務的損失)。

軟體錯誤通常是程式設計或資料問題造成的，會使目錄中的資料不正確或不一致。

效能監視器提供系統效能的寶貴意見，可以識別瓶頸、競爭點和效能降低。效能監視器也能提供基本資訊，並讓您擷取有用的趨勢資訊，協助瞭解何時可以規劃容量或升級目錄基礎結構。

許多商用監視系統包含了前述全部的或大部分的核心元素。選擇解決方案時，必須考慮下列因素：目錄解決方案、產品、組建方式 (集中或分散)，以及管理與客戶的服務層級合約。

實作監視有好幾種方法，本節討論經過證實、最受歡迎的方法。

簡易網路監視通訊協定 (SNMP)。雖然 SNMP 主要是管理網路硬體，例如切換開關、集線器及路由器，但也能監視及管理伺服器及其他支援裝置上執行的應用程式及處理程序。SNMP 可以讓管理應用程式監視網路上的實體狀態，發生事件或發生錯誤時 (例如伺服器突然中斷處理)，也能透過 SNMP 設陷機制，非同步通知管理應用程式。

LDAP 檢查。監視目錄最直接而有用的方法之一，是從用戶端連線發出 LDAP 指令和/或要求進行檢查。例如，簡易檢查工具可以連線到目錄，搜尋預定的項目 (特別為這個目的建立的項目)。如果在預定的回應視窗中回應，就表示目錄運作正常，否則檢查工具會發出錯誤 (或是警示、自訂通知)。

作業系統特定檢查。現在的作業系統大多有工具監視自己的服務，原生目錄服務也包含在內。這種類型的資訊可以協助判斷目錄服務何時因作業系統而發生問題。

間接監視。 監視直接觸及 (使用或存取) 目錄的應用程式，可以讓使用者更清楚瞭解系統的回應性及信賴性。

記錄檔分析。您可以自動掃描能夠指出錯誤狀態的目錄事件記錄檔。此外，您也可以監視一些能夠指出效能問題的狀態。記錄檔分析也能用於主動監視。

本節詳細介紹監視目錄的幾個基本原則及概念。

小心監視

您必須瞭解監視策略的含意。設計不良或執行不當的解決方案，反而會影響目錄解決方案的效能或操作。一般而言，允許擷取所需資訊時，您應該小心製作解決方案。

如何小心製作解決方案？執行解決方案時，除了提供所有所需資訊之外，還應該力求輕簡。例如，檢查時只需抓取能夠指出目錄正在運作的單一項目即可，不必抓取太多項目。此外，檢查的頻率也以能夠提供足夠的回應為基準。這樣可以減少目錄的其他負擔，也有助於減少服務的其他負載。每 5 秒檢查目錄雖然可以加速傳回失敗資料，但會增加服務的負擔。通常每分鐘或 15 分鐘檢查一次最為適當。當然，檢查頻率需視現有的服務層級合約而定。

串連式故障

如果發生故障，可能會在監視方案中觸發其他警示。例如，如果一組複寫的目錄伺服器故障，可能會對其他伺服器造成額外負載，使得運作中的伺服器產生警示。如果發生這種情況，您可以使用的回應方式是停用非關鍵的服務或應用程式，以減少剩餘伺服器上的負載。此外，重新檢查容量能力，以主動在事件再度發生時提供空餘空間。

維護問題歷程記錄

設計監視作業，以提供事件和問題的正確歷程記錄。例如，您可以使用一般以標準格式記錄事件的網路管理和監視系統，並定期抽取與目錄相關的項目，在中央位置編譯和保存記錄以便定期審查。這些抽取出來的記錄提供重要的趨勢資料，協助識別重複發生的問題 (良好的因果資訊)、協助容量規劃，並提供與目錄系統整體可靠度和可用度有關的完整資訊。

維護書面計劃

最後，您需要針對每個失敗、事件或問題的類型或例項，建立書面計劃以提供即時、正確、一致而且可以重複使用的回應。其中最重要的是「可以重複使用」。因為如果您花費了大量時間精力取得事件資訊並規劃問題解決方案，但這些事件及問題可能是不會再發生的，那就相當可惜。

通知技術

擷取即時事件資訊之後，如果未能通知負責單位執行計劃，也是枉然。事件通知，必須完成 4 個重要目標：

發生問題後，系統應該通知負責處理問題的一或多個人員。這些人員通常屬於較高層級，例如負責設計及部署解決方案的系統架構、工程師或諮詢顧問。也可能是受過訓練、能夠處理目錄中斷事件的系統管理者或技術人員，視問題的性質與嚴重性以及處理事件的能力而定。這種通知通常屬於「急件」，尤其是 24/7 操作的重要目錄。這種情形通常用電話或呼叫器通知。

通知系統也應該通知負責管理目錄的小組。這種通知屬於告知性通知，可能會透過電子郵件告知負責小組發生的問題以及處理情況。負責處理問題的人員以及提供系統管理支援的小組之間，必須密切協商，這點十分重要。

使用者和客戶可能也需要知道中斷的情況，不過您一定不希望最先通知問題的人是客戶或使用者。雖然客戶不需要知道問題的詳細內容，但最好還是通知客戶中斷 (或預期中斷) 的情況，並提供相關的注意事項。通知可以透過電子郵件傳達，如果電子郵件系統受到影響，您可以在網頁上公告系統中斷資訊、透過通用電話語音郵件訊息，或通知服務台在客戶來電要求協助時傳達這項資訊。

當發現事件並以適當方式通知適當人員後，應該採取下列行動：

雖然這是基本常識，但卻經常因為不變的危機模式或資源限制，而忽略了這個重要的階段。但如果您執行了本文其他幾節介紹的前置步驟，就能完成大部分的工作。

除了分析主要原因，日常的操作技術中已經包含長期及永久解決方案所需的大部分工具及技術。如需有關如何採取適當的行動，請參閱本文件的＜管理目錄＞和＜維護目錄＞兩節。

管理目錄解決方案和隨時提供安全有效的軟硬體元件操作有關。硬體及軟體元件的安全性尤其重要，這方面在 MOF 安全性文件中有詳細的介紹。

目錄服務架構有兩個基本範圍：實體 (硬體) 元件及程式 (軟體) 元件。主動管理具有信賴性、可用性、可支援性以及可預測性等優點。下面幾節將探討如何管理目錄硬體及軟體，並瞭解這些優點。

硬體管理和前面說明記錄目錄架構的章節相關。如前所述，管理系統時必須知道系統的位置、功能、資源依存性，以及與其他處理程序、功能或應用程式之間的關係。如果您還尚未完成管理計劃中的說明文件階段，請先完成這個部分，然後再嘗試執行本節介紹的軟硬體管理處理程序。

這個主題也涉及監視，能夠主動管理硬體以及監視系統狀況，二者同等重要。

軟體管理也與先前說明記錄目錄架構的章節有直接的關聯。如前所述，未知的系統是無法管理的，如果尚未完成管理計劃的記錄階段，請先結束該程序，然後再嘗試本節說明的軟硬體管理處理程序。

正如上面摘要的硬體管理，軟體管理也涉及監視，能夠主動管理程式元件以及監視系統狀況是同等重要的。

簡言之，管理目錄服務硬體就是瞭解現場、作業內容以及部署的運作情形。同時也必須能在發生問題時，分層處理可用的支援資源，也就是根據您的架構以及可用的支援群組，定義分層支援系統。設計目錄的支援模式時，必須注意下列幾點：

維護目錄

本節會詳細介紹維護目錄以及支援目錄的服務的處理程序。管理計劃的這個階段，詳細說明運用備份及還原以保護目錄的每日資料處理程序，同時也指出損毀修復的較大問題。損毀修復計劃必須具備步驟、處理程序以及包含損毀準備、損毀防止以及損毀修復的規範。用這種方式規劃，也許不需要用到計劃中的修復部分。

目錄資料對組織的基本操作及生產力而言十分重要，如果目錄因故無法使用 (例如裝備失敗、資料毀損)，商務將會遭受生產力及財務上的損失。為目錄和支援的系統元件開發健全的備份和還原程序，可以確保重要的目錄資料和設定資訊不會遺失。

備份和還原程序本身的開發也有同等的重要性。如果只是簡單的磁帶備份處理程序，沒有專人定期測試簡明完備的可執行還原計劃，當您在事情發生時才開始詳細研究時，可能會遭受資料流失或是嚴重的系統中斷。

目錄資料和檔案系統一樣，儲存在磁碟機等大型存放裝置中。下列因素會導致資料損壞：

如果上述事件影響了目錄，就需要一個方法恢復原來的生產操作狀態，您可以從完整目錄的備份還原目錄 (資料和設定) 進行這項工作。

備份目錄有兩種方法：

使用傳統媒體備份及還原

就像存放在磁碟子系統中的檔案系統，目錄資料及設定檔案可以備份到磁帶等的傳統媒體上，也可以備份到本機或網路上的個別磁碟機。這些備份可以用於還原服務中斷時遺失或損壞的資料。

備份目錄與備份檔案系統有下列差異：

除了上述磁帶媒體，您也可以使用磁碟對映技術保護資料。對映技術是同時將資料寫入主要磁碟和次要磁碟的技術。萬一主要磁碟失敗，還有次要磁碟做備份。

在媒體和技術之外更重要的一點是您使用的媒體必須能夠定期離站傳輸。如果備份也在災難中損毀，就失去了意義。

使用複寫技術備份及還原

雖然傳統備份和還原技術可以保護資料不遺失，但卻有重大的缺點：還原大量資料可能需要好幾個小時。由於實際執行系統無法及時上線，可能就無法配合已對客戶或使用者做出的可用性和可靠度承諾。使用複寫做為提供資料容錯和冗餘的方法，或許可以協助避免傳統還原技術無法避免的昂貴停機時間。

副本是目錄資料的線上拷貝。萬一發生伺服器故障，在修理故障的伺服器時，對等副本會提供持續的服務和資料存取。伺服器復原時，就可以上線工作做為副本伺服器。如果副本設計包含了適當的容量 (伺服器的數目和如何在架構中分散伺服器)，使用者將不會因單一伺服器故障而受到影響 (事實上使用者應該不會注意到發生了問題)。

目錄複寫還有其他的優勢：因為目錄複寫通常是最新的，您不需要擔心復原的目錄副本太舊，也不需要執行累加式更新或重新同步處理其他目錄的副本。雖然這是個明顯的優勢，但必須注意的是，在目錄的變更存放在某個副本上一段時間後，再傳播到其他的副本伺服器時，大多數目錄支援會「失去」一致性。它不保證所有副本隨時都有最新的變更內容。副本資料的一致性及同步處理是屬於設計問題，視特定的效能需求而定。

複寫有兩種形式：單一主機及多重主機。單一主機操作只有一個伺服器 (主機) 接受目錄變更，其他都是唯讀副本。一旦主要伺服器失敗就無法變更目錄，只能等待主機還原，或將另一個副本提升為主機 (假設目錄解決方案支援提升)。

多重主機是比較靈活而且有效的解決方案，失敗時修復也較為容易，因為每個副本都能接受及處理目錄變更。多重主機環境中的一個主機失敗時，只需離線修復，修好後再重新建立成副本即可。

複寫提供最佳的即時線上資料保護，而傳統備份提供最佳的完備修復，例如站台發生損毀時，或是能夠修復損壞或錯誤的目錄資料。

最好的作法是結合兩種技術，形成完備靈活的資料保護措施。目前的分散式目錄技術是使用複寫執行整個網路的同步處理及更新、載入平衡以及容錯。如果能夠定期統一製作整個目錄及設定資訊的傳統媒體備份，更可以提供必要的保護。維護這些媒體離站副本，可以在遭遇任何損毀時確保恢復完整的工作狀況。有些公司有自己的離站存放裝置及磁帶輪換、整理及傳遞服務。其他公司則付費委託協力廠商提供這些服務。無論您決定如何處理，立刻採取行動吧！

規劃的第一步是評估目前及預期的工作狀況。做好這個步驟之後，您應該能夠輕易地回答協助評估資料保護需求而設計的下列問題。

疑難排解目錄架構

在使用的過程中，目錄經常會發生錯誤。視問題的類型及嚴重性而定，您可能會遭遇輕如效能降低，重如整個目錄服務失敗的問題。發生問題時，您的目標是把損壞降到最低、儘快讓目錄回到完整服務，以及瞭解問題以防止再度發生。

目錄問題可以分成三個類別：

本節詳細介紹這 3 種問題，希望能幫助您瞭解並且以有意義的疑難排解，主動回應問題。

首先：排解疑難之前，必須先瞭解目錄的問題所在。下面介紹幾個一般使用目錄服務探索問題的方法：

上述一方、多方或各方，可能會同時偵測及報告同一項失敗。例如，目錄伺服器無法使用時，網路管理或監視解決方案會立即報告問題，使用者也可能同時連絡服務台。如前所述，使用者可能報告的是相依服務的存取問題。

操作人員可能報告的是執行排程維護或資料更新程序的問題。探索任何事件的問題時，必須結合各方事件，找出影響相依處理程序的問題根源。

在理想的情況下，您應該盡量減少使用者發現和報告問題的可能性，這可以透過良好的設計、周密的監視及通知計劃而達成。審慎規劃的回饋是相當可觀的。

發生問題時，您應該適當地連絡使用者、服務台、操作人員、系統管理員以及受影響系統的服務層級合約的管理人員。理想的連絡方式為：

發生一個問題。

事前做好規劃，失敗或中斷時，就能通知所有受影響的或是相關的單位。一般採用的方法有在網站上發佈中斷資訊、透過電子郵件傳送通用或群組/應用程式專用訊息、向 Usenet 新聞群組公佈中斷資訊，以及透過錄製的電話訊息提供狀態資訊。

本節前面曾經提過目錄問題基本上可以分成 3 種，下一節將深入探討這些各種問題類型，並提供一些主要原因及解決方案。

第 1 種問題類型是目錄中斷。無法使用部分或全部的目錄服務時，目錄就會中斷。當網路發生問題而無法找到一或多個目錄伺服器，或目錄伺服器的軟硬體失敗時，就會發生這種問題。中斷後，使用者就無法接收服務。

目錄中斷原因

目錄中斷的原因可以分成 2 大類：硬體失敗及軟體失敗。可能失敗的硬體包含網路元件 (路由器、開關、網路介面卡、電纜線等) 及伺服器元件 (處理器、記憶體、磁碟系統、電源供應器等)。也可能因為斷電而發生中斷。

軟體失敗有作業系統或是支援目錄的程式、應用程式及服務。目錄伺服器上執行的其他軟體失敗時，也可能造成目錄服務中斷。

目錄中斷的含意

目錄中斷後，使用者及?用目錄的應用程式就完全無法接收目錄服務。這是因為 LDAP 是主從架構通訊協定，這項失敗會被視為無法連線到目錄服務。目錄中斷會出現 3 個基本徵狀：連線等候逾時、拒絕連線以及連線沒有反應。

解決目錄中斷

如果是硬體失敗造成中斷，一般的處理方法是更換失敗的系統後再重新啟動。例如，電源供應器失敗導致中斷時，只要更換失敗的單位，然後再重新啟動伺服器或服務即可。

但中斷的情況並不是都非常容易解決的。假設中斷不但造成目錄服務中斷，也導致資料在系統失敗時毀損，問題就不像更換失敗的元件後再重新啟動裝置那麼簡單。這種情況下，要處理的不只是更換硬體，您的損毀修復計劃內容還必須考慮資料的完整性、可用性、信賴性及容錯。這些問題都與服務層級合約有關；請先瞭解對當機的容忍度，然後設計規劃硬體重複性、現場的備用零件以及硬體錯誤移轉。除了硬體中斷之外，還必須和損毀修復規劃人員討論如何處理這種類型的中斷。

目錄執行不良時，會發生另一種常見的目錄問題。效能不佳時，本身有幾種表現方式：目錄的整體效能不佳、特定類型的目錄操作不佳，例如電話號碼更新緩慢。效能問題可能是一致的或間歇性的，因此在進行這些問題類型的疑難排解時，必須仔細分析，尤其要注意詳細資料。

效能問題原因

軟體設定不當，是目錄服務執行不良的主要原因。設定不當的目錄伺服器可能無法充分執行，或根本無法運作。例如，大部分的目錄伺服器都使用以 RAM 為基礎的快取記憶體暫時儲存經常存取的指令或資料。如果快取記憶體太小，伺服器可能會回應緩慢，或是根本不回應 (似乎沒有反應)。

反之，如果快取記憶體太大，伺服器的虛擬記憶體系統可能會過度分頁。無論是哪一個狀況，您都必須適當的分析系統，並「調整」所有會影響效能的參數，讓整個系統的執行達到最佳化。目錄產品廠商會提供效能調整規格，協助您改善整體效能。此外，您還必須做其他調整，以滿足部署的特定需求 (尤其是您如何使用解決方案)。

另一個常見的問題是因為沒有為伺服器處理的目錄搜尋類型維護適當的索引。大部分的目錄產品都支援搜尋任何屬性，但是無索引屬性的搜尋效能較差，因為伺服器可能需要在資料庫的每個項目中搜尋符合的項目。如果伺服器花很長的時間回應簡單的搜尋，您可以檢查用戶端是否在搜尋篩選中使用無索引屬性。

最後，目錄伺服器軟體或作業系統中可能會發生效能降低的錯誤。愈來愈多的軟體廠商使用全球資訊網向客戶通知修補程式、升級或修復程式，並且發行知識庫，其中都是有關產品的重要及有用資訊。此外，Usenet 新聞群組是學習現有錯誤、問題、處理方式以及修補程式的最佳資源。您應該充分瞭解有關產品的所有廠商以及 Web 的知識及疑難排解資源。

效能問題的含意

效能問題的含意很廣，可能是服務退化等小問題或服務完全失敗。這些徵狀可能影響所有使用者，也可能隻影響一小部分使用者。例如，快取記憶體設定不當，可能導致所有使用者和啟用目錄的應用程式的效能低落，而遺失一個屬性索引，可能只會導致經常查詢該屬性的使用者效能不佳。

效能問題方案

在進行效能問題的疑難排解時，一定要根據邏輯細心處理。仔細記錄要報告的「確切」問題，然後嘗試再度重新建立問題。如果問題無法重現，請考慮各個環境之間的差異。是否連線到相同的伺服器？是否以匿名方式驗證或繫結？是否靠近網路中的伺服器？嘗試獨立消除每個差異，直到可以確切重現使用者的問題。

如果需要稍微變更設定，修復問題可能很簡單，或者，如果找到軟體錯誤，需要升級到其中一個目錄支援的應用程式，就需要詳細的處理。

如果沒有修復方法，是否有短期的替代辦法？重新設定目錄是否可以緩和影響？

不論補救辦法為何，請花時間記錄問題、原因、短期的修復方法或替代辦法，以及長期的最終方案。軟體問題可能會十分複雜，如果能共享疑難排解方面的各種資訊，群組就可以提供高品質的方案給使用者。

目錄資料問題可能是由於資訊遺失、過多或不正確。在最糟的情況下，目錄伺服器的資料庫檔案可能會被軟體或作業系統的錯誤損毀。就整體而言，這是最常見的目錄資料問題類型。

資料問題通常是軟體設定不當等其他問題造成的，也可能是目錄系統管理員 (根層級系統管理員或啟用目錄的、應用程式系統管理員) 的不正確動作造成的。資料本身的問題，也可能造成其他問題。例如，如果誤改了存取控制屬性，使用者可能無法存取原本可看的資料、看到錯誤的資訊，或看到不該看的資訊。

目錄資料問題原因

目錄中如果出現不正確的資料，一定是某些人員或處理程序放入的。例如，原本要刪除離職員工的項目，卻誤刪了在職員工的項目；更嚴重的情形可能是，自動執行的更新處理程序原本要從人力資源資料庫調解資料庫記錄，卻誤將錯誤的員工資訊放入目錄中。

通常監視軟體時不會偵測到這種類型的問題，除非資料嚴重損壞，導致伺服器損毀或無法啟動。這種問題多半是經過使用者報告而得知，或在主動監視監視品質 (執行不易) 時發現的。

如果再積極一點，可以開發工具監視目錄資料品質，或在使用的軟體中組建驗證工具同步處理目錄與外部資料來源。這些工具可以在使用者發現問題前報告，或在問題嚴重到導致目錄無法執行之前，預先偵測出問題。

目錄資料問題的含意

目錄中出現錯誤資料時，應用程式的行為可能會錯誤或異常。例如，如果不慎移除了有效使用者的項目，使用者的電子郵件可能會退回給寄件者，因為目錄服務中的查閱或轉寄代理程式無法識別使用者。

通常如果目錄看起來正常運作，但是使用者卻報告行為錯誤或異常時，您需要檢查相關/對應目錄項目的內容。

如果目錄中的資訊是有關檔案伺服器或印表機等的網路資源，可能會出現更細微的錯誤。如果這些裝置對應的目錄項目損壞或被移除，您就無法使用這些裝置提供的服務。

此外，如果資料庫檔案損毀，徵狀不是很細微就是很明顯。目錄中的所有項目都可能消失 (這是明顯的情況)，或執行某些類型的查詢或搜尋時無法傳回某些項目或屬性。穩定的伺服器軟體可以防止這些類型的問題，但操作員錯誤可能會導致很多種的資料不一致，當使用者嘗試使用目錄進行一般作業時就會造成混亂。

如果損毀非常細微，可能短時間內並不會被注意到。處理損毀的資料時，一定要記得損毀可能是一段時間前發生的。

解決目錄資料問題

如果判斷目錄中的資料有問題，第一件要做的事是判斷損壞的程度。要進行這項工作，您需要瞭解目錄的內容，最好開始查看目錄的內容。目錄中的項目數目是否正確？如果項目太少，表示正在刪除項目，最好關閉某些 (或全部) 自動化或相依服務或應用程式。例如，如果整個部門或群組的項目都遺失了，最好關閉該群組的電子郵件服務，如此一來及使無法為郵件找到有效的目錄項目，郵件也不會退回給寄件者。

如有疑問，最安全的做法是關閉受影響的伺服器。啟用目錄的應用程式 (一定是編寫良好者) 通常會注意到目錄無法使用、報告有意義的錯誤，稍後再嘗試操作。如果發生問題的伺服器沒有關閉並遺失或包含不正確的資料，存取或使用目錄的應用程式就會因為使用錯誤資料而開始發生失敗。

一旦瞭解損壞的程度時，您就需要開始進行修復。做法則取決於損壞的程度、對原因的瞭解程度，以及與目錄內容相關的資訊量和正確度。例如，如果只遺失了單一使用者的項目，可能最好的方法是重新建立使用者，並還原安全性和應用程式的屬性。如果整個目錄因錯誤過程或操作員不慎而刪除，最好馬上進入損毀復原模式，並使用修復計劃開始還原目錄。

目錄還原後，您需要分析主因，瞭解事情的來龍去脈，如下列清單所示：

無論原因為何、無論問題有多複誰、無論要花多少時間探索問題，您都必須執行這項重要的步驟，直到完全瞭解問題的來龍去脈，並且採取適當的步驟，防止問題再度發生。

下列流程圖對應出疑難排解時執行適當正確的問題管理時的必要步驟。

圖 21 疑難排解流程圖

目錄發生問題時，請使用下列的檢查清單。這個檢查清單包含上述 3 種問題類型以及安全性的相關問題。本文件不討論安全性。如需安全性的詳細資訊，請參閱 MOF 安全性管理白皮書。

目錄中斷

效能問題

目錄資料問題

安全性問題

目錄服務管理的主要角色和相關責任，已經根據產業界的最佳實務定義，但依據組織大小、組織結構，和 IT 部門與服務對象的企業之間存在的基礎服務層級合約，組織可能需要結合某些角色。

接下來說明與目錄服務有關的角色和責任。

目錄管理員是處理序擁有者，對目錄管理處理序有端對端的責任。目錄管理員屬於 MOF 小組模型中所定義的操作角色叢集。

至於處理序設計和/或重新設計，目錄服務管理員要負起大部份責任，因為處理序擁有者提供這個處理序的領導地位和可靠度，以及在執行目錄管理處理序時的所有活動。

因此，目錄管理員要負責所有影響目錄管理及其活動的處理序改善工作。目錄管理員也應該能夠花足夠的時間進行處理序的改善，以及與不同商業單位中最高層的經理和股東保持良好關係，以處理序的成功為自己的目標。

目錄管理員：

目錄設計師

目錄設計師負責建立目錄，讓目錄可以在需求最高的地方提供正確的資訊。良好的設計應該提供資訊給使用者，同時僅使用少量資源 (例如網路頻寬、處理器和記憶體資源以及操作員的時間)。

目錄設計師：

較諸以往，目錄已逐漸成為運算環境中各項基本作業的核心，所以瞭解目錄的支援方式對其他操作程序的影響也更為重要。下圖顯示了在操作範疇內目錄服務管理與其他 MOF 的 SMF 之間所存在的關係。

圖 22 在作業扇形架構中與其他 SMF 之間的關係

系統管理會處理組織所用的管理模型。有些組織偏好在單一站台執行全部 IT 功能的模型，將一組 IT 專家集中在該站台上；有些組織則喜歡將技術和支援人員依地域分散配置的分公司模型。系統管理會檢查各模型的交易。每種系統管理模型都有獨特的網路需求，例如，存放在目錄中的使用者帳戶可能需要放在靠近使用者的地方，以減少登入的時間。分散式管理模型可能也需要委派存取給目錄中的物件。

「安全性管理」包含計劃、選擇、實作、管理以及檢視安全控制項目所需的資訊，同時包含了反應安全事件所需的流程和程序。由於時下的目錄已具備多種安裝性的功能，所以在進行目錄操作時必須特別注別這方面的問題。

服務監視及控制作業會監視多方面的系統效能，以確保服務達到服務層級合約上的相關要求。負責監視系統效能的系統管理員必須確保目錄不致於太大而無法管理，或是否有不正常佔用大量網路頻寬的情況。

網路管理處理組成組織網路的實體元件，例如伺服器、路由器、交換機和防火牆等等。目錄複寫作業可能會佔用大量的網路頻寬，所以，可用的網路頻寬會是目錄設計上所必須考量的重點之一。

列印和輸出管理會處理列印或編輯成報表，以分送給組織成員的所有資料。可用印表機和其位置的記錄通常會當做物件存放在目錄中。

組態管理處理所使用內部軟體版本的追蹤。對系統管理員而言，必須充分地瞭解並掌握作業系統、資料庫管理系統，以及所有執行於網路上電腦中應用程式的版本。在目錄服務方面，組態管理尤其要注意執行中的目錄版本控制、已部署的目錄啟用應用程式版本，以及已執行的支援性、自訂組建或協力廠商的工具版本。

可用性管理處理的是整個系統相對於停機時間的可用性問題。現今的公司企業如果發生系統當機，大多會對營運造成重大的損失，所以系統管理員必須時時注意系統設定和監視的工作，使系統處於長時間的運作狀態，並盡量阻止重大故障的發生。可用性管理與服務層級合約息息相關，對承諾客戶的服務項目和使用者提供高可靠度和可用性的目錄服務。

容量管理對於目錄的操作 (包括目前和持續的操作) 非常重要。容量管理是在目前系統資源的耗用即將接近全滿的臨界點時，處理規劃增加容量資源的相關事宜。此一規劃對於目錄的執行效能 (回應時間) 以及符合現有和未來使用者的需求而言，是十分重要的。

錯誤移轉及復原的主要功能在於應變處理，當其中一部伺服器臨時出現問題而必須停機時，會自動切換至另一部伺服器上提供相關的服務，而在主伺服器回復正常作業之後，再移轉回主伺服器提供服務的一種措施。這項功能在目錄已逐漸成為各項基本作業核心的運算環境中，尤其顯得重要。

服務連續性管理與錯誤移轉及復原有著密切的關係，但其主要著眼於處理較大型的系統災難問題。偶發事件計劃處理整個資料中心由於斷電、洪水、起火、恐怖活動而停機時產生的情況。如果必須實作偶發事件計劃，還原目錄也是主要的考量之一。

本文中介紹的許多實務是以 Accenture、Avanade、Microsoft Consulting Services、Fox IT、Hewlett-Packard Company、Lucent Technologies/NetworkCare Professional Services 以及 Unisys Corporation 等多年的 IT 實作經驗為基礎。

Microsoft 感謝這些企業慷慨提供本文件的素材。

Jeff Yuhas，Microsoft Corporation

William Bagley，Microsoft Corporation

Stephen Barnard，Microsoft Corporation

William Bagley，Microsoft Corporation

Vicky Howells，Fox IT

Jeff Yuhas，Microsoft Corporation

Steve Morgan，Fox IT

Patricia Rytkonen，Volt Technical Services

本文件中所包含的資訊代表 Microsoft Corporation 於發行日前針對該問題的觀點。由於 Microsoft 必須反應市場條件的變更，因此不應解釋為 Microsoft 的承諾。在發行日之後，Microsoft 不保證文件中任何資訊的正確性。

本文件僅供參考使用。MICROSOFT 對於本文件中各項資訊，不作任何明示、默示或法定的保證。

使用者必須遵守所有適用的版權法律規定。即使沒有版權限制，凡未經 Microsoft Corporation 書面同意，皆不得擅自複製本文件任一部份，亦不得將本文件任一部份存放或導入擷取系統，或以任何格式或任何方式 (電子、機械、影印、記錄等) 或任何用途加以散佈。

Microsoft 對於本文件內容具有專利權、專利申請權、商標、版權、或其他智慧財產權。除非任何 Microsoft 書面授權合約當中明確提及，否則出版本文件，並不代表允許您使用這些專利權、商標、版權或其他智慧財產權。

除非另有註明，否則本文中所舉的公司、組織、產品、網域名稱、電子郵件地址、標誌、人員、地點和事件範例皆屬虛構，絕未影射或暗示任何真實的公司、組織、產品、網域名稱、電子郵件地址、標誌、人員、地點和事件。

2002 Microsoft Corporation.All rights reserved.

Microsoft、Active X 及 Visio 係 Microsoft Corporation 在美國和 (或) 其他國家的商標或註冊商標。

本文所提的真實公司和產品名稱，可能係其專屬公司的商標。