Windows Server

Active Directory の廃棄済みオブジェクトを復元する

Gil Kirkpatrick

 

概要:

  • 削除されたオブジェクトが Active Directory に格納されるしくみ
  • LDP と ADRESTORE を使用して廃棄済みオブジェクトを検索および復元する
  • オブジェクトの属性と systemFlags

あまり考えたくない話題かもしれませんが、誤ってデータを失うことは日常よくあります。また、IT プロフェッショナルは、あらゆる復旧シナリオに備えておく必要があります。TechNet Magazine の 2007 年 4 月号で、Active Directory® ユーザーおよびグループ**

の回復計画を立てておくことの重要性について説明しました。この記事 (technetmagazine.com/issues/2007/04/ADRecovery) では、オブジェクトのリンク、レプリケーション、削除、および Authoritative Restore のしくみについても説明しました。残念ながら、Authoritative Restore 機能を使用するには、ドメイン コントローラ (DC) をディレクトリ サービス復元モード (DSRM) で起動する必要があります。DSRM で起動すると、復元操作の実行中はその DC を使用できなくなります。

この他に、もう 1 つ知っておくべき手法があります。廃棄済みオブジェクトの復元 (ゾンビとは関係ありません) は、DC をオフラインにすることなく、削除されたオブジェクトを回復させることができる唯一の方法です。また、objectGUID 属性や objectSid 属性など、削除されたオブジェクトの ID 情報も、これ以外の手法では回復させることができません。この手法を使用すると、削除されたユーザーやグループの再作成や、削除されたオブジェクトの objectSid が含まれた、古いアクセス制御リスト (ACL) のすべての参照の修正が必要になるという問題もうまく解決されます。ただし、後で説明するように、廃棄済みオブジェクトの復元には独自の制限があるため、Authoritative Restore も対策の 1 つに入れておく必要があります。

廃棄済みオブジェクトの復元は、特定のデータ回復シナリオを簡略化するために、Windows Server® 2003 Active Directory で導入されました。この機能は、削除されたオブジェクトを物理的に削除する前に、それらを一定期間データベース内で保持するという Active Directory の動作を活用しています。この記事では、Active Directory がオブジェクトを削除および復元するしくみと、標準の Microsoft ツールを使用して、削除されたオブジェクトを回復させる方法について説明します。

廃棄済みオブジェクトについて

Active Directory がオブジェクトをディレクトリから削除しても、そのオブジェクトがデータベースから物理的に削除されるわけではありません。Active Directory で実行される処理は、オブジェクトの isDeleted 属性を TRUE に設定することによって "削除された" というマークを付け、オブジェクトのほとんどの属性を削除し、オブジェクト名を変更した後、オブジェクトの名前付けコンテキスト (NC) の特殊なコンテナである CN=Deleted Objects にそのオブジェクトを移動するという処理だけです。この処理が施されたオブジェクトを廃棄済みオブジェクトといい、通常のディレクトリ操作では非表示になります。このオブジェクトはどの Microsoft® 管理コンソール (MMC) スナップインにも表示されず、ほとんどのライトウェイト ディレクトリ アクセス プロトコル (LDAP) ユーティリティで認識されません。つまり、廃棄済みオブジェクトはほぼその姿を消しています。しかし、非表示になっているだけでデータ自体は存在します。なぜ Active Directory は、削除されたオブジェクトである廃棄済みオブジェクトをデータベース内で保持するのでしょうか。

廃棄済みオブジェクトは他の処理では認識されませんが、Active Directory のレプリケーション処理では認識されます。Active Directory は、削除するオブジェクトをホストしているすべての DC で削除操作が実行されるようにするために、廃棄済みオブジェクトを他の DC にレプリケートします。つまり、廃棄済みオブジェクトは Active Directory 環境全体に削除操作をレプリケートするために使用されます。

廃棄済みオブジェクトの有効期限

通常、Active Directory は、LDAP プロトコルの削除操作や、セキュリティ アカウント マネージャ (SAM) の削除操作に応答して、ディレクトリからオブジェクトを削除します。この操作は "要求元の削除" と呼ばれ、Active Directory のレプリケーション処理によって実行される削除操作とは区別されます。この説明は、動的オブジェクトは考慮していません。動的オブジェクトには異なる削除メカニズムが使用され、有効期限 (TTL) が切れた時点で Active Directory によって直接削除されます。

