Windows の管理

障害回復: Active Directory ユーザーとグループ

Gil Kirkpatrick

概要:

• レプリケーションとオブジェクト リンクのしくみ
• NTDSUTIL を使用してバックアップと復元を行う
• 権限のある復元と権限のない復元

Active Directory は、Windows ネットワークで最も重要なサービスの 1 つです。ダウンタイムや生産性の低下を防ぐには、Active Directory に関する問題の発生に備えて、あらかじめ有効な障害回復計画を準備しておくことがきわめて重要です。

これは今さら言うまでもありません。しかし、データの誤った削除という最もよくある障害シナリオすら想定していない Active Directory® 管理者が非常に多いのです。

オブジェクトの誤った削除は、サービス障害の最も一般的な原因の 1 つです。私はセミナーやカンファレンスの参加者に、データの誤った削除による Active Directory の障害を経験したことがあるかどうかをよくたずねてみますが、いつもほとんど全員が手を挙げるほどです。

データ回復はなぜこれほどまでに複雑なのでしょうか。それを理解するためには、Active Directory におけるオブジェクトの保存、レプリケーション、および削除の方法を理解し、権限のある復元と権限のない復元のしくみを知る必要があります。

オブジェクトを保存する

Active Directory は、X.500/LDAP データ モデルを実装した特殊なオブジェクト データベースです。データ ストアは "ディレクトリ情報ツリー (DIT)" と呼ばれ、索引順次アクセス方式 (ISAM) のデータベース エンジンである、Extensible Storage Engine (ESE) を利用して動作します。この DIT は、概念的には 2 つのテーブルに格納されます。1 つは実際の Active Directory オブジェクトと属性を含むデータ テーブル、もう 1 つはオブジェクトのリレーションシップ情報を含むリンク テーブルです。

データ テーブルの行には Active Directory オブジェクトが 1 つずつ、列には属性が 1 つずつ格納されます。データ テーブルには、ドメイン コントローラ (DC) に保存されたすべてのレプリカのエントリが含まれます。通常の DC の場合、ドメインの NC (名前付けコンテキスト)、構成 NC、およびスキーマ NC のエントリが含まれます。グローバル カタログの場合、フォレスト内の各オブジェクトのエントリが含まれます。

Active Directory は識別名タグ (DNT) という 32 ビットの整数を使用して、データ テーブルの各行を識別します。DNT はオブジェクトの内部参照に使用されるので、識別名 (DN)、objectGUID (16 バイトのバイナリ構造) などの他の識別子と比べて、かなり小さいサイズになっています。objectGUID と異なる点は、DNT がローカル識別子であり、DC ごとに異なるという点です。

Active Directory のオブジェクトのリンク方法

Active Directory では、DIT 内のオブジェクト間に、親子関係 (コンテナ関係) または参照関係 (リンク関係) の 2 種類のリレーションシップが存在します。親子関係を実装する場合は、データ テーブルに "親識別名タグ (PDNT)" という列が追加されます。この列には、常にオブジェクトの親の DNT が格納されます。

Active Directory の各属性は、Active Directory スキーマ コンテナ内の attributeSchema オブジェクトによって定義されます。Active Directory の属性の一部は、リンク属性として定義されています。attributeSchema オブジェクトの linkID 属性にゼロ以外の偶数値が設定されている場合、その属性はリンク属性です。リンク属性は、ディレクトリ内のオブジェクト間にリレーションシップを作成する属性であり、単一または複数の値を持ちます。たとえば、グループ オブジェクトの member (メンバ) 属性は複数の値を持つリンク属性であり、グループ オブジェクトとそのメンバ オブジェクト間にリンクを作成します。

メンバの DN がグループの member 属性に含まれているように思われますが (たとえば [Active Directory ユーザーとコンピュータ] スナップインで表示した場合)、実際は違います。メンバ オブジェクトの DN をグループの member 属性に追加すると、このオブジェクトの DN ではなく DNT が保存されます。DNT はオブジェクトの名前を変更しても変わりません。このため、ユーザー オブジェクトの名前変更が可能であり、個々の member 属性の DN は、システム内のすべてのグループを調べなくても更新されます。Active Directory では、このようにして DIT 内の参照の整合性が保持されています。図 1 に、データ テーブルとリンク テーブルの関係を簡単に示します。この 2 つのテーブルには、Senior Engineers (シニア エンジニア) グループのメンバである Molly Clark、Alexander Tumanov、および Makoto Yamagishi を表す 3 つのユーザー オブジェクトが含まれています。

Figure 1 データ テーブルとリンク テーブルの関係

