Windows Server

重新引發 Active Directory 標記物件

Gil Kirkpatrick

摘要:

• 已刪除的物件如何儲存在 Active Directory 中
• 使用 LDP 和 ADRESTORE 來尋找及還原標記
• 物件屬性和 systemFlags

雖然您可能不喜歡談論這個主題，但現實生活中總是會意外遺失資料，身為 IT 專業人員的您，更需要為一切修復狀況做好準備。在 TechNet Magazine 的 2007 年 4 月號中，我討論過

為修復 Active Directory® 使用者和群組做好規劃的重要性。在 technetmagazine.com/issues/2007/04/ADRecovery 的那篇文章中，我涵蓋了物件連結、複寫、刪除和授權還原等機制。只可惜，授權還原功能需要您在 Directory Service Restore Mode (DSRM) 中啟動網域控制站。這麼做會使 DC 在還原操作期間無法使用。

還有另一個方法您應該知道的。重新引發標記 (Tombstone Reanimation，「借屍還魂」的同義字，但這可與殭屍一點關係也沒有) 提供不使 DC 離線即可修復已刪除物件的唯一方式，它是唯一修復已刪除物件之身分識別資訊的方式，例如其 objectGUID 和 objectSid 屬性。它恰到好處地解決了因重建已刪除的使用者或群組而必須修正所有老舊存取控制清單 (ACL) 參照的問題，這些參照包含已刪除物件的 objectSid。只是您要記住，重新引發標記有其本身的限制 (此點容後再敍)，因此，您仍然應該保存授權還原的功能。

重新引發標記是在 Windows Server® 2003 Active Directory 推出的，用以簡化某些資料修復狀況。此功能利用一項事實，即 Active Directory 在實際移除已刪除物件之前會先將它們保留在資料庫一段期間。在本文中，我將詳細說明 Active Directory 如何刪除物件及重新引發物件，而且會告訴您如何使用標準 Microsoft 工具來修復已刪除的物件。

什麼是標記？

當 Active Directory 從目錄中刪除物件時，它不會真的從資料庫移除該物件。相反地，Active Directory 會將該物件的 isDeleted 屬性設定為 TRUE、從該物件中移除大部分屬性、重新命名該物件，然後將物件移到物件的命名內容 (NC) 中的一個特殊容器，叫做 CN=Deleted Objects，以此方式將物件標示為已刪除。現在該物件叫做標記，一般目錄操作看不見它。它不會顯示在任何 Microsoft® Management Console (MMC) 嵌入式管理單元中，且大部分輕量型目錄存取協定 (LDAP) 公用程式並不知道標記的存在。無論從那方面來看，標記等於是不見了。然而，資料還在那裡，它只是隱藏起來而已。那麼，Active Directory 為何要將標記 (亦即，已刪除的物件) 保留在資料庫中？

雖然其他程序看不到標記，但 Active Directory 複寫程序看得到。為確保對裝載所刪除物件的所有 DC 執行刪除，Active Directory 會將標記複寫到其他 DC。於是，標記會用於在整個 Active Directory 環境中複寫刪除。

標記的存留時間

Active Directory 通常會從目錄中刪除物件，以回應 LDAP 刪除通訊協定操作或 Security Accounts Manager (SAM) 刪除操作。此操作稱為原始刪除，與 Active Directory 複寫程序執行的刪除操作不同。請注意，此次討論不考慮動態物件，它們有不同的刪除機制，當其存留時間 (TTL) 到期時，會直接由 Active Directory 刪除。

當 Active Directory 接收到刪除操作時，它會先瀏覽檢查清單，確保該物件能夠加以刪除。我們竟然需要這個程序，很驚訝吧，不過，這是因為它可確保下列條件全部為真：