Active Directory は、削除操作を受け取ると、チェックリストを使用して、そのオブジェクトを削除できるかどうかを確認します。この処理では、次の基準がすべて満たされているかどうかが確認されるため、驚くほど複雑な処理が実行されます。

  • オブジェクトの isDeleted が TRUE に設定されていない (既に削除されたオブジェクトを削除することはできません)
  • オブジェクトのセキュリティ記述子に、リソース固有の "プライベート オブジェクト" 制御フラグが設定されている (これは公開されていない "機能" のようです。このプライベート オブジェクト フラグは、セキュリティ記述子構造体の Sbz1 バイトのビット 1 です。)
  • オブジェクトの systemFlags 属性に "削除拒否" ビット (0x80000000) が設定されていない
  • オブジェクトの isCriticalSystemObject 属性が TRUE に設定されていない
  • オブジェクトのセキュリティ記述子によって、そのオブジェクトを削除するための適切なアクセス権がユーザーに与えられている (より具体的に言うと、ユーザーがそのオブジェクト自体を削除することと、親オブジェクトから子オブジェクトを削除することを許可されている)
  • オブジェクトが既存の名前付けコンテキストの相互参照オブジェクト (objectClass = crossRef) ではない
  • オブジェクトが下位オブジェクトを保有していない (LDAP 削除操作に LDAP "ツリー削除" コントロールのオブジェクト ID が含まれている場合、Active Directory は、下位オブジェクトの isCriticalSystemObject 属性が TRUE に設定されていない限り、それらのオブジェクトを自動的に削除します。isCriticalSystemObject 属性により、ツリー削除操作で重要なシステム オブジェクトが誤って削除されるのを防ぐことができます。もちろん、下位オブジェクトを個別に削除することもできます。)
  • オブジェクトが重要な内部オブジェクトではない (DC の nTDSDSA オブジェクトや、NC ヘッドの先祖のプレースホルダ オブジェクトではない)

Active Directory が削除操作を処理するには、これらの基準が満たされているかどうかに加えて、Active Directory が適切な状態であることが必要です。たとえば、Active Directory でドメインの名前変更が実行されている場合、ドメイン信頼アカウントや crossRef オブジェクトは削除されません。

オブジェクトを実際に削除できることが確定したら、Active Directory はオブジェクトを廃棄済みオブジェクトに変換します。まず、オブジェクトから不要な属性を削除します。図 1 で指定されている属性と、スキーマで定義されている属性は、廃棄済みオブジェクト内でも保持されます (詳細については、「オブジェクトの属性を回復させる」を参照してください)。次に、オブジェクトの相対識別名 (RDN) を CN=<old RDN>\0ADEL:<objectGUID> に変更します。\0A は ASCII の改行文字、<objectGUID> は文字列として表される objectGUID をそれぞれ示しています。その後、lastKnownParent 属性をオブジェクトの親コンテナの識別名 (DN) に設定し、isDeleted 属性を TRUE に設定します。そして、すべての前方リンク属性と後方リンク属性をオブジェクトから削除します。最後に、オブジェクトの systemFlag 属性に "削除時の移動を許可しない" ビットが設定されていない場合、オブジェクトを NC の CN=Deleted Objects コンテナに移動します (詳細については、補足記事の「systemFlags 属性とオブジェクトの動作」を参照してください)。

Figure 1 廃棄済みオブジェクトに保存される属性

保存されるようにハードコードされている属性
attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
searchFlags の設定に応じて保存される属性
msDS-AdditionalSam-AccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid

CN=Deleted Objects フォルダの構造はフラットであり、オブジェクトの階層が存在しないことに注意してください。階層が存在しないため、同じ CN を持つ 2 つの異なるオブジェクトを削除したときに、名前の競合が発生するのではないかと思うかもしれませんが、競合は発生しません。各廃棄済みオブジェクトの RDN には objectGUID が組み込まれるため、CN=Deleted Objects コンテナに格納される各廃棄済みオブジェクトの RDN は一意になります。

当然のことながら、オブジェクトは永遠に 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 の操作に使用できる、エクスプローラに似たユーティリティです。もともとは、Active Directory の開発中に、開発チームが Active Directory の LDAP コードをテストするために設計しました。現在は Windows Server 2003 サポート ツールの一部として、Active Directory を操作するための堅牢なツールへと進化しました。

廃棄済みオブジェクトは通常のディレクトリ操作では表示されませんが、LDAP 検索操作と、コントロールと呼ばれる特殊な LDAP 拡張を使用することによって、Active Directory の廃棄済みオブジェクトを検索できます。コントロールは LDAP 標準で定義されているメカニズムです。コントロールを使用すると、LDAP プロトコルを拡張して LDAP 標準で定義されていない追加機能を提供できるだけでなく、他の LDAP 準拠のソフトウェアとの互換性も維持できます。Active Directory では、Return Deleted Objects (削除されたオブジェクトを返す) コントロールなど、22 個のコントロールがサポートされています。Return Deleted Objects (削除されたオブジェクトを返す) コントロールを使用して LDAP 検索操作を拡張すると、通常は表示されない削除されたオブジェクトを取得できます。

