Windows 系統管理

擴充 Active Directory 架構

Vikas Malhotra

摘要:

• 了解預設的 Active Directory 架構
• 新增 classSchema 或 attributeSchema 物件
• 取得及使用物件識別碼
• 使用 .ldif 檔案擴充架構

下載本文程式碼: Schema2008_05.exe (151KB)

自 Active Directory 隨著 Windows 2000 的發行而問世以來，Microsoft 一直不斷提供客戶基本架構定義來實作 Active Directory。

Active Directory® 的出現也對在 Windows® 上撰寫和實作許多應用程式的方式產生了巨大的轉變。在這之前，像是 Microsoft® Exchange 5.5 等應用程式的建置都會包含它們自身的目錄結構。而隨著 Active Directory 的普及化，許多應用程式 (無論出自 Microsoft 或其他公司) 都一捨過去從頭建立自己的架構的作法，轉而開始利用 Active Directory 所提供的基礎結構。

這些應用程式都從 Active Directory 所提供的基本架構開始著手，然後在必要時加以擴充。比方說，Microsoft Exchange 2000 便是利用 Active Directory 來實作訊息，藉以定義 Microsoft 訊息架構的未來。

如今，許多為了搭配 Active Directory 環境使用而撰寫的應用程式都仰賴 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」物件。

您可以在路徑 cn=Schema, cn=Configuration,dc=X (其中 X 是 Active Directory 樹系的命名空間) 中定義的容器內找到 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 架構。您首先在架構容器裡面指定 attributeSchema 物件，然後為這個新物件定義必要的屬性，藉此在 Active Directory 架構內建立屬性。

您可以在 go.microsoft.com/fwlink/?LinkId=110445 上找到 attributeSchema 物件的屬性清單及其相關資訊。如您所見，attributeSchema 物件有許多屬性可以定義，當中有許多都是必要的。

除了標準的屬性之外，在架構裡面還有一些搭配成組 (提供前導連結和後置連結) 實作的特別屬性，稱為連結屬性。舉 Active Directory 中的群組成員資格為例，任何一個群組的成員屬性 (例如，一個名為 ContosoEmployees 群組，內含名為 John Doe 的成員) 都是前導連結，而該成員物件相對應的 memberOf 屬性就是後置連結 (因此，比如在查詢 John Doe 的 memberOf 屬性時，就會計算 ContosoEmployees 群組的辨別名稱，即 DN)。

前導連結的表現方式跟任何其他屬性沒什麼兩樣。它的值可以是單值或多值 (就跟成員屬性一樣，可以包含某群組成員的多個物件)，而且可與父物件一同儲存在目錄中。

另一方面說來，後置連結則是由系統維護以確保參考完整性。當您查詢後置連結屬性的值時，會從所有相符的前導連結值計算出結果。後置連結一律是多值。

ADDS 中的每個物件類別都是由架構容器內的 classSchema 物件定義而成。您可以在 go.microsoft.com/fwlink/?LinkId=110445 中找到成功定義 classSchema 物件的必備屬性清單。

您可以指定的類別共有三種：結構式、抽象和輔助。這些都是由 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 國家註冊機構 (National Registration Authority，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) 不符合要求後，考慮不使用 ADLDS 所實作的替代目錄。接下來，您識別出要新增到架構的新 attributeSchema 物件，然後定義指定這些新物件所有必要的值 (例如 cn、ldapDisplayName 等等)。在定義物件的屬性值時，您也從 Microsoft 或其他來源取得了 OID。您將上述程序記錄成商務需求和技術規格。另外，您也實作了一個實驗室環境來模仿 Active Directory，並且準備好進行測試。

許多公司實際上都設有委員會來核准或否決這類的變更，以及訂定程序來實作它們。進行這類的檢查和權衡非常重要，因為 Active Directory 在許多公司裡面都被當作授權資訊來源，所以在進行變更後讓它繼續順利運作無疑是相當重要的一環。

一旦公司決定往下一步進行後，您就必須針對此專案定義測試和實作計畫。您可以使用 Microsoft Management Console (MMC) 內的 Active Directory 架構嵌入式管理單元加入新物件，或是利用程式設計或半程式設計的方式來擴充架構 (例如使用 LDIFDE 匯入 .ldif 格式檔案，使用 CSVDE 匯入 .csv 格式檔案，或透過 Active Directory 服務介面 (ADSL) 來編寫指令碼)。

無論您採用哪種方法，這項作業都必須在連接到或在 Active Directory 樹系中擁有架構主機的彈性單一主機操作 (FSMO) 角色的伺服器上進行。另外，您進行架構更新所用的帳戶也必須具備足夠的管理權限，才能執行更新，因此請把它設為架構管理員群組的成員。最後，您必須啟用樹系的架構更新 (預設為停用)。