• 物件的 isDeleted 屬性尚未設定為 TRUE (您無法刪除已刪除的物件！)
• "private object" 回應專屬安全描述元控制旗標未設定在物件的安全描述元中 (這似乎是一個未記載的「功能」。專用物件旗標為安全描述元結構的 Sbz1 位元組的位元 1)。
• "disallow delete" 位元 (0x80000000) 未設定在物件的 systemFlags 屬性中。
• 物件 isCriticalSystemObject 屬性未設定為 TRUE。
• 物件的安全描述元授與適當的存取權，讓使用者能夠刪除該物件 (更具體地說，使用者可以刪除物件本身，也可以從父系物件中刪除子物件)。
• 此物件不是現有命名內容的交互參照物件 (objectClass = crossRef)。
• 此物件沒有任何下層物件 (如果 LDAP 刪除操作包括 LDAP "tree delete" 控制物件 ID，除非 isCriticalSystemObject 屬性設定為 TRUE，否則 Active Directory 也會自動刪除下層物件。這樣可防止重要系統物件在樹狀目錄刪除操作中不小心遭到刪除。當然，您可以個別地刪除這些物件)。
• 此物件不是重要內部物件 (例如，它不是 DC 的 nTDSDSA 物件或 NC 表頭的 ancestor 的 placeholder 物件)。

除了這些條件為真之外，Active Directory 還必須在適當狀態下才能處理刪除操作。比方說，如果 Active Directory 正在重新命名網域的程序中，則它不會刪除網域信任帳戶或 crossRef 物件。

如果確定事實上可刪除該物件，Active Directory 就會將該物件轉變成標記。Active Directory 會先從物件中移除不必要的屬性，但留下 [圖 1] 所指定的那些屬性以及在架構中定義為要保留在標記中的那些屬性 (如需其詳細資訊，請參閱＜修復物件屬性＞一節)。然後它會將物件的相對分辨名稱 (RDN) 變更為 CN=<old RDN>\0ADEL:<objectGUID>，其中 \0A 指出 ASCII 換行字元， <objectGUID> 則是以字串表示的 objectGUID。然後 lastKnownParent 屬性設定為物件上層容器的分辨名稱 (DN)，isDeleted 屬性則設定為 TRUE。然後 Active Directory 會從物件移除所有正向和反向連結屬性。最後，如果物件的 systemFlag 屬性沒有設定 "disallow move on delete" 位元，Active Directory 會將該物件移到 NC 的 CN=Deleted Objects 容器中 (如需本主題的詳細資訊，請參閱「systemFlags 屬性及物件行為」資訊看板)。

Figure 1 儲存在標記中的屬性

請注意，CN=Deleted Objects 資料夾是平面的，沒有物件階層。您可能會認為，如果您刪除兩個具有相同 CN 的不同物件，會造成名稱衝突。但事實並非如此。由於 objectGUID 已併入每一個標記的 RDN 中，因此，每一個標記的 RDN 在 CN=Deleted Objects 容器內都是唯一的。

顯然，物件不會永遠留在 CN=Deleted Objects 容器中。對於一開始使用 Windows® 2000 和 Windows Server 2003 建置的樹系，預設的標記存留時間為 60 天，對於一開始使用 Windows Server 2003 SP1 建置的樹系，則為 180 天。您可以設定 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=<root domain> 物件的 tombstoneLifetime 屬性，來變更標記的存留時間。

每隔 12 小時，每一個網域控制站就會啟動廢棄項目收集程序 (這可藉由為 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 物件的 garbageCollPeriod 屬性設定一個新值來加以變更)。廢棄項目收集會掃描 DC 上的所有標記，並實際刪除比標記存留時間更久的任何標記。

使用 LDP 尋找標記

LDP 是使用 Active Directory 的公用程式，類似 Windows 檔案總管。LDP 原本是由 Active Directory 開發小組設計來測試其 LDAP 程式碼，當時 Active Directory 還在開發階段。現在 LDP 是 Windows Server 2003 伺服器支援工具的一部分，它已發展成使用 Active Directory 的健全工具。

即使一般目錄操作看不到標記，您仍然可以使用 LDAP 搜尋操作及稱為控制項的特殊 LDAP 延伸，在 Active Directory 中找到標記物件。控制項是定義在 LDAP 標準中的一種機制，用來延伸 LDAP 通訊協定，以提供超出 LDAP 標準所定義的其他功能，但仍然與其他 LDAP 規格軟體保持相容。Active Directory 支援 22 個控制項，包括 Return Deleted Objects 控制項。當此控制項用來延伸 LDAP 搜尋操作時，它會擷取隱藏的已刪除物件。

