扩展活动目录构架
概覽:
自從在 Windows 2000 中開始引入 Active Directory 以來，Microsoft 已向眾多客戶提供了用于實施 Active Directory 的基本架構定義。 Active Directory? 的出現也標志著 Windows? 中許多應用程序的寫入和實施方式都發生了轉變。在此之前，應用程序（如 Microsoft? Exchange 5.5）必須要自行加以構建來包含其自身的目錄結構。Active Directory 出現后，許多應用程序（無論是 Microsoft 的還是其他公司的）都開始充分利用它所提供的底層結構，而不再從頭開始構建自己的架構。 這些應用程序首先使用 Active Directory 提供的基本體系結構，然后根據需要再加以擴展。以 Microsoft Exchange 2000 為例，它利用 Active Directory 來實現消息傳遞，并進而定義了未來的 Microsoft 消息傳遞體系結構。 現在，許多被編寫為在 Active Directory 環境中運行的應用程序都依賴其底層架構來發揮作用，并且有些還會根據需要來定義自己的架構變更內容。當然，正如我將在本文中介紹的，這需要一個可擴展的架構。并且，由于如此眾多的應用程序都依賴于 Active Directory 中的基本定義，因此核心架構的持續穩定性至關重要。因為許多應用程序都需要在同一個 Active Directory 中彼此配合工作，因此對任意應用程序的變更均不能影響其他應用程序。
什么是架構？ 對許多人來說，Active Directory 架構是個黑盒子，修改自身架構這一想法讓人覺得有點恐怖。當然，擴展 Active Directory 架構并不是每天都要執行的操作，但特定的應用程序或業務需求可能會需要此操作。因此，了解架構是什么以及它都包含哪些內容非常重要，并且由于 Active Directory 在許多組織中都是非常重要的資產，因此如果因更新有誤而致使其出現故障可能會造成嚴重的影響。 作為一種策略，許多組織都在考慮將 Windows Server? 2008 中的“Active Directory 輕型目錄服務”(ADLDS) 或 Windows Server 2003 中的“Active Directory 應用程序模式”(ADAM) 作為一種替代方案加以測試，或者直接實施自定義的架構定義而不擴展 Active Directory 架構。 架構是一種提供目錄服務格式的底層結構。Active Directory 架構可以定義“Active Directory 域服務”(ADDS) 中使用的對象類和屬性。核心架構定義了許多眾所周知的類（如 user、computer 和 organizationalUnit）和屬性（如 telephoneNumber 和 objectSID）。核心架構定義中出現的對象被稱為“類別 1”對象，而添加的對象被稱為“類別 2”對象。 Active Directory 架構可在路徑 cn=Schema, cn=Configuration,dc=X 所定義的容器中找到，其中 X 是 Active Directory 林的命名空間。請注意，Active Directory 林僅包含一個架構；對林中的架構定義進行變更會影響該林中的所有域。圖 1 顯示了對于不同版本的 Windows Server，在 Active Directory 架構中添加的類和屬性的數量。 ?Figure?1?類和屬性的數量
在不同版本的 Windows Server 中，架構的更新都是使用名為 Adprep 的實用工具來完成的。在 Windows Server 2003 R2 的更新版本中，架構版本更新為 31，在 Windows Server 2008 中會改為 44。 要對此進行核對，可使用 ADSIEdit 等工具來檢查 Active Directory 中 cn=Schema,cn=Configuration,dc=X 的 objectVersion 屬性值。請注意，Exchange Server、System Management Server (SMS) 等應用程序或依賴于 Active Directory 的其他一些應用程序可能會根據應用程序的需求來修改架構。
具體細節 Active Directory 包括兩種對象類型：classSchema（簡稱為類）和 attributeSchema（簡稱為屬性）。如果組織希望將數據存儲到未包含在現有架構中的特定屬性內，通常會考慮擴展 Active Directory 架構。要在 Active Directory 架構中創建屬性，首先要在架構容器中指定一個 attributeSchema 對象，然后為該新對象定義必要的屬性。 在 go.microsoft.com/fwlink/?LinkId=110445 中提供了 attributeSchema 對象相關屬性的列表以及其他一些信息。正如您所看到的，可為 attributeSchema 對象定義多個屬性；這些屬性中很多都是必需的。 除常規屬性以外，架構中還有一些被稱為鏈接屬性的特殊屬性，它們都是通過提供前向鏈接和后向鏈接來成對實施的。以 Active Directory 中的組成員身份為例。任意組（例如，名為 ContosoEmployees 且包含一個名為 John Doe 成員的組）的 member 屬性為前向鏈接，而成員對象的對應 memberOf 屬性為后向鏈接（因此，當查詢 John Doe 的 memberOf 屬性時，會計算 ContosoEmployees 組的可分辨名稱，即 DN）。 前向鏈接的行為方式與其他所有屬性都非常相似。其值可以是單值或多值（與 member 屬性一樣，可包含多個對象作為組成員），并與目錄中的父對象存儲在一起。 另一方面，后向鏈接是由系統維護的，以確保引用的完整性。查詢后向鏈接屬性的值時，會根據所有匹配的前向鏈接值來計算結果。后向鏈接始終是多值鏈接。 ADDS 中的每個對象類都由架構容器中的 classSchema 對象所定義。在 go.microsoft.com/fwlink/?LinkId=110445 中提供了對成功定義 classSchema 對象至關重要的一些屬性的列表。 可以指定下列三種類型的類：Structural、Abstract 和 Auxiliary。它們由 objectClassCategory 屬性的值定義。（第四種類型稱為 88，它包括在 X.500 1993 標準之前定義的所有類。這種類型的類由 objectClassCategory 屬性中的值 0 來指定。這種類型的類不應該再定義。）
獲得并使用標識符 目錄中每個 classSchema 和 attributeSchema 對象的身份都是使用“強制對象標識符”(OID) 定義的，此標識符的定義依據是 classSchema 對象的 governsID 和 attributeSchema 對象的 attributeID。這些是由特定的頒發機構所提供的唯一數字值，可用于識別對象。編號方式由 LDAP 協議 (RFC 2251) 的定義進行管理。Active Directory 架構中的某些 OID 是由“國際標準化組織”(ISO) 頒發的，而有些是由 Microsoft 頒發的。OID 對于目錄中的對象而言必須唯一。 OID 是一個數字字符串，如 1.2.840.113556.1.y.z（如圖 2 所示）。例如，由此可以得出用戶 classSchema 對象的 OID 為 1.2.840.113556.1.5.9。 ?Figure?2?用戶對象的標識符
當組織打算擴展架構時，必須要確保 OID 的唯一性，為此首先要獲取自己的 OID 根號，然后開始分支，為組織所創建的新對象類和屬性提供唯一的 ID。OID 根可直接從 ISO 國家注冊機構 (NRA) 獲取，該機構在美國屬于“美國國家標準協會”(ANSI)。 可通過 ansi.org 來了解獲取根 OID 所需的程序和費用。對于其他地區，請聯系相應的 ISO 成員組織；ISO 在 iso.org/iso/about/iso_members.htm 提供了其成員組織的列表。 在過去，組織可通過向 schemreg@microsoft.com 發送電子郵件來從 Microsoft 獲取 OID。但是現在，它會提供一個自動回復，提示請求者從 go.microsoft.com/fwlink/?LinkId=110453 下載并運行 VBScript。 對于 Microsoft 頒發的 OID，該數字是在 Microsoft OID 數字空間下指定的：1.2.840.113556.1.8000.x，其中 x 是指定給組織的唯一編號。組織可能會進一步拆分這些 OID 來指定對象。這樣，組織可以使用 1.2.840.113556.1.8000.x.1.y 來代表新的 classSchema 對象，使用 1.2.840.113556.1.8000.x.2.z 來代表 attributeSchema 對象（其中，x 代表組織的唯一編號，y 和 z 分別代表指定給特定的 classSchema 和 attributeSchema 對象的編號）。另外還建議用戶在這些對象的名稱中使用組織特定的前綴以區分它們。
定義鏈接屬性 前向鏈接的 attributeSyntax 值為 2.5.5.1, 2.5.5.7（或 2.5.5.14），這一點非常重要。這些值對應于包含可分辨名稱的語法，例如 Object (DS-DN) 語法。 后向鏈接的 attributeSyntax 值必須為 2.5.5.1，這是 Object (DS-DN) 語法。按照慣例，后向鏈接屬性將被添加到頂層抽象類的 mayContain 值中。這將允許從任意類的對象中讀取后向鏈接屬性，因為后向鏈接屬性實際上并非存儲在對象中；它們都是根據前向鏈接值計算得來的。 Windows Server 2003 引入了如下所示的一個新功能，組織可使用此功能來鏈接架構中的兩個對象：自動生成 linkID。利用此功能，當屬性的 linkID 屬性設為 1.2.840.113556.1.2.50 時，系統會自動為新鏈接屬性生成一個 linkID。通過將 linkID 設置為前向鏈接的 attributeId 或 ldapDisplayName，可創建對應的后向鏈接。在創建前向鏈接之后及創建后向鏈接之前，必須重新加載架構緩存。否則，在創建后向鏈接時將無法找到前向鏈接的 attributeId 或 ldapDisplayName。架構緩存可根據需要重新加載，在架構更改后幾分鐘內或域控制器重新啟動后也會重新加載。 如果您的 Active Directory 是在 Windows 2000 級別，則必須向 schemreg@microsoft.com 發送一封電子郵件，向 Microsoft 請求 linkID。在自動回復郵件中，您會看到：“對于發送到 schemreg@microsoft.com 的電子郵件，只有那些與原有環境下的 linkID 注冊問題相關的郵件才會得到處理。”為此，請在電子郵件中提供以下信息：公司名稱、聯系人姓名、電子郵件地址、電話號碼、注冊的前綴（如果適用）、注冊的 OID（如果適用）。
準備擴展架構 假設您已決定擴展您的 Active Directory 架構。在確信它已無法再滿足要求后，此分析結果可能會建議減少使用 ADLDS（或 Windows Server 2003 中的 ADAM）實現的替代目錄。接下來，確定要添加到架構中的新 attributeSchema 對象，這樣做之后，可以定義指定這些新對象所需的所有值（例如 cn、ldapDisplayName 等）。在定義對象的屬性值時，還從 Microsoft 或其他機構獲取了 OID。您實際上已將上述內容記錄為業務需求和技術規范。而且已實施了模擬 Active Directory 的實驗室環境并已準備好進行測試。 許多組織實際都設有委員會來批準或拒絕此類變更并且會設置實施它們的過程。由于在許多組織中 Active Directory 都被用作權威的信息源，因此此類檢查和平衡至關重要，而且在變更后認真加以貫徹和執行也極為重要，無論怎樣強調也不為過。 當組織決定了繼續推行后，就必須制定有關此項目的測試和實施計劃。要對架構進行擴展，您可以使用 Microsoft 管理控制臺 (MMC) 中的 Active Directory 架構管理單元來添加新對象，也可以使用編程或半編程方法來擴展架構（如使用 LDIFDE 來導入 .ldif 格式文件；使用 CSVDE 導入 .csv 格式文件；或使用 Active Directory 服務接口 (ADSI) 腳本）。 無論使用哪種方法，都必須在 Active Directory 林中，在連接到或擁有架構主機的“靈活單主機操作”(FSMO) 角色的服務器上執行此功能。并且，由于用來更新架構的帳戶必須具有足夠的管理權限才能執行更新，因此應使其成為“架構管理員”組的成員。最后，必須啟用林的架構更新（默認為禁用）。 除非變更非常簡單，否則都應以自動方式執行，以便促進測試和生產實施階段之間的標準化并減少可能會因手動操作而產生的錯誤。讓我們假設您已決定使用 LDIFDE 來實施變更。要在擴展架構時應用更新，您應添加新屬性和類，向類添加新屬性，然后觸發緩存重新加載。讓我們先來看幾種方案。
添加屬性 為了敘述方便起見，假設名為 Contoso 的組織希望將新屬性添加到其 Active Directory 中，用來標識每名員工的鞋碼。Active Directory 林有兩個域：contoso.com 和 employees.contoso.com。具體要求是使用用戶類定義創建的所有對象都應包含這一新屬性。 您必須要記住的一點是，架構變更對這兩個域都會產生影響，因為它們位于同一林中。假設您已從 Microsoft 獲得 OID 1.2.840.113556.8000.9999 并已將其拆分為 1.2.840.113556.8000.9999.1（代表 Contoso 的 classSchema 對象）和 1.2.840.113556.8000.9999.2（代表 Contoso 的 attributeSchema 對象）。現在要為這一新對象定義所有屬性值（如圖 3 所示）。 ?Figure?3?定義 contosoEmpShoe 屬性
而且，盡管 contosoEmpShoe 屬性需要可供創建為用戶類對象的所有對象使用，但并不建議您對用戶類的默認定義進行修改。相反，應定義一個名為 contosoUser 的輔助類，它具有指定為 contosoEmpShoe 的 mayContain 值（如圖 4 所示）。然后，將為 contosoUser 輔助類定義的屬性添加到用戶類中。 ?Figure?4?定義 contosoUser 類
既然已經執行了分析并定義了值，就可以開始創建 .ldif 文件了（類似于圖 5 所示的代碼）。您可將圖 5 中的內容復制到記事本并將其保存為 contosoUser.ldif（或者，也可以在 technetmagazine.com 的代碼下載部分找到此代碼的副本）。 ?Figure?5?.ldif 文件（用于擴展架構） ?#Attribute definition for contosoEmpShoedn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemaaddobjectClass: topobjectClass: attributeSchemacn: contosoEmpShoeattributeID: 1.2.840.113556.1.8000.9999.2.1attributeSyntax: 2.5.5.12isSingleValued: TRUEadminDisplayName: contosoEmpShoeadminDescription: contosoEmpShoeoMSyntax: 64searchFlags: 1lDAPDisplayName: contosoEmpShoesystemOnly: FALSEdn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-# Classesdn: CN=contosoUser,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemaaddobjectClass: topobjectClass: classSchemacn: contosoUsergovernsID: 1.2.840.113556.1.8000.9999.1.1mayContain: contosoEmpShoerDNAttID: cnadminDisplayName: contosoUseradminDescription: contosoUserobjectClassCategory: 3lDAPDisplayName: contosoUsername: contosoUsersystemOnly: FALSEdn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-dn: CN=User,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemamodifyadd: auxiliaryClassauxiliaryClass: contosoUser-dn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1 生成 .ldif 文件后，您需要在實驗環境中對實施進行全面的測試、驗證域和林的端對端復制情況，還需要在林中啟用架構更新。此時，應以具有“架構管理員”權限的帳戶身份登錄。您可能希望禁用架構主機（將在其中執行變更）上的出站復制，然后再運行以下命令來導入 .ldif 文件： ?ldifde –i –f <Path>\contosoUser.ldif –b<username> <domain> <password> -k –j. –c"CN=schema,CN=Configuration,DC=X"#schemaNamingContext 變更發生后，啟用架構主機上的出站復制并驗證所有域控制器都已執行復制操作。 來一次深呼吸——大功告成啦！您已在架構中定義了一個新屬性，它將與使用用戶類（即用戶帳戶）創建的對象相關聯。 要驗證變更，請打開 Active Directory 用戶和計算機，連接到 employees.contoso.com 域，瀏覽到用戶組織單元 (OU)，創建一個名為 ContosoTestUser 的新用戶帳戶。現在，打開 adsiedit.msc 控制臺并連接到域分區 dc=employees,dc=contoso,dc=com，展開用戶組織單元，右鍵單擊 ContosoTestUser，打開“Properties”（屬性）頁面。瀏覽查找 contosoEmpShoe 屬性。可編輯此屬性以輸入一個值。也可使用 Ldp.exe 實用工具來驗證和修改屬性。 現在讓我們來看一個定義和鏈接兩個屬性的示例，假設 Contoso 非常看重員工的鞋碼并希望能通過某種方式跟蹤公司中負責測量鞋碼的員工的年度表現。這聽起來可能有點好笑，但讓我們進一步假設，Contoso 不僅希望跟蹤負責測量員工鞋碼的人員，還希望跟蹤他們測量了哪些人的鞋碼以及總人數（所有這些都通過查詢一個屬性來完成）。（您可能會認為此數據更適合存儲在數據庫表中，但此處只是為了解釋前向鏈接和后向鏈接的工作機制）。 當然，您會首先執行我在先前的示例中提到過的相同類型的分析。但是，在此我們要繼續生成 .ldif 文件 linkids1.ldif 和 linkids2.ldif（如圖 6 所示）。然后運行以下命令來導入 .ldif 文件： ?Figure?6?前向鏈接和后向鏈接 .ldif 文件 ? #linkids1.ldif#Attribute definition for Forward Link Attributedn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemaaddobjectClass: topobjectClass: attributeSchemacn: ContosoShoeSizeTakerattributeID: 1.2.840.113556.1.8000.9999.2.2LinkID: 1.2.840.113556.1.2.50attributeSyntax: 2.5.5.1isSingleValued: TRUEadminDisplayName: ContosoShoeSizeTakeradminDescription: ContosoShoeSizeTakeroMSyntax: 64searchFlags: 1lDAPDisplayName: ContosoShoeSizeTakersystemOnly: FALSEdn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-#Reload schema#linkids2.ldif#Attribute definition for Backward Link Attributedn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemaaddobjectClass: topobjectClass: attributeSchemacn: ContosoShoeSizesTakenByMeattributeID: 1.2.840.113556.1.8000.9999.2.3LinkID: 1.2.840.113556.8000.9999.2.2attributeSyntax: 2.5.5.1isSingleValued: FALSEadminDisplayName: ContosoShoeSizesTakenByMeadminDescription: ContosoShoeSizesTakenByMeoMSyntax: 64searchFlags: 1lDAPDisplayName: ContosoShoeSizesTakenByMesystemOnly: FALSEdn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in #contosoUser classdn: CN= contosoUser,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemamodifyadd: mayContainmayContain: ContosoShoeSizeTakermayContain: ContosoShoeSizesTakenByMedn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-#Add Backward Link Attribute as MayContain in Topdn: CN=Top,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemamodifyadd: mayContainmayContain: ContosoShoeSizesTakenByMedn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1 ?ldifde –i –f <Path>\linkedids<>.ldif –b<username> <domain> <password> -k –j. –c"CN=schema,CN=Configuration,DC=X"#schemaNamingContext 在創建完用戶對象后，它還會使 ContosoShoeSizeTaker 和 ContosoShoeSizesTakenByMe 作為其屬性。當為某個人員（比如 John）創建用戶對象時，ContosoShoeSizeTaker 屬性將被填寫為測量鞋碼人員（即名為 Frank 的人員）的 DN。現在轉到 Frank 的用戶對象屬性并查詢 ContosoShoeSizesTakenByMe 屬性，結果將包含 John 的以及 Frank 所測量的所有其他人的 DN。在我們方案的最后，管理層會根據 Frank 用戶帳戶的 ContosoShoeSizesTakenByMe 屬性中存在的 DN 總數來獎勵他。
系統檢查和平衡 如果沒有對體系結構需求的檢查，將無法執行關鍵更新（如架構修改）。通過這些一致性檢查和安全檢查，Active Directory 可以驗證無論何時對 Active Directory 執行添加或修改操作，這些變更都不會導致任何不一致情況或其他問題。 首先，每個類的 governsID 值在架構內必須唯一。在定義 schemaClass 對象時，在 systemMayContain、mayContain、systemMustContain 和 mustContain 列表中定義的所有屬性必須都已經存在。同時，在 subClassOf、systemAuxiliaryClass、auxiliaryClass、systemPossSuperiors 和 possSuperiors 列表中定義的所有類也必須都已經存在。 并且，systemAuxiliaryClass 和 auxiliaryClass 列表中的所有類的 objectClassCategory 必須為 88 類或 Auxiliary 類。類似地，systemPossSuperiors 和 possSuperiors 列表中的所有類的 objectClassCategory 也必須被指定為 88 類或 Structural 類。 在定義各種類時，Abstract 類只能從其他 Abstract 類繼承，Auxiliary 類無法從 Structural 類繼承，而 Structural 類也無法從 Auxiliary 類繼承。此外，在 rDNAttID 屬性中指定的屬性必須使用 Unicode 字符串作為其語法并且必須為單值。 這些是與 classSchema 對象相關的一些規則。那 attributeSchema 對象的規則呢？與類的 governsID 值一樣，attributeID 的值也必須唯一。同樣，mAPIID（如果有）的值也必須唯一。并且，如果存在 rangeLower 和 rangeUpper，rangeLower 必須小于 rangeUpper。attributeSyntax 和 oMSyntax 的值必須匹配。如果屬性為對象型語法 (oMSyntax =127)，它必須具有正確的 oMObjectClass。linkID（如果有）必須唯一。此外，后向鏈接必須有一個對應的前向鏈接。
如果出了差錯該怎么辦？ 使用新對象（類和屬性）對架構進行擴展后，這些新對象將無法再刪除。但是，可通過將架構對象的屬性 isDefunct 設為 TRUE 來取消激活類或屬性。不過對于隨 Active Directory 一同提供的作為默認架構一部分的架構對象（“類別 1”對象），將無法取消激活它們。您只能取消激活被添加到默認架構中的對象；即，只有“類別 2”對象能被禁用，并且必須要經過 Active Directory 驗證，確認該類未用于任何現有非無效類的 subClassOf、auxiliaryClass 或 possSuperiors 列表中。 如果試圖將某個屬性設為無效，Active Directory 會檢查以確認任何現有非無效類的 mustContain 或 mayContain 中都未使用該屬性。可通過將屬性 isDefunct 設為 FALSE 來恢復被禁用的對象。如果您的 Active Directory 是在 Windows Server 2003 級別，則可重用被禁用對象的 ldapDisplayName、schemaIdGuid、OID 和 mapiID 值。
總結 在架構中添加或修改類或屬性定義涉及到添加或修改對應的 classSchema 對象或 attributeSchema 對象。此過程類似于在 Active Directory 中添加或修改任意對象，不同之處在于需要執行額外的檢查來確保變更在今后不會在架構中導致不一致情況或其他問題。 盡管修改 Active Directory 架構非常簡單，但必須要了解架構的構成以及它是如何實施這些變更的。對生產型 Active Directory 架構進行任何變更前都需要進行周密的規劃，并且執行時務必要小心謹慎。對新對象而言，為其定義業務需求和技術規范并執行大量的實驗室測試至關重要。由于變更可能會產生深遠的影響，因此建議只有在絕對必要的情況下才擴展 Active Directory 架構。
Vikas Malhotra 就職于紐約的 Microsoft Consulting Services。在 12 年的職業生涯中，他曾與許多大型和中型企業的 IT 組織一起工作，研究他們的基礎設施體系結構需求（如目錄、消息傳遞、安全性以及數據聯網等）。他擁有電子和電信工程學學士學位以及電信（技術）管理理學碩士學位。可通過電子郵件 vikasmal@microsoft.com 與他聯系。
- 了解默認的 Active Directory 架構
- 添加 classSchema 或 attributeSchema 對象
- 獲得并使用對象標識符
- 使用 .ldif 文件擴展架構
自從在 Windows 2000 中開始引入 Active Directory 以來，Microsoft 已向眾多客戶提供了用于實施 Active Directory 的基本架構定義。 Active Directory? 的出現也標志著 Windows? 中許多應用程序的寫入和實施方式都發生了轉變。在此之前，應用程序（如 Microsoft? Exchange 5.5）必須要自行加以構建來包含其自身的目錄結構。Active Directory 出現后，許多應用程序（無論是 Microsoft 的還是其他公司的）都開始充分利用它所提供的底層結構，而不再從頭開始構建自己的架構。 這些應用程序首先使用 Active Directory 提供的基本體系結構，然后根據需要再加以擴展。以 Microsoft Exchange 2000 為例，它利用 Active Directory 來實現消息傳遞，并進而定義了未來的 Microsoft 消息傳遞體系結構。 現在，許多被編寫為在 Active Directory 環境中運行的應用程序都依賴其底層架構來發揮作用，并且有些還會根據需要來定義自己的架構變更內容。當然，正如我將在本文中介紹的，這需要一個可擴展的架構。并且，由于如此眾多的應用程序都依賴于 Active Directory 中的基本定義，因此核心架構的持續穩定性至關重要。因為許多應用程序都需要在同一個 Active Directory 中彼此配合工作，因此對任意應用程序的變更均不能影響其他應用程序。
什么是架構？ 對許多人來說，Active Directory 架構是個黑盒子，修改自身架構這一想法讓人覺得有點恐怖。當然，擴展 Active Directory 架構并不是每天都要執行的操作，但特定的應用程序或業務需求可能會需要此操作。因此，了解架構是什么以及它都包含哪些內容非常重要，并且由于 Active Directory 在許多組織中都是非常重要的資產，因此如果因更新有誤而致使其出現故障可能會造成嚴重的影響。 作為一種策略，許多組織都在考慮將 Windows Server? 2008 中的“Active Directory 輕型目錄服務”(ADLDS) 或 Windows Server 2003 中的“Active Directory 應用程序模式”(ADAM) 作為一種替代方案加以測試，或者直接實施自定義的架構定義而不擴展 Active Directory 架構。 架構是一種提供目錄服務格式的底層結構。Active Directory 架構可以定義“Active Directory 域服務”(ADDS) 中使用的對象類和屬性。核心架構定義了許多眾所周知的類（如 user、computer 和 organizationalUnit）和屬性（如 telephoneNumber 和 objectSID）。核心架構定義中出現的對象被稱為“類別 1”對象，而添加的對象被稱為“類別 2”對象。 Active Directory 架構可在路徑 cn=Schema, cn=Configuration,dc=X 所定義的容器中找到，其中 X 是 Active Directory 林的命名空間。請注意，Active Directory 林僅包含一個架構；對林中的架構定義進行變更會影響該林中的所有域。圖 1 顯示了對于不同版本的 Windows Server，在 Active Directory 架構中添加的類和屬性的數量。 ?Figure?1?類和屬性的數量
| 版本 | 添加的屬性數量 | 添加的類數量 | 架構擴展文件 |
| Windows Server 2003 | 208 | 49 | Sch14.ldf 到 sch30.ldf |
| Windows Server 2003 R2 | 81 | 29 | Sch31.ldf |
| Windows Server 2008 | 136 | 10 | Sch32.ldf 到 sch44.ldf |
具體細節 Active Directory 包括兩種對象類型：classSchema（簡稱為類）和 attributeSchema（簡稱為屬性）。如果組織希望將數據存儲到未包含在現有架構中的特定屬性內，通常會考慮擴展 Active Directory 架構。要在 Active Directory 架構中創建屬性，首先要在架構容器中指定一個 attributeSchema 對象，然后為該新對象定義必要的屬性。 在 go.microsoft.com/fwlink/?LinkId=110445 中提供了 attributeSchema 對象相關屬性的列表以及其他一些信息。正如您所看到的，可為 attributeSchema 對象定義多個屬性；這些屬性中很多都是必需的。 除常規屬性以外，架構中還有一些被稱為鏈接屬性的特殊屬性，它們都是通過提供前向鏈接和后向鏈接來成對實施的。以 Active Directory 中的組成員身份為例。任意組（例如，名為 ContosoEmployees 且包含一個名為 John Doe 成員的組）的 member 屬性為前向鏈接，而成員對象的對應 memberOf 屬性為后向鏈接（因此，當查詢 John Doe 的 memberOf 屬性時，會計算 ContosoEmployees 組的可分辨名稱，即 DN）。 前向鏈接的行為方式與其他所有屬性都非常相似。其值可以是單值或多值（與 member 屬性一樣，可包含多個對象作為組成員），并與目錄中的父對象存儲在一起。 另一方面，后向鏈接是由系統維護的，以確保引用的完整性。查詢后向鏈接屬性的值時，會根據所有匹配的前向鏈接值來計算結果。后向鏈接始終是多值鏈接。 ADDS 中的每個對象類都由架構容器中的 classSchema 對象所定義。在 go.microsoft.com/fwlink/?LinkId=110445 中提供了對成功定義 classSchema 對象至關重要的一些屬性的列表。 可以指定下列三種類型的類：Structural、Abstract 和 Auxiliary。它們由 objectClassCategory 屬性的值定義。（第四種類型稱為 88，它包括在 X.500 1993 標準之前定義的所有類。這種類型的類由 objectClassCategory 屬性中的值 0 來指定。這種類型的類不應該再定義。）
獲得并使用標識符 目錄中每個 classSchema 和 attributeSchema 對象的身份都是使用“強制對象標識符”(OID) 定義的，此標識符的定義依據是 classSchema 對象的 governsID 和 attributeSchema 對象的 attributeID。這些是由特定的頒發機構所提供的唯一數字值，可用于識別對象。編號方式由 LDAP 協議 (RFC 2251) 的定義進行管理。Active Directory 架構中的某些 OID 是由“國際標準化組織”(ISO) 頒發的，而有些是由 Microsoft 頒發的。OID 對于目錄中的對象而言必須唯一。 OID 是一個數字字符串，如 1.2.840.113556.1.y.z（如圖 2 所示）。例如，由此可以得出用戶 classSchema 對象的 OID 為 1.2.840.113556.1.5.9。 ?Figure?2?用戶對象的標識符
| 值 | 含義 | 說明 |
| 1 | ISO | 標識根頒發機構。 |
| 2 | ANSI | ISO 指定的組名稱。 |
| 840 | 美國 | 組織指定的國家/地區代碼。 |
| 113556 | Microsoft | 國家/地區指定的組織名稱。 |
| 1 | Active Directory | 由組織（如本例中的 Microsoft）指定。 |
| Y | 對象類型 | 定義不同對象類型（類別）（如 classSchema 或 attributeSchema）的數字。例如，5 定義對象類。 |
| Z | 對象 | 標識類別中特定對象的數字。例如，用戶類被指定的數字是 9。 |
定義鏈接屬性 前向鏈接的 attributeSyntax 值為 2.5.5.1, 2.5.5.7（或 2.5.5.14），這一點非常重要。這些值對應于包含可分辨名稱的語法，例如 Object (DS-DN) 語法。 后向鏈接的 attributeSyntax 值必須為 2.5.5.1，這是 Object (DS-DN) 語法。按照慣例，后向鏈接屬性將被添加到頂層抽象類的 mayContain 值中。這將允許從任意類的對象中讀取后向鏈接屬性，因為后向鏈接屬性實際上并非存儲在對象中；它們都是根據前向鏈接值計算得來的。 Windows Server 2003 引入了如下所示的一個新功能，組織可使用此功能來鏈接架構中的兩個對象：自動生成 linkID。利用此功能，當屬性的 linkID 屬性設為 1.2.840.113556.1.2.50 時，系統會自動為新鏈接屬性生成一個 linkID。通過將 linkID 設置為前向鏈接的 attributeId 或 ldapDisplayName，可創建對應的后向鏈接。在創建前向鏈接之后及創建后向鏈接之前，必須重新加載架構緩存。否則，在創建后向鏈接時將無法找到前向鏈接的 attributeId 或 ldapDisplayName。架構緩存可根據需要重新加載，在架構更改后幾分鐘內或域控制器重新啟動后也會重新加載。 如果您的 Active Directory 是在 Windows 2000 級別，則必須向 schemreg@microsoft.com 發送一封電子郵件，向 Microsoft 請求 linkID。在自動回復郵件中，您會看到：“對于發送到 schemreg@microsoft.com 的電子郵件，只有那些與原有環境下的 linkID 注冊問題相關的郵件才會得到處理。”為此，請在電子郵件中提供以下信息：公司名稱、聯系人姓名、電子郵件地址、電話號碼、注冊的前綴（如果適用）、注冊的 OID（如果適用）。
準備擴展架構 假設您已決定擴展您的 Active Directory 架構。在確信它已無法再滿足要求后，此分析結果可能會建議減少使用 ADLDS（或 Windows Server 2003 中的 ADAM）實現的替代目錄。接下來，確定要添加到架構中的新 attributeSchema 對象，這樣做之后，可以定義指定這些新對象所需的所有值（例如 cn、ldapDisplayName 等）。在定義對象的屬性值時，還從 Microsoft 或其他機構獲取了 OID。您實際上已將上述內容記錄為業務需求和技術規范。而且已實施了模擬 Active Directory 的實驗室環境并已準備好進行測試。 許多組織實際都設有委員會來批準或拒絕此類變更并且會設置實施它們的過程。由于在許多組織中 Active Directory 都被用作權威的信息源，因此此類檢查和平衡至關重要，而且在變更后認真加以貫徹和執行也極為重要，無論怎樣強調也不為過。 當組織決定了繼續推行后，就必須制定有關此項目的測試和實施計劃。要對架構進行擴展，您可以使用 Microsoft 管理控制臺 (MMC) 中的 Active Directory 架構管理單元來添加新對象，也可以使用編程或半編程方法來擴展架構（如使用 LDIFDE 來導入 .ldif 格式文件；使用 CSVDE 導入 .csv 格式文件；或使用 Active Directory 服務接口 (ADSI) 腳本）。 無論使用哪種方法，都必須在 Active Directory 林中，在連接到或擁有架構主機的“靈活單主機操作”(FSMO) 角色的服務器上執行此功能。并且，由于用來更新架構的帳戶必須具有足夠的管理權限才能執行更新，因此應使其成為“架構管理員”組的成員。最后，必須啟用林的架構更新（默認為禁用）。 除非變更非常簡單，否則都應以自動方式執行，以便促進測試和生產實施階段之間的標準化并減少可能會因手動操作而產生的錯誤。讓我們假設您已決定使用 LDIFDE 來實施變更。要在擴展架構時應用更新，您應添加新屬性和類，向類添加新屬性，然后觸發緩存重新加載。讓我們先來看幾種方案。
添加屬性 為了敘述方便起見，假設名為 Contoso 的組織希望將新屬性添加到其 Active Directory 中，用來標識每名員工的鞋碼。Active Directory 林有兩個域：contoso.com 和 employees.contoso.com。具體要求是使用用戶類定義創建的所有對象都應包含這一新屬性。 您必須要記住的一點是，架構變更對這兩個域都會產生影響，因為它們位于同一林中。假設您已從 Microsoft 獲得 OID 1.2.840.113556.8000.9999 并已將其拆分為 1.2.840.113556.8000.9999.1（代表 Contoso 的 classSchema 對象）和 1.2.840.113556.8000.9999.2（代表 Contoso 的 attributeSchema 對象）。現在要為這一新對象定義所有屬性值（如圖 3 所示）。 ?Figure?3?定義 contosoEmpShoe 屬性
| 屬性 | 值 | 注釋 |
| Cn | contosoEmpShoe | ? |
| lDAPDisplayName | contosoEmpShoe | ? |
| adminDisplayName | contosoEmpShoe | ? |
| attributeSyntax | 2.5.5.12 | 指定一個 Unicode 字符串。 |
| oMSyntax | 64 | 表示一個 Unicode 字符串。 |
| objectClass | top, attributeSchema | ? |
| attributeID | 1.2.840.113556.8000.9999.2.1 | 如組織所定義。 |
| isSingleValued | TRUE | 只能存儲一個鞋碼值。 |
| searchFlags | 1 | 您的分析結果表明您希望為此屬性編制索引。備注：您需要在實驗室環境下執行壓力測試分析。 |
| isMemberOfPartialAttributeSet | TRUE | 您希望此屬性出現在全局編錄中。 |
| 屬性 | 值 |
| Cn | contosoUser |
| lDAPDisplayName | contosoUser |
| adminDisplayName | contosoUser |
| governsID | 1.2.840.113556.8000.9999.1.1（如組織所定義） |
| mayContain | contosoEmpShoe |
| possSuperiors | organizationalUnit, container |
| objectClassCategory | 3（定義輔助類） |
系統檢查和平衡 如果沒有對體系結構需求的檢查，將無法執行關鍵更新（如架構修改）。通過這些一致性檢查和安全檢查，Active Directory 可以驗證無論何時對 Active Directory 執行添加或修改操作，這些變更都不會導致任何不一致情況或其他問題。 首先，每個類的 governsID 值在架構內必須唯一。在定義 schemaClass 對象時，在 systemMayContain、mayContain、systemMustContain 和 mustContain 列表中定義的所有屬性必須都已經存在。同時，在 subClassOf、systemAuxiliaryClass、auxiliaryClass、systemPossSuperiors 和 possSuperiors 列表中定義的所有類也必須都已經存在。 并且，systemAuxiliaryClass 和 auxiliaryClass 列表中的所有類的 objectClassCategory 必須為 88 類或 Auxiliary 類。類似地，systemPossSuperiors 和 possSuperiors 列表中的所有類的 objectClassCategory 也必須被指定為 88 類或 Structural 類。 在定義各種類時，Abstract 類只能從其他 Abstract 類繼承，Auxiliary 類無法從 Structural 類繼承，而 Structural 類也無法從 Auxiliary 類繼承。此外，在 rDNAttID 屬性中指定的屬性必須使用 Unicode 字符串作為其語法并且必須為單值。 這些是與 classSchema 對象相關的一些規則。那 attributeSchema 對象的規則呢？與類的 governsID 值一樣，attributeID 的值也必須唯一。同樣，mAPIID（如果有）的值也必須唯一。并且，如果存在 rangeLower 和 rangeUpper，rangeLower 必須小于 rangeUpper。attributeSyntax 和 oMSyntax 的值必須匹配。如果屬性為對象型語法 (oMSyntax =127)，它必須具有正確的 oMObjectClass。linkID（如果有）必須唯一。此外，后向鏈接必須有一個對應的前向鏈接。
如果出了差錯該怎么辦？ 使用新對象（類和屬性）對架構進行擴展后，這些新對象將無法再刪除。但是，可通過將架構對象的屬性 isDefunct 設為 TRUE 來取消激活類或屬性。不過對于隨 Active Directory 一同提供的作為默認架構一部分的架構對象（“類別 1”對象），將無法取消激活它們。您只能取消激活被添加到默認架構中的對象；即，只有“類別 2”對象能被禁用，并且必須要經過 Active Directory 驗證，確認該類未用于任何現有非無效類的 subClassOf、auxiliaryClass 或 possSuperiors 列表中。 如果試圖將某個屬性設為無效，Active Directory 會檢查以確認任何現有非無效類的 mustContain 或 mayContain 中都未使用該屬性。可通過將屬性 isDefunct 設為 FALSE 來恢復被禁用的對象。如果您的 Active Directory 是在 Windows Server 2003 級別，則可重用被禁用對象的 ldapDisplayName、schemaIdGuid、OID 和 mapiID 值。
總結 在架構中添加或修改類或屬性定義涉及到添加或修改對應的 classSchema 對象或 attributeSchema 對象。此過程類似于在 Active Directory 中添加或修改任意對象，不同之處在于需要執行額外的檢查來確保變更在今后不會在架構中導致不一致情況或其他問題。 盡管修改 Active Directory 架構非常簡單，但必須要了解架構的構成以及它是如何實施這些變更的。對生產型 Active Directory 架構進行任何變更前都需要進行周密的規劃，并且執行時務必要小心謹慎。對新對象而言，為其定義業務需求和技術規范并執行大量的實驗室測試至關重要。由于變更可能會產生深遠的影響，因此建議只有在絕對必要的情況下才擴展 Active Directory 架構。
Vikas Malhotra 就職于紐約的 Microsoft Consulting Services。在 12 年的職業生涯中，他曾與許多大型和中型企業的 IT 組織一起工作，研究他們的基礎設施體系結構需求（如目錄、消息傳遞、安全性以及數據聯網等）。他擁有電子和電信工程學學士學位以及電信（技術）管理理學碩士學位。可通過電子郵件 vikasmal@microsoft.com 與他聯系。
總結
- 上一篇： springmvc+activiti 完
- 下一篇： Cisco 2950 系列交换机实例配置