除非變更內容非常簡單，否則應該透過自動化的方式進行，以促進測試和生產實作階段之間的標準化，並且減少因手動執行步驟可能造成的錯誤。假設您決定使用 LDIFDE 來實作變更，若要在擴充架構時套用更新，您必須加入新的屬性和類別，在類別中加入新的屬性，然後觸發快取重新載入。現在就來逐一討論幾個案例。

新增屬性

為了方便討論，假設有家名為 Contoso 的公司想要在它的 Active Directory 中新增屬性來識別每名員工的鞋子尺寸。Active Directory 樹系有兩個網域：contoso.com 和 employees.contoso.com。必備條件是，所有利用使用者類別定義建立的物件也應該包含這個新屬性。

有一點要牢記在心，因為兩個網域都位於相同的樹系中，所以架構變更對兩者都有影響。假設您從 Microsoft 收到了 1.2.840.113556.8000.9999 的 OID，並將它進一步細分成 1.2.840.113556.8000.9999.1 和 1.2.840.113556.8000.9999.2，分別用於 Contoso 的 classSchema 和 attributeSchema 物件。現在您要為這個新物件定義所有屬性值，如 [圖 3] 所示。

Figure 3 定義 contosoEmpShoe 屬性

另外，雖然 contosoEmpShoe 屬性必須供所有建立成使用者類別物件的物件使用，但是還是不建議您修改該使用者類別的預設定義。您反而應該定義一個名為 contosoUser 的輔助類別，並將 mayContain 的值指定為 contosoEmpShoe，如 [圖 4] 所示。然後將針對 contosoUser 輔助類別定義的屬性新增到使用者類別中。

Figure 4 定義 contosoUser 類別

執行了分析並定義好值之後，接下來要建立 .ldif 檔案，看起來就像 [圖 5] 中的程式碼。您可以將 [圖 5] 的內容複製到記事本中，然後把檔案另存成 contosoUser.ldif (或者您也可以在 technetmagazine.com 上找到程式碼下載的複本)。

Figure 5 .用於擴充架構的 ldif 檔案

#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 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，展開 [使用者] OU，在 [ContosoTestUser] 上按一下滑鼠右鍵，再開啟 [內容] 頁面。瀏覽以尋找 contosoEmpShoe 屬性，您可以編輯此屬性以輸入值。您也可以使用 Ldp.exe 公用程式來驗證和修改屬性。

現在來看一下定義和連結兩個屬性的範例，讓我們假想一下 Contoso 非常重視員工鞋子尺寸，並且希望對記錄公司裡面鞋子尺寸的人員進行年度績效考察。這聽起來或許很可笑，但姑且讓我們進一步假設 Contoso 不僅希望追蹤負責測量員工鞋子尺寸的人，也希望追蹤他們記錄了哪些人的鞋子尺寸以及記錄的數目 — 全都只查詢一個屬性來完成 (您可能會覺得這些資料比較適合存放在資料庫資料表中，但此處的目的只是要解釋前導和後置連結的運作方式)。

不用多說，您要先進行稍早的範例中所述的分析步驟。無論如何，我們先直接跳到產生 .ldif 檔案 linkids1.ldif 和 linkids2.ldif，如 [圖 6] 所示。然後執行這個命令匯入 .ldif 檔案：

Figure 6 前導和後置連結 .ldif 檔案

 
#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in 
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 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 的 DN，以及 Frank 可能記錄的其他員工 DN。為了完成我們的案例，管理階層可能會根據 Frank 使用者帳戶的 ContosoShoeSizesTakenByMe 屬性中包含的 DN 數量來嘉獎他。

系統檢查和平衡

像架構修改這麼重大的更新，不對架構需求進行檢查是不行的。Active Directory 是使用這些一致性檢查和安全性檢查，確認在對 Active Directory 進行新增或修改動作時，所產生的變更並沒有導致任何不一致或其他問題。

首先，每個類別的 governsID 值在架構內都必須是唯一的。定義 schemaClass 物件時，在 systemMayContain、mayContain、systemMustContain 和 mustContain 清單內定義的所有屬性都必須已經存在。同時，在 subClassOf、systemAuxiliaryClass、auxiliaryClass、systemPossSuperiors 和 possSuperiors 清單中定義的所有類別也必須已經存在。

另外，systemAuxiliaryClass 和 anxiliaryClass 清單中所有類別的 objectClassCategory 也必須是 88 類別或輔助類別。同樣地，systemPossSuperiors 和 possSuperiors 清單中所有類別的 objectClassCategory 也必須指定為 88 類別或結構式類別。

定義不同的類別時，抽象類別只能從其他抽象類別繼承，輔助類別不能從結構式類別繼承，而結構式類別不能從輔助類別繼承。另外，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 諮詢服務，他在這個行業投入 12 個年頭以來，曾與許多大型和中型規模的 IT 公司合作解決其基礎結構架構方面的需要，例如目錄、訊息、安全性和資料網路等。他持有電子和電訊工程的學士學位，以及電訊 (科技) 管理科學的博士學位。您可以透過電子郵件與他連絡：vikasmal@microsoft.com。

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