この動作のデモンストレーションを行うために、エンタープライズ管理者の資格情報を使用して foo.local ドメインにログインし、Active Directory ユーザーとコンピュータ (ADUC) MMC スナップインを使用してユーザー オブジェクト (CN=John Smith,CN=Users,DC=foo, DC=local) を作成します (図 2 を参照)。次に、再度 ADUC を使用してこのユーザー オブジェクトを削除します。

図 2 ADUC を使用したユーザーの作成

図 2** ADUC を使用したユーザーの作成 **(画像を拡大するには、ここをクリックします)

これで、LDP プログラムを実行し、このプログラムを使用して、削除されたユーザーの廃棄済みオブジェクトを表示できるようになりました。まず、LDP を特定の DC に接続し、適切な資格情報を使用して認証を行います。DC に接続するには、[Connection] (接続) メニューの [Connect] (接続) オプションを選択します。今回は DC で LDP を実行しているため、単に [OK] をクリックしてローカル DC に接続します。LDP をリモートで実行している場合は、接続先の DC の名前を指定する必要があります。DC に正しく接続されると、rootDSE の属性 (DC 自体の状態と構成を示す属性など) が表示されます (図 3 を参照)。

図 3 DC に接続された LDP

図 3** DC に接続された LDP **(画像を拡大するには、ここをクリックします)

ここで、ドメイン管理者またはエンタープライズ管理者の資格情報を使用して DC に対する認証を行うために、[Connection] (接続) メニューの [Bind] (バインド) を選択します。既にフォレストのエンタープライズ管理者としてログインしている (既定では、ドメイン管理者とエンタープライズ管理者に、CN=Deleted Objects コンテナのオブジェクトを一覧表示および復元する権限が与えられています) ため、[Bind] (バインド) ダイアログの [Username] (ユーザー名) と [Password] (パスワード) を空のままにして、[OK] をクリックします。または、適切な資格情報を [Bind] (バインド) ダイアログに入力してもかまいません。

次に、CN=Deleted Objects,DC=foo,DC=local コンテナの内容を一覧表示します。通常、CN=Deleted Objects コンテナが表示されることはありません。これは、このコンテナ自体が "削除された" というマークを付けられるためです。CN=Deleted Objects コンテナを検索できる唯一の方法は、Return Deleted Objects (削除されたオブジェクトを返す) LDAP コントロールを使用することです。

このコントロールを LDP で使用するには、[Browse] (参照) メニューの [Search] (検索) を選択します。これにより、図 4 のような検索ダイアログが表示されます。[Base Dn] (ベース Dn) フィールドには、検索を開始するディレクトリ ツリー内の場所を指定できます。このフィールドに、ドメインの Deleted Objects (削除されたオブジェクト) コンテナの DN (この例では CN=Deleted Objects,DC=foo,DC=local) を入力します。

図 4 LDP の検索ダイアログ

図 4** LDP の検索ダイアログ **

[Filter] (フィルタ) フィールドには、LDP によって使用される検索条件を指定します。既定値の (objectClass=*) は、objectClass 属性に値が格納されているすべてのオブジェクトを検索結果として返します。Active Directory の削除されたオブジェクトの objectClass にも値が格納されているため、既定のフィルタでは、検索範囲内のすべてのオブジェクトが返されることになります。この例では、フィルタを (objectClass=user) に変更して、検索対象をユーザー オブジェクトに制限します。これにより、たとえば削除されたユーザー John Smith を CN=Deleted Objects コンテナ内の (場合によっては) 何千個という廃棄済みオブジェクトから容易に検索できるようになります。

CN=Deleted Objects コンテナには、1 回の検索操作で Active Directory によって返されるオブジェクトの数を上回る数のオブジェクトが格納されている場合もあります。通常、この問題に対処するには、ページ単位の LDAP 検索を使用します。この検索方法では、結果が一度に 1 グループずつ返されます。ただし、LDP ではページ単位の検索と拡張検索を両方指定することはできないため、LDAP フィルタの範囲を絞り込んで目的のオブジェクトを検索する必要があります。