為了示範其運作方式，我使用企業系統管理員認證登入 foo.local 網域，然後使用 Active Directory 使用者及電腦 (ADUC) MMC 嵌入式管理單元建立一個使用者物件 (CN=John Smith,CN=Users,DC=foo,DC=local)，如 [圖 2] 所示。然後，再次使用 ADUC 刪除該使用者物件。

圖 2** 使用 ADUC 建立使用者 **(按影像可放大)

現在，我可以執行 LDP 程式，用它來顯示已刪除使用者的標記。第一步是將 LDP 連接到特定的 DC，並使用適當的認證進行驗證。為了連接到 DC，我直接從 [連線] 功能表中選取 [連接] 選項。由於我是在 DC 上執行 LDP，因此我只按下 [確定] 就可以連接到本機 DC。如果您是從遠端執行 LDP，則必須指定您要連接的 DC 名稱。在順利連線之後，LDP 會顯示 rootDSE 的屬性，這包含說明 DC 狀態及其本身設定的屬性 (請參閱 [圖 3])。

圖 3** LDP 連接到 DC **(按影像可放大)

現在，為了使用網域或企業系統管理員認證在 DC 進行驗證，我從 [連線] 功能表中選取 [連結]。由於我是以樹系的企業系統管理員登入 (網域系統管理員和企業系統管理員預設為具有權限列出 CN=Deleted Objects 容器的物件及重新引發物件)，因此，我直接將 [連結] 對話方塊中的 [使用者名稱] 和 [密碼] 保留空白，並按下 [確定]。否則，我可以在 [連結] 對話方塊中輸入適當的認證。

接下來，我想要列出 CN=Deleted Objects,DC=foo,DC=local 容器的內容。通常您不會看到 CN=Deleted Objects 容器，因為該容器本身是標示為已刪除。您可以搜尋 CN=Deleted Objects 容器的唯一方式是使用 Return Deleted Objects LDAP 控制項。

若要搭配 LDP 使用此控制項，請到 [瀏覽] 功能表並選取 [搜尋]。即出現 [圖 4] 所顯示的搜尋對話方塊。[基本 Dn] 欄位可讓您指定要在目錄樹中開始搜尋的位置。我輸入網域的 Deleted Objects 容器的 DN–在此範例中，DN 是 CN=Deleted Objects,DC=foo,DC=local。

圖 4** LDP 搜尋對話方塊 **

在 [篩選器] 欄位中，我指定 LDP 將使用的搜尋條件。預設值為 (objectClass=*)，它指示搜尋工具傳回含有 objectClass 屬性值的所有物件。因為即使 Active Directory 中的已刪除物件也具有 objectClass 的值，所以預設篩選器將傳回搜尋範圍內的每一個物件。在此範例中，我將篩選器變更為 (objectClass=user)，限制為只搜尋使用者物件。這樣可以在 CN=Deleted Objects 容器的數千個標記當中，更容易找到已刪除的 John Smith。

您會發現，CN=Deleted Objects 容器中的物件將超過 Active Directory 在單一搜尋操作中可傳回的數量。若要解決此問題，通常您會使用分頁 LDAP 搜尋，它以一次一個群組的方式傳回結果。不過，LDP 不容許您同時指定分頁和延伸搜尋。因此，您必須重新定義 LDAP 篩選器來尋找您要的那個物件。

[範圍] 圓鈕可讓您指定要搜尋的目錄樹範圍。基本搜尋只會傳回 [基本 Dn] 欄位指定的物件。單層搜尋將傳回直接從屬於 Base Dn 物件的物件。樹狀子目錄搜尋將傳回從屬於 Base Dn 物件的所有物件。因為 CN=Deleted Objects 資料夾是平面的，所以我使用單層搜尋來擷取所有標記。

到目前為止，我只概述了傳統的 LDAP 搜尋方式。如果我現在執行它，LDP 會顯示錯誤，指出 CN=Deleted Objects,DC=foo,DC=com 不存在，因為它標示為已刪除。我還是必須在搜尋操作中包括 Return Deleted Objects LDAP 控制項。要這麼做時，我會按一下 [搜尋] 對話方塊上的 [選項] 按鈕，並選取 [Extended for the Search Call Type]，如 [圖 5] 所示。此選項可讓我指定搜尋操作的控制項。這裡，我也將屬性清單變更為 *。這會使 LDP 顯示它擷取的每一個物件的所有一般屬性，而非 LDP 的預設屬性集。