これらのリンクは、前方リンクと呼ばれます。同様に、Active Directory には後方リンク属性もあります。後方リンクは、リンク先オブジェクト (参照先オブジェクト) から参照元オブジェクト (前方リンクを持つオブジェクト) への参照を提供します。たとえば、ユーザーやグループの memberOf 属性は後方リンク属性です。後方リンク属性を持つ attributeSchema オブジェクトの linkID 値は、対応する前方リンク属性の偶数の linkID 値に 1 を加えた値になります。たとえば、Windows Server® 2003 R2 のスキーマに含まれる member 属性の linkID 値は 2 です。後方リンクとして働く memberOf 属性の linkID 値は 3 です。詳細については、図 2 を参照してください。図 2 は、Windows Server 2003 R2 のスキーマで定義された既定のリンク属性の一覧です。

Figure 2 Windows Server 2003 R2 スキーマのリンク属性

後方リンク属性は常に複数の値を持ち、Active Directory で自動的に管理されます。ユーザーが後方リンク属性を直接変更することはできません。ユーザーまたはグループの memberOf 属性は、Microsoft 管理コンソール (MMC) の Active Directory ユーザーとコンピュータ スナップインを使用して変更できそうに見えます。しかし、実際にはスナップインでは対応するグループの member 属性が変更されるだけで、memberOf 属性は Active Directory によって更新されます。ユーザーをグループに追加するときユーザー オブジェクトのアクセス許可が必要ないのは、実際にはグループ オブジェクトの member 属性を変更しているだけだからです。各 DC は後方リンク属性をローカルに管理するので、後方リンクの変更内容はレプリケートされません。グループの member 属性など、前方リンク属性の変更内容だけがレプリケートされます。

通常の DC の場合、データ テーブルには、ドメイン オブジェクトのエントリの他に、構成コンテナおよびスキーマ コンテナのオブジェクトが含まれます。一部のグループの種類には、別のドメインにあるオブジェクトへの参照も含めることができます。Active Directory は、データ テーブル内に存在しないオブジェクトの DNT をどのようにして保存するのでしょうか。その答えは、インフラストラクチャ マスタの FSMO (フレキシブル シングル マスタ オペレーション) の所有者と、ファントム オブジェクトにあります。

ファントム オブジェクト

あるドメインのメンバを別のドメインのグループに追加すると、データ テーブル内にファントムと呼ばれる特殊なオブジェクトが自動的に作成されます。ファントム オブジェクトには、新しいメンバの objectGUID、objectSid、および DN が含まれます。これにより、DNT をグループの member 属性として保存できるようになります。ドメイン コントローラがグローバル カタログである場合は、データ テーブルにフォレスト内の各オブジェクトのエントリが作成されているので、ファントムを作成する必要はありません。

インフラストラクチャ マスタの FSMO の役割を持つ DC は、定期的にデータ テーブルのエントリとグローバル カタログを比較します。そして、オブジェクトの移動、名前変更、削除などを検出すると、データ テーブル内のファントムを更新し、変更内容をドメイン内のその他の DC にレプリケートします。インフラストラクチャ マスタは、参照カウントに基づいて、ドメイン内の前方リンク属性によって参照されていないファントムを削除することもできます。

DC は、ファントムを利用して、フォレスト内の他のドメインのオブジェクトへの参照を管理できますが、前方リンク属性も、フォレストの外、たとえば信頼されたドメイン内のオブジェクトを参照できます。この場合、Active Directory により、ドメイン NC の CN=ForeignSecurityPrincipals コンテナ内に、外部セキュリティ プリンシンパル (FSP) というオブジェクトが作成されます。FSP には、外部オブジェクトのセキュリティ識別子 (SID) と、外部ドメイン内のオブジェクトを識別するその他の属性が含まれています。ただし、FSP を最新の状態に保つための処理は行われません。データ回復の目的には、FSP をその他の Active Directory オブジェクトと同様に扱います。

オブジェクトを削除する

ここでは主に、ユーザーとそのグループのメンバシップを復元する方法について説明しますが、同じ方法で、リンクされたその他の属性を回復することもできます。

Active Directory でオブジェクトを削除しても、そのオブジェクトが DIT から物理的に削除されるわけではありません。Active Directory は、isDeleted 属性を true に設定して、"オブジェクトが削除された" というマークを付けるだけです。マークが付けられたオブジェクトは、通常のディレクトリ操作では非表示になります。Active Directory は、スキーマに従って、保存すると指定されていないすべての属性を削除し、オブジェクトの相対識別名 (RDN) を <old RDN>\0aDEL:<objectGUID> に変更します。続いて、このオブジェクトを NC の CN=Deleted Objects (削除済みオブジェクト) コンテナに移動します。ただし、構成 NC 内には、削除済みオブジェクト コンテナに移動されないオブジェクト クラスもあります。オブジェクトを削除すると、このオブジェクトから他のオブジェクトへの前方リンクがすべて削除されるので、リンク テーブル内の参照カウントが減ります。削除済みオブジェクトへの前方リンクを含むオブジェクトがある場合は、そのリンクも削除されます。