[Scope] (検索範囲) のオプション ボタンでは、検索するディレクトリ ツリーの深さを指定できます。ベース検索では、[Base Dn] (ベース Dn) フィールドに指定されたオブジェクトのみが返されます。1 レベル検索では、ベース Dn オブジェクトの直下にあるオブジェクトが返されます。また、サブツリー検索では、ベース Dn オブジェクトよりも下の階層にあるオブジェクトがすべて返されます。CN=Deleted Objects フォルダの構造はフラットであるため、ここでは 1 レベル検索を使用してすべての廃棄済みオブジェクトを取得します。

ここまでは、従来の LDAP 検索について説明しました。上記の LDAP 検索を実行した場合、CN=Deleted Objects,DC=foo,DC=com が存在しないことを示すエラーが表示されます。これは、このコンテナに "削除された" というマークが付けられているためです。このため、さらに Return Deleted Objects (削除されたオブジェクトを返す) LDAP コントロールをこの検索操作に含める必要があります。これを行うには、[Search] (検索) ダイアログの [Options] (オプション) をクリックし、[Search Call Type] (呼び出しの種類の選択) の [Extended] (拡張) を選択します (図 5 を参照)。このオプションを選択することによって、検索操作用のコントロールを指定できるようになります。また、[Attributes] (属性) リストの値を * に変更します。これにより、LDP の既定の属性ではなく、LDP によって取得された各オブジェクトの通常の属性がすべて表示されます。

図 5 LDP の [Search Options] (検索オプション) ダイアログ

図 5** LDP の [Search Options] (検索オプション) ダイアログ **

次に、[Controls] (コントロール) をクリックして [Controls] (コントロール) ダイアログを表示します。LDP の [Controls] (コントロール) ダイアログは若干扱いにくいため、この操作を行う際は、次の手順に注意深く従って Return Deleted Objects (削除されたオブジェクトを返す) コントロールを追加してください。

[Load Predefined] (定義済みオブジェクトの読み込み) ボックスの一覧を開き、[Return deleted objects] (削除されたオブジェクトを返す) を選択して、[Check in] (チェックイン) をクリックします。これにより、Return Deleted Objects (削除されたオブジェクトを返す) コントロールのオブジェクト ID (OID) (1.2.840.113556.1.4.417) が [Active Controls] (アクティブなコントロール) の一覧に追加されます (図 6 を参照)。これで、以降の LDP によって実行されるすべての拡張検索操作に、このコントロールが追加されます。[OK] をクリックしてコントロールの設定を保存し、もう一度 [OK] をクリックして [Search Options] (検索オプション) ダイアログを閉じます。

図 6 Return Deleted Objects (削除されたオブジェクトを返す) コントロールの追加

図 6** Return Deleted Objects (削除されたオブジェクトを返す) コントロールの追加 **

[Controls] (コントロール) ダイアログには特有の動作があります。具体的には、[Active Controls] (アクティブなコントロール) の一覧に OID が表示されても、そのコントロールが実際に有効になっているわけではないということです。このため、あるコントロールを次の LDAP 操作で使用するために、そのコントロールを一度チェックアウトしてから再度チェックインする必要が生じる場合もあります。

これで検索を実行する準備ができました。LDP の [Search] (検索) ダイアログで [OK] をクリックすると、LDP によってドメインの CN=Deleted Objects コンテナのすべてのユーザー オブジェクトが取得されます。結果は図 7 のようになります。

図 7 CN=Deleted Objects コンテナの検索結果

図 7** CN=Deleted Objects コンテナの検索結果 **(画像を拡大するには、ここをクリックします)

LDP の検索結果を調べる

上記で実行した検索では、2 つの廃棄済みオブジェクトが返されました。まず、1 つ目の廃棄オブジェクトの 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 が廃棄済みオブジェクトに保存されていることも確認できます。この属性は、後で説明するユーザーとグループの廃棄済みオブジェクトの回復を行う際に重要になります。廃棄済みオブジェクトを回復させる際に非常に重要になるもう 1 つの属性は、lastKnownParent 属性です。この属性は、削除されたオブジェクトが廃棄済みオブジェクトになる前に格納されていたオブジェクトの DN を表しています。