圖 5** LDP 搜尋 選項對話方塊 **

現在我按下 [控制項] 按鈕來顯示 [控制項] 對話方塊。LDP 的 [控制項] 對話方塊有點難用，因此當您這麼做時，務必小心遵循這些步驟來新增 Return Deleted Objects 控制項。

開啟 [載入預先定義] 下拉清單，選取 [Return deleted objects]，並按下 [移入] 按鈕。這樣會將 Return Deleted Objects 控制項的物件 ID (OID) (1.2.840.113556.1.4.417) 新增至 Active Controls 清單中，如 [圖 6] 所示。然後 LDP 會將此控制項新增至所有後續延伸的搜尋操作中。按下 [確定] 以儲存控制項設定，並再一次按下 [確定] 以關閉 [搜尋選項] 對話方塊。

圖 6** 新增 Return Deleted Objects 控制項 **

[控制項] 對話方塊有一些罕見行為。具體來說，即使 OID 出現在 Active Controls 清單中，不一定表示該控制項實際上有作用。有時候您必須移出控制項再將它移回，才可確保該控制項會使用於下一個 LDAP 操作。

現在我準備要執行搜尋。我按下 [LDP 搜尋] 對話方塊上的 [確定] 按鈕，LDP 即從該網域的 CN=Deleted Objects 容器中擷取所有使用者物件。[圖 7] 顯示我的結果。

圖 7** 來自 CN=Deleted Objects 容器的結果 **(按影像可放大)

檢查 LDP 結果

我的搜尋傳回兩個標記物件。首先，您會看到第一個標記的 DN：CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local.已刪除物件的 objectGUID 是以字串表示 (41800281-6bc4-42c3-a99b-b283022b3af8)。在 DN 下方是屬性清單，它顯示 objectClass、cn、distinguishedName...等等的值。您會看到 isDeleted 屬性的值是 TRUE，表示該物件事實上已經刪除。您也會看到 objectSid 已保留在標記中，這對於修復使用者及群組的標記很重要，此點容後再敘。lastKnownParent 屬性代表包含已刪除物件的物件在變成標記之前的 DN，在修復標記時，此屬性也很重要。

在我的範例中，LDP 顯示兩個標記物件，兩者都是名為 CN=John Smith 的使用者物件，它們原本來自 CN=Users,dc=foo,dc=local 容器。兩個具有相同 RDN 的不同物件如何來自相同容器？其解釋很簡單。在執行 LDP 來搜尋標記之前，我在 CN=Users,DC=foo,DC=local 容器中建立了 CN=John Smith 使用者物件，並刪除它。然後我又建立了具有相同屬性的另一個使用者物件，同樣也刪除了它。因為我已經刪除第一個 CN=John Smith 使用者物件，所以建立第二個非常合理 (即使它具有相同名稱)。但這些是不同的、獨一無二的物件，由其 objectGUID 加以區別。由於 Active Directory 將 objectGUID 併入標記的 DN 中，它們看起來像是 CN=Deleted Objects 容器中的個別物件。

如何重新引發標記

Active Directory 提供將標記還原為正常物件的機制。這實際上就是用於已刪除物件的取消刪除功能。此功能是一種特殊形式的 LDAP 修改操作，它必須包括兩項特定屬性修改：它必須移除 isDeleted 屬性 (而不只是將它設為 FALSE)，而且它必須變更物件的 distinguishedName，將該物件移到另一個容器。新的 distinguishedName 通常 (但未必) 使用 lastKnownParent 屬性作為容器，並保留相同的 RDN，但去掉 \0ADEL:<objectGUID> 元件，這是 Active Directory 在建立標記時所新增的元件。

在重新引發標記之前，Active Directory 會檢查並確保某些必要條件全部為真。使用者必須具有重新引發標記的延伸存取權，此權限是定義在包含標記之 NC 的 NC 表頭上。使用者無法重新引發他自己的物件。標記的 isDeleted 屬性必須設為 TRUE。而定義在安全性描述元的物件擁有者安全性識別元 (SID)，必須是來自該樹系的其中一個網域或信任網域中。