こうして得られたオブジェクトは、廃棄 (TOMBSTONE) オブジェクトと呼ばれます。Active Directory は、廃棄オブジェクトを他の DC にレプリケートし、同様の変更が行われます。ただし、削除済みオブジェクトを参照する前方リンクへの変更はレプリケートされません。これは、DC ごとにローカルで同様の変更が行われるからです。詳細は後述しますが、このことはグループ メンバシップの回復に影響します。

Active Directory は、CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> オブジェクトの tombstoneLifetime 属性に従って、廃棄オブジェクトを DIT に保持します。各 DC でガベージ コレクションが実行されると、設定された有効期間を過ぎた廃棄オブジェクトは削除されます。既定では、廃棄オブジェクトの有効期間は 60 日 (Windows® 2000、Windows Server 2003、および Windows Server 2003 R2 の場合) または 180 日 (Windows Server 2003 SP1 の場合) です。

廃棄オブジェクトの有効期間と復元処理には、重要な関連性があります。廃棄オブジェクトの有効期間を過ぎた古いバックアップからデータを復元することはできません。ドメインから削除され、ガベージ コレクションが完了したオブジェクトには、廃棄オブジェクトがありません。このため、削除操作を実行しても、復元された DC へのレプリケーションは行われません。削除済みオブジェクトは、復元された DC 上に残留オブジェクトとして残り、この復元された DC は、ドメイン内の他の DC とは、厳密には同じ状態にならなくなります。

オブジェクトをレプリケートする

オブジェクトの追加、属性の変更など、ドメイン コントローラで何らかの更新を行うと、この更新操作に更新シーケンス番号 (USN) と呼ばれる 64 ビットの一意の数値が割り当てられます。Active Directory は、更新対象のオブジェクトや属性に USN のタグを付け、これらのレプリケーションが必要かどうかの判断材料にします。

Active Directory は属性単位でオブジェクトのレプリケーションを行います。つまり、あるオブジェクトのある属性を変更した場合、そのオブジェクト全体ではなく、変更された属性だけがレプリケートされます。この処理を実現するため、Active Directory は、レプリケーション メタデータを使用して、各属性の変更を追跡しています。属性のレプリケーション メタデータには、次のものがあります。

• ローカル USN。ローカル DC に対する変更操作を識別します。
• 変更のソース DC の invocationID。厳密には、この DC の対応する nTDSSettings オブジェクトの invocationID 属性です。DC における DIT の特定の生成処理を識別します。
• 元の操作の USN。ソース DC 上にあります。
• タイム スタンプ。ソース DC に変更が加えられた時のシステム時刻です。
• 32 ビットの連続したバージョン番号。この番号は、値が変更されるたびに大きくなります。

変更のレプリケート先 DC は、ソース DC に変更情報をリクエストするとき、前回正常にレプリケートされた変更の USN と最新ベクタを送信します。最新ベクタは、レプリケートされる NC のレプリカを格納するすべての DC から受信した USN のうち、最大の値を示します。ソース DC は、この情報を基に、レプリケート先 DC にまだ適用されていない更新情報だけを送信します。

レプリケート先 DC は、受信した属性の更新情報を処理する際に、各属性のバージョン番号を確認します。受信した属性のバージョン番号が現在のバージョン番号より大きい場合、DC は受信した値を保存します。受信した属性のバージョン番号が現在のバージョン番号と同じである場合、DC はタイムスタンプを比較し、タイムスタンプが新しい方の属性を使用します。タイムスタンプも一致している場合は、invocationID が大きい方の値を選択します。このようにして、すべての DC のすべての属性の値が、最終的に同じになります。

リンクされた値のレプリケーション

Windows 2000 の Active Directory では、属性に 1 つしか値がない場合も、複数の値がある場合も、レプリケーションの方法は同じでした。しかし、member 属性の複数の値が複数の DC 上で頻繁に変更されるような、大規模で動的なグループ オブジェクトでは、この方法はうまく機能しませんでした。たとえば、管理者 1 が DC 1 を使用して、あるグループにユーザーを追加したとします。その後レプリケーション待ち時間内に、管理者 2 が DC 2 を使用して同じグループに別のユーザーを追加した場合、最初の変更は完全に失われ、後からの変更だけが適用されます。この問題は、Windows Server 2003 でリンクされた値のレプリケーション (LVR) という処理の導入により解決されました。