この記事の LDP のサンプルでは、もともとは CN=Users,dc=foo,dc=local コンテナの CN=John Smith という名前のユーザー オブジェクトであった、2 つの廃棄済みオブジェクトが表示されました。同じコンテナに格納されていた、同じ RDN を持つ 2 つのオブジェクトが、なぜ CN=Deleted Objects コンテナで共存できるのでしょうか。これは簡単に説明がつきます。LDP を実行して廃棄済みオブジェクトを検索する前に、CN=Users,DC=foo,DC=local コンテナに CN=John Smith ユーザー オブジェクトを作成した後、そのオブジェクトを削除しました。その後、まったく同じ属性を持つ別のユーザー オブジェクトを作成し、そのオブジェクトも削除しました。1 つ目の CN=John Smith ユーザー オブジェクトは既に削除されていたため、何の問題もなく同じ名前を持つ 2 つ目のオブジェクトを作成することができました。しかし、これらは異なる一意のオブジェクトとして、objectGUID によって区別されます。objectGUID は廃棄済みオブジェクトの DN に組み込まれるため、これら 2 つは異なるオブジェクトとして CN=Deleted Objects コンテナに格納されます。

廃棄済みオブジェクトが復元されるしくみ

Active Directory では、廃棄済みオブジェクトを通常のオブジェクトに復元するためのメカニズムが提供されます。実質的には、これは削除されたオブジェクトの削除取り消し機能です。この機能は、特殊な構成の LDAP 変更操作であり、2 つの特定の属性を変更する操作が含まれている必要があります。特定の属性を変更する操作とは、isDeleted 属性を削除する (FALSE に設定するだけではありません) 操作、およびオブジェクトの distinguishedName を変更することによって、そのオブジェクトを別のコンテナに移動する操作です。新しい distinguishedName は、通常 (必ずではありません) lastKnownParent 属性をコンテナとして使用し、廃棄済みオブジェクトの作成時に Active Directory によって追加された \0ADEL:<objectGUID> という文字列を RDN から削除した名前を値として保持します。

Active Directory は、廃棄済みオブジェクトを復元する前に、特定の要件がすべて満たされているかどうかを確認します。ユーザーは、廃棄済みオブジェクトを復元するための拡張アクセス権を与えられている必要があります。このアクセス権は、廃棄済みオブジェクトが格納されている NC の NC ヘッドで定義されています。ユーザーは、自分自身のオブジェクトを復元することはできません。廃棄済みオブジェクトの isDeleted 属性は、TRUE に設定されている必要があります。また、セキュリティ記述子で定義されている、オブジェクトの所有者のセキュリティ識別子 (SID) は、フォレスト内のいずれかのドメインか信頼されているドメインの SID である必要があります。

復元するオブジェクトが構成 NC またはスキーマ NC 内のオブジェクトである場合、廃棄オブジェクトの systemFlags 属性に FLAG_CONFIG_ALLOW_RENAME ビットと FLAG_ CONFIG_ALLOW_MOVE ビットが設定されている必要があります。復元するオブジェクトが構成 NC またはスキーマ NC 内のオブジェクトであり、さらに FLAG_CONFIG_ALLOW_LIMITED_MOVE フラグが設定されている場合、そのオブジェクトは、同じ祖父母を持つコンテナにのみ移動することができます。つまり、曽祖父母は変更できないということです。また、オブジェクトがドメイン NC またはアプリケーション パーティション内のオブジェクトである場合、廃棄済みオブジェクトの systemFlags 属性に FLAG_DOMAIN_DISALLOW_RENAME ビットと FLAG_DOMAIN_DISALLOW_MOVE ビットが設定されていない必要があります。

ユーザーが RDN (通常は CN ですが異なる場合もあります) を変更する権限と、オブジェクトを新しい親コンテナに追加する権限を与えられていることが、セキュリティ記述子で定義されている必要があります。また、新しい親コンテナが廃棄済みオブジェクトの objectClass の利用可能な上位クラスであることが、スキーマで定義されている必要があります。System コンテナからの移動や System コンテナへの移動は通常 (レジストリの System サブツリーの Unlock キーの値が 0 以外でない限り) 許可されませんが、System コンテナへの廃棄済みオブジェクトの復元は許可されます。

スキーマ オブジェクトの復元は許可されません。ただし、論理的にはスキーマ NC からオブジェクトを削除することはできないため、このことはそれほど問題ではありません。

すべての確認が正常に終了し、要件を満たしていることが確認されたら、Active Directory は廃棄済みオブジェクトに対して次の手順を実行し、オブジェクトを復元します。

  • isDeleted 属性を削除します。
  • 変更操作によって objectCategory の値が設定されていない場合、廃棄済みオブジェクトに指定されている最も限定的な objectClass を objectCategory の値に設定します。
  • RDN を変更し、オブジェクトを新しい親コンテナに書き込みます。