如果有問題的物件是在 Configuration 或 Schema NC 中，則 FLAG_CONFIG_ALLOW_RENAME 和 FLAG_ CONFIG_ALLOW_MOVE 位元必須設定在標記的 systemFlags 屬性中。如果物件是在 Configuration 或 Schema NC 中，而且有設定 FLAG_CONFIG_ALLOW_LIMITED_MOVE 旗標，則該物件只能移到具有相同的上二層容器中，換句話說，在移動之後，該物件必須留在其上三層容器中。如果物件是在網域 NC 或應用程式磁碟分割中，則 FLAG_DOMAIN_DISALLOW_RENAME 和 FLAG_DOMAIN_DISALLOW_MOVE 位元不得設在標記的 systemFlags 屬性中。

使用者必須具有如安全描述元所定義的權限，才能修改 RDN (通常是 CN，但不一定) 以及將物件新增至新的上層容器中。新的上層容器必須是標記之 objectClass 的可能上層，如架構所定義。雖然通常不容許在 System 容器中移進或移出 (除非 Unlock 系統樹狀子目錄登錄值不是零)，但容許在 System 容器中重新引發標記。

絕不容許重新引發架構物件的使用。不過，這其實不會造成問題，因為您無法正當地從 Schema NC 中刪除物件。

如果所有檢查都很順利，而且必要的需求都符合的話，Active Directory 就會對於標記執行下列步驟來重新引發物件：

• 移除 isDeleted 屬性。
• 如果在修改操作中沒有規定，objectCategory 會設定為標記中所指出最具體的 objectClass。
• RDN 已變更，且物件寫入新的上層容器。

在重新引發之後，物件具有它原本擁有的相同 objectGUID 和 objectSid 屬性。這表示物件的外部參照 (例如在 ACL 中) 不必重設，如果您重建已刪除的物件則必須加以重設。重新引發的物件，其外觀和作用就和它被刪除之前一樣。不過，有一項重要的差異：已還原的物件會缺少標記中未儲存的任何屬性。

使用 LDP 重新引發標記

systemFlags 屬性及物件行為

systemFlags 屬性是對類別端定義的選用屬性，它使 systemFlags 成為每一個 Active Directory 類別的選用屬性。它是 32 位元整數位元遮罩，控制物件的移動及刪除行為。以下是重要旗標的摘要。

FLAG_DISALLOW_DELETE (0x80000000)

如果設定此旗標，系統就不容許物件遭到刪除或移到另一個網域。

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

除非此旗標設定在 systemFlags 屬性中，否則 Configuration 和 Schema NC 中的物件無法重新命名。

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

除非此旗標設定在 systemFlags 屬性中，否則 Configuration 和 Schema NC 中的物件無法移動。

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

除非此旗標設定在 systemFlags 屬性中，否則 Configuration 和 Schema NC 中的物件無法移動。此旗標對移動操作的目標容器加諸進一步限制‑目標容器與目前容器必須具有相同的上二層容器。

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

網域 NC 或應用程式 NC 中的物件預設為可以重新命名。不過，如果此旗標是設定在物件的 systemFlags 屬性中，則系統不容許物件重新命名。

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

網域 NC 或應用程式 NC 中的物件預設為可以移到另一個容器中。不過，如果此旗標是設定在物件的 systemFlags 屬性中，則系統不容許移動物件。

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

如果設定此旗標，系統不會將物件移到其命名內容的 CN=Deleted Objects 容器。它會設定 isDeleted 屬性，重新命名物件，及移除架構中未指定要儲存的屬性。這表示並非所有已刪除物件都會出現在命名內容的 CN=Deleted Objects 容器中；有些物件會留在原始上層容器中。

現在我已告訴您重新引發標記是如何運作的具體細節，我想要示範如何使用 LDP 來還原我刪除的 CN=John Smith 使用者。首先，我連接到 DC 並進行驗證。現在我何以使用 LDP 執行修改操作。在修改操作參數中，我可以移除 isDeleted 屬性，同時指定新的 DN。

因為我要操作標記，所以必須指定 Return Deleted Objects LDAP 控制項。若要在 LDP 中設定修改操作的這個控制項，請從選項功能表中選取 [控制項]，並從 [載入預先定義] 下拉清單中選取 [Return deleted objects]，按 [移入] 按鈕，並按下 [確定] 以儲存控制項設定。