Windows Server 2003 のフォレストの機能レベル、または Windows Server 2003 中間の機能レベルでは、Active Directory は、複数の値を持つ前方リンク属性の個々の値を個別にレプリケートし、各値に固有のレプリケーション メタデータを使用します。これにより、Windows 2000 での問題が事実上解決され、複数の DC 上でほぼ同時にグループ メンバシップが更新されてもデータが失われる心配はなくなりました。

ただし、1 点注意が必要です。フォレストの機能レベルを上げても、複数の値を持つ既存のリンク属性に、新しいレプリケーション メタデータが自動的に適用されるわけではありません。フォレストの機能レベルを上げた後で追加した値にだけ、新しいメタデータが適用されます。これがグループ メンバシップを回復する際にどれほど重要であるかについては、この後すぐにご説明します。

バックアップを作成する

Windows には、DC のシステム状態のバックアップを実行できる非常に基本的な NTBACKUP ユーティリティが付属しています。DC のシステム状態には、レジストリ、SYSVOL、Active Directory DIT ファイル、および重要なシステム ファイルが含まれます。サードパーティのほとんどのバックアップ ユーティリティには、DC のシステム状態のバックアップおよび復元機能があります。

ディスク ファイルにシステム状態のバックアップを取るには、次のコマンドを使用します。

NTBACKUP backup systemstate /F “<filename>”

<filename> の位置には、作成するバックアップ ファイルの名前を入力します。ファイル拡張子 .bkf を付けてください。

権限のない復元を実行する

削除された Active Directory オブジェクトは、バックアップから 2 段階の処理で復元できます。まず、DC をディレクトリ サービス復元モード (DSRM) で再起動した後、Windows の NTBACKUP ユーティリティか、同等のサードパーティ製品を使用して、システム状態のバックアップから Active Directory DIT 全体を復元します。この処理により、DIT 全体が上書きされます。

DC を DSRM で起動する方法は 2 とおりあります。DC のシステム コンソールを使用できる場合は、いったん DC をシャットダウンし、再起動する際に、Windows のブート メニューのプロンプトが表示されたら F8 キーを押します。メニューから [ディレクトリ サービス復元モード] を選択し、DSRM のパスワードを入力します。

リモート管理サーバーでは、Windows のブート メニューを表示できません。この場合は、[マイ コンピュータ] を右クリックし、メニューの [プロパティ] をクリックします。続いて、[詳細設定] タブをクリックし、[起動と回復] の [設定] ボタンをクリックします。[起動システム] の [編集] ボタンをクリックして boot.ini ファイルを開き、図 3 に示すように、行の最後に「/SAFEBOOT:DSREPAIR」スイッチを追加して保存します。boot.ini のスイッチの詳細については、microsoft.com/technet/ sysinternals/information/bootini.mspx を参照してください。

図 3** DSRM の起動オプションを設定する **(画像を拡大するには、ここをクリックします)

サーバーを再起動すると、DSRM で起動します。DC を通常モードで再起動するには、boot.ini ファイルから /SAFEBOOT スイッチを削除する必要があります。

DSRM パスワードを使用してログインしたら、再度 NTBACKUP コマンドを実行して、システム状態を復元します。今回はコマンド パラメータは指定しません (NTBACKUP をコマンド ラインから実行して復元を実行することはできません)。ウィザード画面が表示されたら、[ファイルと設定を復元する] をクリックし、[次へ] をクリックします。続いて、バックアップ ファイルを選択し、[システム状態] チェック ボックスをオンにします。図 4 を参照してください。

図 4** バックアップまたは復元ウィザードを使用してシステム状態を復元する **(画像を拡大するには、ここをクリックします)

この時点で DC を通常モードで起動すると、Active Directory のレプリケーション処理により、復元された DC がドメイン内の他の DC と同期され、復元データが最新のデータで上書きされてしまいます。もちろん、これは意図するところではありません。実際には、復元したオブジェクトで、ドメイン内の他のドメイン コントローラのデータを上書きする必要があります。

権限のある復元を実行する

NTDSUTIL は、バックアップから復元までの日数に 10 万を乗じた数だけ、各属性のバージョン番号を大きくします。1 日に 10 万回以上更新される属性がある場合を除き、復元された属性のバージョン番号は、他の DC のバージョン番号よりはるかに大きくなります。したがって、レプリケーションにより、これらの DC のデータは権限のある復元が行われたオブジェクトで上書きされます。バックアップから権限のない復元が行われたその他のオブジェクトは、最終的に、その他のドメイン コントローラの既存のデータで上書きされます。

権限のない復元の実行後、通常モードで再起動する前に、NTDSUTIL プログラムを使用して、回復したいオブジェクトについて権限のある復元を実行します。「権限のある復元」と言っても、オブジェクトを本当に復元するわけではなく、Active Directory を使用して、オブジェクトをその他の DC にレプリケートするだけです。このために、NTDSUTIL は、使用可能な次の USN をオブジェクトの属性のローカル USN に割り当てます。これにより、次に同期が行われる際に、オブジェクトがレプリケーション パートナーに送信されます。単一のオブジェクトを復元するには、DC を DSRM で起動し、次の手順に従います。