復元後、オブジェクトの objectGUID 属性と objectSid 属性には、削除される前と同じ値が格納されます。つまり、削除されたオブジェクトを再作成したときのように、(ACL などの) オブジェクトへの外部参照を再設定する必要はありません。復元されたオブジェクトの外観と動作は、削除される前と同じ状態に戻ります。ただし、1 つだけ重要な違いがあります。それは、復元されたオブジェクトでは、廃棄済みオブジェクトに保存されなかった属性がすべて失われるということです。

LDP を使用して廃棄済みオブジェクトを復元する

systemFlags 属性とオブジェクトの動作

systemFlags 属性は、クラス Top 用に定義された (つまり、すべての Active Directory クラス用の) 省略可能な属性です。この属性は、オブジェクトの移動と削除の動作を制御する 32 ビットの整数ビットマスクです。この属性の重要なフラグの概要を次に示します。

FLAG_DISALLOW_DELETE (0x80000000)

このフラグが設定されている場合、システムでは、オブジェクトの削除や別のドメインへの移動が許可されません。

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

systemFlags 属性にこのフラグが設定されていない限り、構成 NC とスキーマ NC のオブジェクトの名前を変更することはできません。

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

systemFlags 属性にこのフラグが設定されていない限り、構成 NC とスキーマ NC のオブジェクトを移動することはできません。

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

systemFlags 属性にこのフラグが設定されていない限り、構成 NC とスキーマ 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 コンテナに格納されず、元の親コンテナに残ります。

廃棄済みオブジェクトの復元のしくみについて具体的に説明したところで、次は削除したユーザー CN=John Smith を LDP によって復元する方法のデモンストレーションを行います。まず、DC に接続して認証を行います。これで、LDP を使用して変更操作を実行できます。変更操作のパラメータを指定する際は、isDeleted 属性を削除して、さらに新しい DN を指定します。

操作するのは廃棄済みオブジェクトであるため、Return Deleted Objects (削除されたオブジェクトを返す) LDAP コントロールを指定する必要があります。LDP の変更操作にこのコントロールを設定するには、[Options] (オプション) メニューの [Controls] (コントロール) を選択し、[Load Predefined] (定義済みオブジェクトの読み込み) ボックスの一覧から [Return deleted objects] (削除されたオブジェクトを返す) を選択して、[Check in] (チェックイン) をクリックした後、[OK] をクリックしてコントロールの設定を保存します。

次に、[Browse] (参照) メニューの [Modify] (変更) を選択して [Modify] (変更) ダイアログを開き、復元する廃棄済みオブジェクトの DN を入力します。このとき、先ほど実行した検索操作の結果から DN をコピーして貼り付けると、容易に DN を入力できます。

次に、実行する属性操作の一覧を入力する必要があります。廃棄済みオブジェクトを復元するには、isDeleted 属性を削除し、distinguishedName 属性の値を、復元する廃棄済みオブジェクトの任意の DN に置き換えるという 2 つの属性操作が必要です。まず、[Attribute] (属性) フィールドに「isDeleted」と入力し、[Delete] (削除) オプション ボタンを選択します。[Enter] (入力) をクリックすると、この属性操作が [Entry List] (エントリの一覧) に追加されます (図 8 を参照)。

図 8 実行する属性操作の指定

図 8** 実行する属性操作の指定 **

その後、[Attribute] (属性) フィールドに「distinguishedName」と入力し、[Replace] (置換) オプション ボタンを選択して、[Values] (値) フィールドにオブジェクトの新しい DN を入力します。この場合、ユーザーの元の distuiguishedName である CN=John Smith,CN=Users,DC=foo,DC=local を使用します。[Enter] (入力) をクリックすると、この変更操作が [Entry List] (エントリの一覧) に追加されます。

Return Deleted Objects (削除されたオブジェクトを返す) LDAP コントロールを検索操作に含める必要があるため、拡張 LDAP 変更操作を使用する必要があります。これを行うには、[Extended] (拡張) チェック ボックスをオンにします。設定が完了して図 9 のような状態になったら、[Run] (実行) をクリックして変更操作を実行します。結果は大きなテキスト ウィンドウに表示されます。

図 9 distinguishedName の変更

図 9** distinguishedName の変更 **

Active Directory ユーザーとコンピュータ (ADUC) MMC スナップインに戻って CN=Users コンテナを確認すると、一度は削除されたユーザー オブジェクトが元の場所に戻っています。しかし、復元されたオブジェクトの状態と元のオブジェクトの状態との間には、この後説明するいくつかの重要な違いがあります。

ADRESTORE を使用して廃棄済みオブジェクトを復元する