現在我從 [瀏覽] 功能表中選取 [修改]，以開啟 [修改] 對話方塊，並輸入我想要還原之標記物件的 DN。要達到此目的，最簡單的方式是從我先前執行的搜尋操作的結果中複製及貼上 DN。

接下來，我必須輸入要執行的屬性操作清單。重新引發標記需要兩個屬性操作，刪除 isDeleted 屬性，並以重新引發之標記的所需 DN 來取代 distinguishedName 屬性。因此，我在 [屬性] 欄位中輸入 isDeleted，並選取 [刪除] 圓鈕。當我按下 Enter 按鈕時，屬性操作就會新增至 [項目清單]，如 [圖 8] 所示。

圖 8** 指定要執行的屬性操作 **

然後我在 [屬性] 欄位中輸入 distinguishedName，選取 [取代] 圓鈕，並在 [值] 欄位中輸入該物件的新 DN。在此情況下，我使用使用者的原始 distuiguishedName，即 CN=John Smith,CN=Users,DC=foo,DC=local。當我按下 Enter 按鈕時，修改操作就會新增至 [項目清單] 中。

因為我必須在修改操作中包括 Return Deleted objects LDAP 控制項，所以必須使用延伸的 LDAP 修改。為了這麼做，我勾選了 [延伸] 核取方塊。在一切都設定之後，如 [圖 9] 所示，我按下 [執行] 按鈕使這些變更生效。LDP 會在大型文字視窗中顯示結果。

圖 9** 變更 distinguishedName **

當我回到 Active Directory 使用者及電腦 MMC 嵌入式管理單元並查閱 CN=Users 容器時，我發現曾經刪除的使用者物件又回到它所屬的地方。但該物件與其原始狀態有一些重大差異，此點容後再敘。

使用 ADRESTORE 重新引發標記

當您了解如何使用 LDP 之後，重新引發標記就沒有那麼困難了。但它也沒有那麼方便使用。還好，Sysinternals (此公司現在已經成為 Microsoft 的一部分) 的一些好心人士開發了一個命令列工具來簡化重新引發程序。此工具稱為 ADRESTORE，您可以從 Microsoft 網站取得它：microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx。它的安裝很簡單。只要將執行檔複製到您機器上的適當目錄即可，例如 C:\WINDOWS\SYSTEM32 目錄。

ADRESTORE 可在兩種模式下執行。如果您執行它時不使用參數，它會列出預設網域的 CN=Deleted Objects 容器中的所有標記。您可以將搜尋字串新增至命令列，以選取要顯示的物件，例如：

C:\> adrestore John

這樣會顯示 CN=Deleted Objects 容器中在其 CN 或 OU 屬性中包含 "John" 的所有標記物件，它會使用 LDAP 搜尋篩選器 cn=*John* 和 ou=*John*。這並非搜尋標記物件最有彈性的方式，但它適用於大部分情況。[圖 10] 顯示我的搜尋在 ADRESTORE 中傳回的輸出。

圖 10** 儲存在標記中的屬性 **(按影像可放大)

如果您想要重新引發標記，而不只是找到它，則您需要指定 –r 參數以及一個選用字串，如下所示：

C:\> adrestore –r John

此命令會提示您重新引發每一個相符的標記物件。ADRESTORE 一律會將物件重新引發到標記的 lastKnownParent 屬性所指定的容器中，不可以指定不同容器。

ADRESTORE 提供方便的命令列介面來使用 Active Directory 重新引發功能。雖然不是那麼有彈性，但比起使用 DLP 卻簡單許多。同樣地，ADRESTORE 也無法避免重新引發標記的兩個重要問題：要修復第一次刪除物件時從物件中移除的屬性，及修復從 Configuration NC 刪除的物件。

修復物件屬性

從資料修復方面來看，重新引發標記比執行授權還原有更大的好處： 重新引發標記不需要使 DC 離線。且重新引發標記比直接建立已刪除物件的新版本更好。如果您重建某物件，它一定會取得新的 objectGUID 和 objectSid (如果它是安全性主體，如使用者) 屬性。因此，物件的任何外部參照 (例如 ACL) 必須加以更新，來反映新物件的身分識別。這可是令人相當頭痛。