1. コマンド ウィンドウを開き、次のように入力します。

   ntdsutil
   

2. ntdsutil のプロンプトで、次のように入力します。

   authoritative restore
   

3. 権限のある復元のプロンプトで、次のように入力します。

   restore object “<DN of object to be restored>”
   

   たとえば、DRNET ドメインで、組織単位 (OU) Eng の Molly Clark のアカウントを復元するには、次のように入力します。

   restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
   

   ディレクトリ サブツリー全体 (たとえば 1 つの OU) に対して、権限のある復元を実行する場合は、次のように入力します。

   restore subtree “OU=Eng,DC=DRNET,DC=com”
   

   NTDSUTIL には、構成 NC やスキーマ NC を含めたドメイン全体に対して権限のある復元を実行する restore database コマンドもあります。しかし、ドメイン全体を復元するのは危険なので、お勧めしません。ドメイン全体を復元する必要がある場合は、まず 1 つのドメイン コントローラを復元し、ドメイン内のその他の DC を再び昇格させます。詳細については、「Active Directory フォレストの障害回復計画」を参照してください。

4. プロンプトが表示されたら、権限のある復元で個々のオブジェクトとその属性のバージョン番号が大きくなることを確認します。

5. 「quit」と 2 回入力して、ntdsutil を終了します。

6. DC を通常の Active Directory モードで再起動します。

次回、DC とパートナーのレプリケーションが行われると、復元したユーザーのデータがレプリケートされます。ただし、ユーザー オブジェクトの復元は、問題解決の半分に過ぎません。グループとそのメンバ間のリンクのようなオブジェクト リンクの扱いは、より複雑です。復元の前後には、いくつかの根本的な問題が発生します。ここからは、これらの問題について説明します。

まず、後方リンクを持つオブジェクトを削除した場合、何が起こるか確認しましょう。たとえば、1 つ以上のグループのメンバになっているユーザー オブジェクトを削除するとします。このユーザー オブジェクトのコピーを持っている各ドメイン コントローラは、コピーを廃棄オブジェクトに変換し、リンク テーブルから参照をすべて削除します。このようにして、ユーザーのドメイン内のすべてのグループ メンバシップからこのユーザー オブジェクトを削除します。グループ メンバシップは各 DC がローカルで更新するので、グループ メンバシップからユーザーを削除しても、この変更はレプリケートされません。グループの member 属性のバージョン番号とローカルの USN は変更されません。しばらくすると、他のドメインのリンク テーブルからファントム オブジェクトが削除されます。この場合も、グループの member 属性のレプリケーション メタデータは更新されません。

ユーザー ドメインのドメイン コントローラ上で DIT に対し権限のない復元を実行すると、ユーザー オブジェクトと、そのドメイン内のグループのグループ メンバシップがすべて復元されます。このため、復元された DC には不整合はありません。NTDSUTIL ユーティリティを使用して、ユーザーに対し権限のある復元を実行すると、ドメイン内のその他のすべての DC にユーザー オブジェクトがレプリケートされます。

しかし、ドメイン内の現在のグループのレプリケーション メタデータは変更されないので、復元された DC 上のグループの member 属性と他の DC のグループの member 属性に不整合が生じます。この場合、これらを共通の状態にする方法はありません。したがって、ユーザーのメンバシップは、ドメイン内の他の DC 上では復元されません。

問題: ドメイン内のグループ メンバシップが復元されない

ユーザー オブジェクトに対し権限のある復元しても、ユーザーのグループ メンバシップは復元されません。なぜでしょうか。ユーザーの memberOf 属性 (後方リンク) ではなく、グループ オブジェクトの member 属性 (前方リンク) を使用してメンバシップのリレーションシップが保存され、レプリケートされるからです。この場合、問題となるのはユーザーの古いグループ メンバシップを見つけ出す方法です。このメンバシップが見つかったら、今度は適切に回復する方法が問題になります。

マイクロソフトでは、ユーザーのグループ メンバシップの回復処理に徐々に改良を加えてきました。このため、実行している Active Directory のバージョンによって使用する方法が異なります。次のセクションでは、主に Windows 2000 Active Directory について説明します。

ユーザーの以前のグループ メンバシップは非常に簡単に特定できます。復元された DC の後方リンク属性、この場合はユーザー オブジェクトの memberOf 属性を調べるだけです。memberOf 属性には、ユーザーのドメインのローカル グループおよびグローバル グループのすべてのメンバシップが含まれています。復元されたユーザーのグループ メンバシップを一覧表示するには、Microsoft 管理コンソール (MMC) の Active Directory ユーザーとコンピュータ スナップイン (ADUC) か、Windows Server 付属の LDIFDE ユーティリティを使用できます。