LDP の使用方法を理解すれば、廃棄済みオブジェクトの復元はそれほど難しいものではなくなります。しかし、LDP は非常に便利な方法とは言えません。幸運なことに、Sysinternals (現在はマイクロソフトに統合されています) のすばらしい開発者によって、この復元処理を簡略化できるコマンド ライン ツールが開発されました。この ADRESTORE と呼ばれるツールは、マイクロソフト Web サイト (microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx) からダウンロードできます。このツールのインストールは単純で、実行可能ファイルをコンピュータの適切なディレクトリ (C:\WINDOWS\SYSTEM32 など) にコピーするだけです。

ADRESTORE は 2 つのモードで実行できます。パラメータを指定せずに実行すると、既定のドメインの CN=Deleted Objects コンテナにあるすべての廃棄済みオブジェクトが一覧表示されます。次のように、コマンド ラインに検索文字列を追加すると、表示するオブジェクトを選択できます。

C:\> adrestore John

上記のコマンドを実行すると、CN=Deleted Objects コンテナにある廃棄済みオブジェクトの中で、CN または OU 属性に "John" という文字列が含まれたオブジェクトがすべて表示されます。つまり、cn=*John* と ou=*John* という LDAP 検索フィルタが使用されます。これはあまり柔軟な廃棄済みオブジェクトの検索方法ではありませんが、多くの状況で使用できます。図 10 は、上記のコマンドを実行したときに ADRESTORE から返される出力を示しています。

図 10 廃棄済みオブジェクトに保存される属性

図 10** 廃棄済みオブジェクトに保存される属性 **(画像を拡大するには、ここをクリックします)

廃棄済みオブジェクトを検索するだけではなく復元する場合は、次のように –r スイッチを文字列 (省略可能) と共に指定する必要があります。

C:\> adrestore –r John

上記のコマンドを実行すると、条件に一致した廃棄済みオブジェクトを復元するかどうかを確認するメッセージが、オブジェクトごとに表示されます。ADRESTORE は、常に廃棄済みオブジェクトの lastKnownParent 属性に指定されているコンテナにオブジェクトを復元します。他のコンテナを指定する方法はありません。

ADRESTORE によって、Active Directory の復元機能の使用に役立つコマンド ライン インターフェイスが提供されます。ADRESTORE はそれほど柔軟性はありませんが、LDP よりもはるかに使いやすいツールです。しかし、ADRESTORE を使用しても、まだ廃棄済みオブジェクトの復元に関する 2 つの重要な問題は解決されません。この問題とは、オブジェクトが最初に削除されたときに一緒に削除される属性をどのようにして回復させるかということ、および構成 NC から削除されたオブジェクトをどのようにして回復させるかということです。

オブジェクトの属性を回復させる

データ回復という点では、廃棄済みオブジェクトの復元のほうが、Authoritative Restore よりもはるかに優れています。これは、廃棄済みオブジェクトの復元では DC をオフラインにする必要がないためです。また、廃棄済みオブジェクトの復元は、削除されたオブジェクトの新しいバージョンを単純に再作成するよりもはるかに便利です。オブジェクトを再作成すると、(そのオブジェクトがユーザーなどのセキュリティ プリンシパルである場合) そのオブジェクトの objectGUID 属性と objectSid 属性には新しい値が割り当てられるため、オブジェクトへの外部参照 (ACL など) を更新して新しいオブジェクトの ID を反映する必要があります。これは大きな悩みの種になる可能性があります。

一部の属性は、オブジェクトが削除されたときに一緒に削除され、廃棄済みオブジェクトの復元を実行しても回復させることはできません。しかし、Active Directory はいくつかの重要な属性を廃棄済みオブジェクトに保存します。その中で最も重要な属性は、objectGUID や objectSid などの ID に関連した属性です。この他にも、既定で多くの属性が保存されます (図 1 を参照)。保存されるようにハードコーディングされている属性のほとんどは、特に削除されたユーザー オブジェクトの回復という点では、あまり興味を引きません。しかし、Active Directory スキーマ内にある、該当する attributeSchema オブジェクトの searchFlags 属性にビット 3 (0x00000008) を設定すると、廃棄済みオブジェクトに保存する属性を追加指定できます。Windows Server 2003 R2 のスキーマでは、既にいくつかの属性 (図 1 にも記載されています) にこのビットが設定されています。

特定のアプリケーションをインストールすると、既存の属性の searchFlags のビット 3 が変更されたり、ビット 3 が設定された新しい属性が追加されたりすることがあります。たとえば、Exchange Server は、いくつかの属性の構成を変更し、それらを廃棄済みオブジェクトに保存される属性として追加します。