刪除物件時會移除某些屬性，這些屬性並不會隨著重新引發標記而跟著修復。但 Active Directory 會儲存標記中的一些主要屬性，其中最重要的是身分識別相關屬性，例如 objectGUID 和 objectSid。根據預設，它也許儲存許多其他屬性 (請參閱 [圖 1])。大部分寫在程式中要儲存的屬性不太有趣，尤其是在討論修復已刪除的使用者物件時。但您可以在 Active Directory 架構中設定相對應的 attributeSchema 物件的 searchFlags 屬性的位元 3 (0x00000008)，來指定標記中要儲存的其他屬性。在 Windows Server 2003 R2 中，有些屬性已在架構中設定此位元 (這些也顯示在 [圖 1] 中)。

安裝特定應用程式可能變更現有屬性的 searchFlags 的位元 3，甚至新增已設定位元 3 的屬性。例如，Exchange Server 有設定幾個其他屬性，且會儲存在標記中。

即使您在架構物件的 searchFlags 屬性中指定這麼做，Active Directory 也不會在標記中儲存正向連結或反向連結的屬性。尤其，Active Directory 不會儲存像群組的成員屬性或使用者的 memberOf 屬性之類的屬性。因此，重新引發標記並未提供解決方案來修復 Active Directory 中的群組成員資格，請參閱我所寫的＜嚴重損壞修復：Active Directory 使用者及群組＞一文：technetmagazine.com/issues/2007/04/ADRecovery。因此，在重新引發標記時，您還是必須提供替代機制來修復此資訊。

如果您想要以重新引發標記作為資料修復策略的一部分，您需要確定重要屬性已儲存在標記中，或您需要提供另一種方式來儲存及修復重要屬性，例如使用 LDIFDE 或另一個備份和還原方法。其他選項包括第三方 Active Directory 資料修復產品，其中會提供自動化機制，來備份及還原標記未儲存及修復的屬性。

從 Configuration 命名內容中重新引發物件

重新引發標記還有另一項很重要的限制，那就是，一般而言，您無法重新引發從 Configuration NC 刪除的物件。那些物件受到移動及重新命名方面的特殊規則限制，如物件的 systemFlags 屬性所定義。除非 systemFlags 屬性另有指定，否則 Configuration NC 中的物件將無法移動或重新命名，這表示其標記將無法重新引發。Active Directory 在建立特定類別的物件時會強制使用 systemFlags 屬性的某些值，如 [圖 11] 所定義。請注意，Active Directory 對這些值套用位元邏輯 OR 運算，並結合在加法運算中指定的任何 systemFlags 值。如此一來，即使應用程式對 systemFlags 屬性指定不同值，仍會適當地設定必要位元。

Figure 11 預設 systemFlags 設定

在正常情況下，Configuration NC 中您唯一可以重新引發的物件是伺服器物件。有趣的是，當 Active Directory 刪除伺服器物件時，標記不會移到 Configuration NC 的 CN=Deleted Objects 容器中；標記會直接留在物件所在之處。這可讓知識一致性檢查程式 (KCC)，即負責計算 Active Directory 複寫拓撲的程序，從已刪除的伺服器物件可能禁止適當複寫的特定狀況中自動修復。因此，如果您發現自己正試圖重新引發伺服器物件，請記住，您不會在 CN=Deleted Objects 容器中找到它。

在修復計劃中重新引發

重新引發標記應該是您資料修復工具組的重要組件。此機制是唯一不需要使 DC 離線就可以修復已刪除物件的方法，同樣重要的是，它也是可以修復已刪除物件之身分識別資訊的唯一方法。這恰好解決了重建已刪除的使用者或群組又必須修正所有老舊 ACL 參照的問題。

但重新引發標記是一個不完整的解決方案。您必須提供自己的機制來修復 Active Directory 未保留在標記物件中的屬性，而且您要從 Configuration NC 修復已刪除物件的能力也有限。請記住，如果您真的決定要重新引發已刪除使用者或群組的使用，您仍然必須修復群組成員資格及您可能需要的任何其他連結屬性。

Gil Kirkpatrick 是 NetPro 的技術長，他從 1996 年開始開發 Active Directory 軟體。他與來自 HP 的 Guido Grillenmeier 共同提供大受歡迎的 Active Directory Disaster Recovery 工作室。Gil 也是 Directory Experts Conference (www.dec2007.com) 的創辦人。

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