次の LDIFDE コマンドを実行すると、Molly Clark がメンバになっている DRNET ドメイン内のグループが一覧表示され、結果が output.ldf ファイルに書き込まれます。

C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf

LDAP ツールを使用するときは必ず通常モードで DC を起動する必要があります。また入力方向のレプリケーションは無効にしてください。そうしないと、復元したデータが上書きされます。REPADMIN コマンドを使用すると、入力方向のレプリケーションを簡単に無効にすることができます。

REPADMIN /options <dcname>+DISABLE_INBOUND_REPL

<dcname> の位置には、復元する DC 名を入力します。作業が完了したら、–DISABLE_INBOUND_REPL を使用してレプリケーションを再度有効にしてください。

回復するユーザー数が少数の場合は、ADUC を使用して、該当ユーザーをグループに手動で追加する方法が簡単です。回復するユーザー数がある程度の数に達している場合は、処理の一部を自動化するツールを利用できます。Microsoft 製品サポート サービスから利用可能な Microsoft GROUPADD ユーティリティでは、ユーザーの以前のグループ メンバシップを一覧表示するために作成した LDIF ファイルを受け入れて、これらのメンバシップを再作成する LDIF ファイルを生成します。たとえば、この GROUPADD コマンドでは、前述の Molly Clark の例で作成した LDIF ファイルを処理できます。

C:\> groupadd /after_restore output.ldf

このコマンドは、Molly Clark がグループ メンバシップを持っていたドメインごとに、groupadd_<domain>.ldf という名前の新しい LDIF ファイルを生成します。<domain> の位置には、グループを更新するドメインの完全修飾ドメイン名を入力します。この LDIF ファイルは、次のコマンドでインポートできます。

C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf

Windows Server 2003 では、NTDSUTIL が改良され、member 属性内に存在する追加メタデータを利用して、リンクされた値のレプリケーション (LVR) 機能を使用できるようになっています。復元されたユーザー オブジェクトがドメイン内のグループのメンバであり、そのユーザーのグループ メンバシップが LVR メタデータと共に保存されていた場合、NTDSUTIL は member 属性の対応する値のバージョン番号を大きくします。これにより、復元されたメンバシップがレプリケートされます。

Windows Server 2003 SP1 バージョンの NTDSUTIL には、GROUPADD 機能が組み込まれていて、ユーザー オブジェクトに対し権限のある復元を行うと、自動的に LDIF ファイルが作成されます。図 5 はこの新しいバージョンの NTDSUTIL、図 6 は自動的に作成された LDIF ファイルの内容を示しています。

Figure 6 NTDSUTIL によって作成された LDIF ファイルの内容

dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-

図 5** GROUPADD 機能が組み込まれた新しい NTDSUTIL **(画像を拡大するには、ここをクリックします)

多数のユーザーおよびグループを含む OU 全体を復元する場合は、手動でユーザーをグループに追加していたのでは手間がかかります。グループ自体に対し権限のある復元を実行することで、復元されたグループ メンバシップを回復することができます。

ただし、グループに対し権限のある復元を実行する処理には、2 つの問題点があります。1 つは明らかな問題です。グループを復元すると、そのグループ内のメンバシップがバックアップ時の状態に戻ります。したがって、復元されたグループには、前回のバックアップ以降に加えられた変更内容をすべて適用し直す必要があります。もう 1 つはややわかりにくいのですが、Active Directory のレプリケーション方法と関係のある問題です。ユーザーとグループの両方に対し権限のある復元を実行した後、これらがレプリケートされる順番は決まっていません。グループ オブジェクトが、復元されたユーザー オブジェクトより先に DC にレプリケートされた場合、ソースのドメイン コントローラは、グループからユーザー参照を自動的に削除します。これは、ユーザー オブジェクトがまだその DC 上に存在していないからです。ユーザー オブジェクトが後でレプリケートされた場合でも、このオブジェクトはグループに追加されません。

この問題を解決する最も簡単な方法は、グループに対する権限のある復元をもう一度行うことです。最初の権限のある復元を実行した後、通常モードで再起動し、レプリケーションが正常に行われていることを確認します。次に DSRM で再起動し、NTDSUTIL を実行して、ユーザーがメンバになっているグループに対し権限のある復元を実行します。こうすることで、通常モードで再起動したとき、ユーザー オブジェクトがレプリケートされた後に、そのオブジェクトを参照するグループ オブジェクトがレプリケートされます。

問題: 他のドメインのグループ メンバシップが復元されない