Active Directory では、前方リンク属性と後方リンク属性を廃棄済みオブジェクトに保存するように、スキーマ オブジェクトの searchFlags 属性で指定した場合でも、これらのリンク属性が保存されません。具体的には、グループの member 属性やユーザーの memberOf 属性は保存されません。このため、廃棄済みオブジェクトの復元を使用しても、Active Directory のグループ メンバシップを回復させることはできません。これについては、以前に公開した「障害回復: Active Directory ユーザーとグループ」(technetmagazine.com/issues/2007/04/ADRecovery) を参照してください。つまり、廃棄済みオブジェクトの復元を行う際にこの情報も回復させるには、さらに別のメカニズムを提供する必要があります。

廃棄済みオブジェクトの復元をデータ回復戦略の一部として使用する場合は、重要な属性が廃棄済みオブジェクトに保存されることを確認するか、重要な属性を保存および回復させる別の方法 (LDIFDE や他のバックアップおよび復元方法) を提供する必要があります。他の選択肢としては、廃棄済みオブジェクトへの保存や廃棄済みオブジェクトからの回復が行われない属性をバックアップおよび復元するための自動化されたメカニズムを提供する、サードパーティ製のデータ回復製品などがあります。

構成名前付けコンテキストからオブジェクトを復元する

廃棄済みオブジェクトの復元に関する他の大きな制限の 1 つは、一般的に言うと、構成 NC から削除されたオブジェクトを復元できないということです。これらのオブジェクトの移動と名前変更に関しては、オブジェクトの systemFlags 属性の定義に従って、特殊な規則が適用されます。構成 NC のオブジェクトは、systemFlags 属性で指定しない限り、移動することも名前を変更することも (つまり、廃棄済みオブジェクトを復元することも) できません。Active Directory は、特定のクラスのオブジェクトを作成するときに、systemFlags 属性に特定の値を強制的に設定します (図 11 を参照)。また、Active Directory は、これらの値と追加操作で指定された systemFlags の値を組み合わせた値に、ビットごとの論理 OR 演算を適用します。このため、アプリケーションが systemFlags 属性に異なる値を指定した場合でも、必要なビットが正しく設定されます。

Figure 11 既定の systemFlags の設定

クラス 既定の設定
server FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA FLAG_DISALLOW_MOVE_ON_DELETE
siteLink FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge FLAG_CONFIG_ALLOW_RENAME
nTDSConnection FLAG_CONFIG_ALLOW_RENAME

通常の状態で復元できる構成 NC のオブジェクトは、サーバー オブジェクトのみです。興味深いことに、Active Directory がサーバー オブジェクトを削除したとき、廃棄済みオブジェクトは構成 NC の CN=Deleted Objects コンテナに移動されず、元のオブジェクトと同じ場所に残ります。このため、削除されたサーバー オブジェクトが原因で正しいレプリケーションを実行できない場合、Active Directory のレプリケーション トポロジの計算を実行する知識整合性チェッカー (KCC) によって、自動的に再度レプリケーションを実行できる状態に回復させることができます。したがって、サーバー オブジェクトの復元が必要になった場合は、そのオブジェクトが CN=Deleted Objects コンテナに格納されないことを思い出してください。

回復計画における復元

廃棄済みオブジェクトの復元は、重要なデータ回復ツールキットの 1 つになるはずです。このメカニズムは、DC をオフラインにせずに、削除されたオブジェクトを回復させることができる唯一の方法です。また、同じくらい重要なことですが、このメカニズムは、削除されたオブジェクトの ID 情報を回復させることができる唯一の方法でもあります。廃棄済みオブジェクトの復元を使用すると、削除されたユーザーやグループの再作成や、古い ACL のすべての参照の修正が必要になるという問題がうまく解決されます。

しかし、廃棄済みオブジェクトの復元は完全な解決策ではなく、Active Directory によって廃棄済みオブジェクト内で保持されない属性を回復させるための独自のメカニズムを提供する必要があり、構成 NC から削除されたオブジェクトの回復も制限されます。このため、削除されたユーザーやグループの復元を実行する場合は、グループのメンバシップと、必要になる可能性がある、他のリンクされた属性も回復させることを忘れないでください。

Gil Kirkpatrick は NetPro 社の最高技術責任者であり、1996 年以来 Active Directory 用ソフトウェアの開発に取り組んできました。彼が HP 社の Guido Grillenmeier と共同で行う Active Directory の障害回復ワークショップは好評です。また、彼は Directory Experts Conference (www.dec2007.com) の発起人でもあります。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.