「このユーザーはどのグループのメンバだったか」という問題は、実際には結構厄介です。復元しようとしているユーザーは、他のドメインのローカル グループやユニバーサル グループのメンバであった可能性があります。この場合、権限のない復元では、グループ メンバシップは復元されません。では、ユーザーが他のドメインのどのグループのメンバになっているかは、どのようにしてわかるのでしょうか。答えはグローバル カタログにあります。グローバル カタログには、固有のドメインのデータの他に、フォレスト内の他のドメインのデータの読み取り専用コピーが含まれています。

グローバル カタログに含まれているフォレスト全体のデータを利用するには、グローバル カタログに対して権限のない復元を実行します。つまり、まず第一にグローバル カタログのバックアップが必要になります。LDIFDE を実行してユーザーのグループ メンバシップを特定できたら、そのユーザーの他のドメインのユニバーサル グループ メンバシップを見つけることができます。

回復中のユーザーのグループ メンバシップ一覧が表示されたら、既定のポート 389 ではなく、グローバル カタログ ポート 3268 に接続し、検索先としてフォレストのルート ドメインを指定します。LDIFDE は、回復されたユーザーのグループ メンバシップを表示します。このメンバシップには、フォレスト内のすべてのドメインのユニバーサル グループのメンバシップも含まれています。具体的な方法は次のとおりです。

C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf

グローバル カタログ上で GROUPADD または新しい NTDSUTIL を実行すると、LDIF ファイルがユーザーのドメインに対して 1 つ、復元されたユーザーがメンバになっていたユニバーサル グループのある各ドメインに対して 1 つずつ生成されます。これらの LDIF ファイルをインポートすると、そのユーザーのすべてのグループ メンバシップが復元されます。これでだいたい終わりですが、次の問題にぶつかります。

問題: 他のドメインのローカル グループ メンバシップを回復する

Windows Active Directory 環境には、3 種類のグループが存在します。グローバル グループは、同じドメインのメンバだけで構成されるグループですが、自分のドメインと、フォレスト内のその他のドメインのドメイン ローカル グループ内でメンバとして使用できます。グローバル グループの member 属性は、グローバル カタログには表示されません。しかし、グローバル グループには自分のドメインのメンバしか含まれないので、問題はありません。ユニバーサル グループは、任意のドメインのメンバから構成されるグループであり、フォレスト内の他のユニバーサル グループ、フォレスト内の自分のドメインおよびその他のドメインのドメイン ローカル グループ内でメンバとして使用できます。ユニバーサル グループの member 属性は、グローバル カタログにレプリケートされます。ドメイン ローカル グループは、フォレスト内の任意のドメインのメンバから構成されるグループですが、他のドメインのグループ内メンバとしては使用できません。また、ドメイン ローカル グループの member 属性は、グローバル グループの member 属性と同様、グローバル カタログには表示されません。つまり、他のドメインのドメイン ローカル グループ内のユーザーのメンバシップは、簡単には回復できません。

Windows Server 2003 SP1 より前までは、外部ドメインのドメイン ローカル グループ メンバシップを回復するには、各ドメインの DC を復元し、復元されたユーザーが含まれていたドメイン ローカル グループのドメイン データを手動で検索して、このユーザーを特定したグループに追加し直す必要がありました。この方法は、ドメイン数の多い大規模な環境ではたいへん時間がかかります。

Windows Server 2003 SP1 バージョンの NTDSUTIL では、この点が強化されています。ドメイン コントローラ上で NTDSUTIL を実行すると、復元されたユーザー オブジェクトの DN と GUID を含むテキスト ファイルが作成されます。次に、各外部ドメインについて、単一の DC に対し権限のない復元を実行し、このテキスト ファイルを DC にコピーした後、NTDSUTIL を実行して、新しいドメイン固有の LDIF ファイル (回復されたユーザーを元々メンバだったドメイン ローカル グループに追加する) を生成します。

このためには、外部ドメインごとに DC 上で次のステップを実行します。

1. 外部ドメインの DC を DSRM で起動します。
2. NTBACKUP を使用して、復元されたユーザーのグループ メンバシップを含む DIT のコピーを復元します。
3. NTDSUTIL で作成された .txt ファイルを作業対象の DC にコピーします。
4. コマンド ウィンドウを開き、「ntdsutil」と入力します。
5. 「authoritative restore」と入力します。
6. 「create LDIF file(s) from <file name>」と入力します。<file name> にはテキスト ファイルの名前を入力します。
7. 「quit」と 2 回入力して、ntdsutil を終了します。
8. DC を通常の Active Directory モードで再起動します。
9. 「ldifde –i –f <ldif filename>」と入力します。<ldif filename> には作成した LDIF ファイルの名前を入力します。

これで、削除されたユーザーのグループ メンバシップがすべて復元されました。

ステップ バイ ステップ

Active Directory ユーザーとそのグループ メンバシップの回復処理は簡単ではありません。特に複数ドメイン環境の場合、処理は複雑になります。グループ メンバシップを正常に回復するための手順は、実行中の Windows のバージョンによって異なります。

Windows 2003 SP1 を使用している場合は、次の手順を参照してください。

1. GC を DSRM で起動し、削除されたユーザーを含むバックアップを使用してシステム状態の復元を実行します。
2. NTDSUTIL を使用して、削除されたユーザーに対し権限のある復元を実行します。NTDSUTIL により、復元されたオブジェクトの DN と GUID を含むテキスト ファイルが 1 つと、ユーザーのグループ メンバシップの復元に使用する 1 つ以上の LDIF ファイルが作成されます。
3. LDIFDE –i –f <LDIF filename> を実行して、現在のドメインとその他のドメインのグループ メンバシップをインポートします。<LDIF filename> には、手順 2 で作成した LDIF ファイルの名前を入力します。
4. グローバル カタログを通常モードで再起動します。
5. 各外部ドメインの DC を DSRM で起動し、復元されたユーザーのグループ メンバシップを含むバックアップを使用して、システム状態の復元を実行します。
6. create ldif files コマンドを使用して、NTDSUTIL を実行します。
7. DC を通常モードで再起動します。
8. LDIFDE –i –f <LDIF filename> を実行して、外部ドメイン内のグループ メンバシップを復元します。<filename> には、手順 6 で作成した LDIF ファイルの名前を入力します。
9. ここで、REPADMIN /syncall を実行して、強制的にレプリケーションを実行することもできます。

SP1 をまだ適用していない Windows Server 2003 を実行している場合、または Windows 2000 を実行している場合、追加の手順が必要です。旧バージョンの NTDSUTIL では LDIF ファイルは作成されません。GROUPADD ユーティリティを使用して作成する必要があります。次のようにします。

1. グローバル カタログを DSRM で起動し、削除されたユーザーを含むバックアップを使用してシステム状態の復元を実行します。
2. NIC を無効にするか、ケーブルを抜いて、入力方向のレプリケーションを無効にします。
3. グローバル カタログを通常モードで再起動します。
4. LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf を実行して、ユーザーのメンバシップをダンプします。<dn> の位置には識別名を入力します。
5. GROUPADD /after_restore membership.ldf を実行して、LDIF ファイルを作成します。
6. LDIFDE –i –f <filename> を実行して、現在のドメインとその他のドメインのグループ メンバシップをインポートします。<filename> には、手順 5 で GROUPADD を使用して作成した LDIF ファイルの名前を入力します。
7. REPADMIN /options <dcname> –DISABLE_INBOUND_REPL を使用して、入力方向のレプリケーションを再度有効にします。
8. 各外部ドメインの DC を DSRM で起動し、復元されたユーザーのグループ メンバシップを含むバックアップを使用して、システム状態の復元を実行します。
9. DC を通常モードで再起動します。
10. LDIFDE –i –f <filename> を実行して、外部ドメイン内のグループ メンバシップを復元します。<filename> には、手順 5 で GROUPADD を使用して作成した LDIF ファイルの名前を入力します。
11. ここで、REPADMIN /syncall を実行して、強制的にレプリケーションを実行することもできます。

Windows Server 2003 SP1 より前の環境の場合、あとは復元されたユーザーの外部ドメイン ローカル グループのメンバシップを回復するだけです。ドメイン ローカル グループのメンバシップを手動で復元するか、バックアップから DC を復元して、ドメイン ローカル グループに対し権限のある復元を実行します。

まとめ

Active Directory 環境でうっかりユーザーや OU を削除してしまうのは、よくあることです。しかし、削除されたユーザーとそのグループ メンバシップを復元するのは驚くほど複雑で手間がかかり、間違いやすい作業です。こうした障害からできるだけ短時間で回復するには、オブジェクトのリンク、レプリケーション、削除、および権限のある復元について理解しておく必要があります。

実稼働環境ですべての手順をいきなり正しく実行できるはずはありません。あなたの会社の CEO のユーザー オブジェクトを回復する必要が生じてもあわてずに済むように、削除したオブジェクトの回復計画を紙に書き記しておくことをお勧めします。また、実際のデータで実行する前に、少なくとも 1 ～ 2 回は、その計画の手順を訓練しておきましょう。上司や CEO から感心、評価されること請け合いです。

参考資料

• Active Directory から削除されたユーザーおよびユーザーのグループ メンバシップを復元する方法
• Microsoft 製品サポート サービス
• ステップバイステップ ガイド : Active Directory の管理

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; 許可なしに一部または全体を複製することは禁止されています.