次の方法で共有

Active Directory フォレストの回復 - フォレストを回復する方法を決定する

Active Directory フォレスト全体を回復するには、使用可能なバックアップからすべてのドメインに少なくとも 1 つのドメイン コントローラー (DC) を復元する必要があります。 フォレストを回復すると、フォレスト内の各ドメインが、最新の信頼できるバックアップの時点の状態に復元されます。

失われるもの

復元操作により、少なくとも次の Active Directory データが失われる可能性があります。

  • 最新の信頼できるバックアップの後に追加されたすべてのオブジェクト (ユーザーやコンピューターなど)
  • 最新の信頼できるバックアップ以降に既存のオブジェクトに対して行われたすべての更新
  • 最新の信頼できるバックアップ以降に AD DS の構成パーティションまたはスキーマ パーティションに対して行われたすべての変更 (スキーマの変更など)

パスワードの知識

  1. フォレスト内の各ドメインのドメイン管理者アカウントのパスワードを知っている必要があります。 望ましいのは、あらかじめ登録された Administrator アカウントのパスワードです。
  2. また、DC のシステム状態の復元を実行するには、DSRM のパスワードもわかっている必要があります。

バックアップが有効である限り、Administrator アカウントと DSRM パスワード履歴を安全な場所にアーカイブすることをお勧めします。 つまり、廃棄標識の有効期間内、または Active Directory のごみ箱が有効になっている場合は削除されたオブジェクトの有効期間内に行います。

覚えやすくするため、DSRM パスワードをドメイン ユーザー アカウントと同期することもできます。 詳細については、 こちらの記事を参照してください。 DSRM アカウントの同期は、準備の一環として、フォレストの回復の前に行う必要があります。

注意

Administrator アカウントは既定では組み込みの Administrators グループのメンバーであり、Domain Admins グループと Enterprise Administrators グループも同様です。 このグループは、ドメイン内のすべての PC のフル コントロール権限を持っています。

使用するバックアップを決定する

複数のバックアップから選択できるように、ドメインごとに少なくとも 2 つの書き込み可能な DC を定期的にバックアップします。 必要に応じて 1 つ以上の DC と、SYSVOL データ復旧用の PDC エミュレーター操作マスターを選択します。

Note

読み取り専用ドメイン コントローラー (RODC) のバックアップを使って書き込み可能 DC を復元することはできません。 障害が発生する数日前に作成されたバックアップを使用して、DC を復元することをお勧めします。 一般に、復元されるデータの新しさと安全性の間のトレードオフを決定する必要があります。 より新しいバックアップを選ぶと、より有用なデータが回復されますが、復元されたフォレストに危険なデータが再び導入されるリスクが高くなる可能性があります。

システム状態のバックアップの復元は、バックアップの元のオペレーティング システムとサーバーによって異なります。 たとえば、システム状態のバックアップを異なるサーバーに復元してはなりません。 この場合、次の警告が表示されることがあります。

警告

指定したバックアップは、別のサーバーのバックアップであり、現在のサーバーのものではありません。 別のサーバーのバックアップを使用して、現在のサーバーに対してシステム状態の回復を実行すると、サーバーが使用不可能になる可能性があるため、推奨されません。 このバックアップを現在のサーバーの回復に使用しますか?

Active Directory を異なるハードウェアに復元する必要がある場合は、サーバーの完全バックアップを作成し、サーバーの完全回復の実行を計画してください。

重要

システム状態のバックアップを、新しいハードウェアまたは同じハードウェアの Windows Server の新しいインストールに復元することはサポートされていません。 Windows Server が同じハードウェアに再インストールされている場合 (推奨)、次の順序でドメイン コントローラーを復元できます。

  1. オペレーティング システムおよびすべてのファイルとアプリケーションを復元するには、サーバーの完全復元を実行します。
  2. SYSVOL を信頼できるものとしてマークするには、wbadmin.exe を使用してシステム状態の復元を実行します。

詳細については、「Windows 7 インストールを復元する方法」を参照してください。

障害の時刻が不明な場合は、さらに調査して、最も新しい安全な状態のフォレストが保持されているバックアップを特定します。

このアプローチはあまりお勧めできません。 そのため、フォレスト全体の障害が発生した場合に、障害のおおよその日時を特定できるよう、AD DS の正常性状態に関する詳細なログを毎日保持することを強くお勧めします。 また、迅速に回復できるよう、バックアップのローカル コピーを保持する必要があります。

Active Directory のごみ箱が有効になっている場合、バックアップの有効期間は deletedObjectLifetime の値または tombstoneLifetime の値のどちら小さい方になります。 詳しくは、「Active Directory のごみ箱のステップ バイ ステップ ガイド」をご覧ください。

または、Active Directory データベース マウント ツール Dsamain.exe とライトウェイト ディレクトリ アクセス プロトコル (LDAP) ツール (Ldp.exe、Active Directory ユーザー、コンピューターなど) を使用して、最も新しい安全な状態のフォレストが保持されているバックアップを特定することもできます。 Windows Server オペレーティング システムに含まれる Active Directory データベース マウント ツールは、LDAP サーバーとして、バックアップまたはスナップショットに格納されている Active Directory のデータを公開します。 LDAP ツールを使用してデータを参照できます。 この方法には、AD DS のバックアップの内容を調べるために、ディレクトリ サービス復元モード (DSRM) で DC を再起動する必要がないという利点があります。

Active Directory データベース マウント ツールの詳しい使い方については、Active Directory データベース マウント ツールのステップ バイ ステップ ガイドに関する記事をご覧ください。

ntdsutil snapshot コマンドを使って、Active Directory データベースのスナップショットを作成することもできます。 タスクをスケジュールして定期的にスナップショットを作成することにより、一定の期間についての Active Directory データベースの追加コピーを一度に取得できます。 これらのコピーを使用すると、フォレスト全体の障害がいつ発生したのかがより正確にわかり、最適なバックアップを選んで復元できます。 スナップショットを作成するには、ntdsutil またはリモート サーバー管理ツール (RSAT) を使用します。

ターゲット DC で実行されている Windows Server のバージョンは何でもかまいません。 ntdsutil snapshot コマンドの使い方について詳しくは、「Snapshot」をご覧ください。

復元するドメイン コントローラーを決定する

復元するドメイン コントローラーを決定するときの重要な要素は、復元プロセスの容易さです。 ドメインごとに、復元用の優先 DC として専用の DC を用意することをお勧めします。 復元専用 DC を用意すると、復元テストの実行に使用したものと同じソース構成を使用することで、フォレストの回復の確実な計画と実行が容易になります。 回復のスクリプトを作成すると、DC が操作マスター ロールを持っているかどうか、GC または DNS サーバーかなど、さまざまな構成との競合を回避できます。

Note

すべてのロールを常に獲得するため、単純化のために操作マスター ロール所有者を復元することはお勧めしません。 通常、PDC には SYSVOL データの最適なコピーがあるため、PDC エミュレーター操作マスターから作成されたバックアップを使用して SYSVOL 回復が行われる場合があります。

良好なバックアップとは、正常に復元でき、障害の数日前に作成されていて、可能な限り有用なデータが含まれているバックアップです。 次の条件を最もよく満たす DC を選びます。

  • 書き込み可能な DC。 これは必須です。

  • VM-GenerationID をサポートするハイパーバイザー上の仮想マシンとして Windows Server 2012 以降を実行している DC。 この DC は、複製のソースとして使用できます。 一般に、最新の OS を持つ適切なバックアップを備えた DC を使用します。

  • 物理的に、または仮想ネットワーク上でアクセスすることができ、できればデータセンターに配置されている DC。 これにより、フォレストの回復中にネットワークから簡単に分離できます。

  • サーバーの良好な完全バックアップがある DC。

  • ドメイン ネーム システム (DNS) ロールを実行し、フォレストとドメイン ゾーンをホストしている DC。

  • グローバル カタログ (GC) として構成された DC。

  • Windows 展開サービスを使用する場合は、BitLocker ネットワーク ロック解除を使用するように構成されていない DC。 フォレストの回復中にバックアップから復元する最初の DC に対して BitLocker ネットワーク ロック解除を使用することはサポートされていません。 Windows 展開サービス (WDS) を展開した DC では、最初の DC のロックを解除するには Active Directory と WDS が動作している必要があるため、BitLocker ネットワーク ロック解除を唯一のキーの保護機能として使用することはできません。 最初の DC を復元する前は、WDS 用に Active Directory をまだ使用できないので、ロックを解除することはできません。

    BitLocker ネットワーク ロック解除を使用するように DC が構成されているかどうかを確認するには、次のレジストリ キーでネットワーク ロック解除の証明書が示されていることを調べます。

    HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemCertificatesFVE_NKP

重要

Active Directory を含むバックアップ ファイルを処理または復元するときは、セキュリティ手順を維持します。 フォレストの回復を緊急に行う必要があると、セキュリティのベスト プラクティスをうっかり見落とす可能性があります。

現在のフォレストの構造と DC の機能を確認する

フォレスト内のすべてのドメインを明らかにして、現在のフォレストの構造を特定します。 各ドメイン内のすべての DC (特にバックアップがある PC) と、複製のソースとして使用できる仮想化 PC の一覧を作成します。

フォレストのルート ドメインを最初に回復するため、このドメインの DC の一覧が最も重要です。 フォレストのルート ドメインを復元した後は、Active Directory のスナップインを使って、フォレスト内の他のドメイン、PC、サイトの一覧を取得できます。

フォレスト内のドメインごとに、そのドメインの Active Directory データベースの信頼できるバックアップを持つ、1 つの書き込み可能 DC を特定します。 DC を復元するためのバックアップを選ぶときは注意してください。 障害の日付と原因がわかっている場合の一般的な推奨事項は、その日付の数日前に作成された安全なバックアップを特定して使用することです。

次の例に示すように、ドメイン内の各 DC の機能を示す表を準備します。 これは、回復の後で、フォレストの障害前の構成に戻すのに役立ちます。

DC の名前 オペレーティング システム FSMO GC RODC Backup DNS Server Core VM
DC_1 Windows Server 2019 スキーマ マスター、ドメイン名前付けマスター はい いいえ 有効 いいえ 番号 はい
DC_2 Windows Server 2019 なし はい いいえ イエス はい いいえ はい
DC_3 Windows Server 2022 インフラストラクチャ マスタ いいえ いいえ 番号 イエス イエス はい
DC_4 Windows Server 2022 PDC エミュレーター、RID マスター はい いいえ いいえ いいえ 番号 はい
DC_5 Windows Server 2022 なし いいえ 番号 イエス はい いいえ はい
RODC_1 Windows Server 2016 なし 有効 イエス イエス イエス イエス はい
RODC_2 Windows Server 2022 なし 有効 はい いいえ イエス イエス はい

上記の例には、DC_1、DC_2、DC_4、DC_5 の 4 つのバックアップ候補があります。 これらのバックアップ候補のうち、1 つだけを復元します。 推奨される DC は、次の理由により DC_5 です。

  • これは、Windows Server 2022 を仮想 DC として実行し、複製が許可されている (または複製できない場合は削除できる) ソフトウェアを実行するため、仮想化 DC 複製に適したソースです。 復元が完了すると、PDC エミュレーターの役割がそのサーバーに取得され、Cloneable Domain Controllers グループに追加できるようになります。
  • Windows Server 2022 の完全インストールが実行されます。 Server Core のインストールを実行している DC は、回復の対象としてはあまり便利ではありません。 コマンド ライン インターフェイスを使用した Windows Server の管理に慣れている場合、これは要因にならない可能性があります。
  • それは DNS サーバーです。

Note

DC_5 はグローバル カタログ サーバーではないため、復元後にグローバル カタログを削除する必要がないという点で若干の利点があります。 ただし、Rid 500 の既定の Administrator アカウントで回復を開始するか、レジストリ値 ignoregcfailures を使用する必要があります。

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Value: IgnoreGCFailures
Type: REG_DWORD
Data: 0 – Require GlobalCatalog for logon (default)
1 – Allow logon without groups from GC

通常、GC ロールを削除する追加の手順よりも、他の要因の方が重要です。 DC_3 または DC_4 も、持っている操作マスター ロールが問題にならないため、適切な選択肢です。 オプションを検討し、実際の回復状況に応じて選択します。 通常は、PDC 操作マスター バックアップを復元して計画とテストを行うことができますが、このバックアップが、たとえば時刻が間違っているために機能しない場合は、同じドメインの GC からバックアップを選択します。

フォレストを分離して回復する

最初に復元された DC を運用環境に戻す前に、すべての書き込み可能 DC をシャットダウンすることをお勧めします。 これにより、回復されたフォレストに危険なデータがレプリケートされないようにすることができます。 特に、すべての操作マスター ロール所有者をシャットダウンすることが重要です。

Note

場合によっては、システムのダウンタイムを最小限にするため、各ドメインで回復する予定の最初の DC を分離されたネットワークに移動し、他の DC をオンラインのままにできるようにすることができます。 たとえば、スキーマのアップグレードの失敗から回復する場合は、分離環境で回復手順を実行している間、運用ネットワークでドメイン コントローラーを実行し続けることができます。

仮想化 DC

仮想化 DC を実行している場合は、それを運用ネットワークから分離された仮想ネットワークに移動し、そこで回復を実行することができます。 仮想化 DC を別のネットワークに移動すると、次の 2 つの利点があります。

  • 回復された DC では、フォレストの回復の原因となった問題は再現されません。
  • 仮想化 DC の複製は分離されたネットワークで実行できるため、運用ネットワークに戻す前に、必要な数の DC を実行してテストすることができます。

物理 DC

物理ハードウェアで DC を実行している場合は、フォレストのルート ドメインに復元する予定の最初の DC のネットワーク ケーブルを切断します。 可能であれば、他のすべての DC のネットワーク ケーブルも切断します。 これにより、フォレストの回復プロセスの間に DC が誤って開始された場合に、DC がレプリケートされるのを防ぐことができます。

大規模なフォレスト

複数の場所に分散する大規模なフォレストでは、書き込み可能なすべての DC を確実にシャットダウンするのが難しい場合があります。 このため、メタデータのクリーンアップに加えて、コンピューター アカウントや krbtgt アカウントのリセットなどの回復手順は、回復された書き込み可能 DC が危険な書き込み可能 DC でレプリケートされないように設計されています (フォレスト内でまだオンラインになっているものがある場合)。

ただし、書き込み可能 DC をオフラインにすることによってのみ、レプリケーションが行われないことを保証できます。 そのため、可能な限り、フォレストの回復中に書き込み可能 DC をシャットダウンして物理的に分離することができる、リモート管理テクノロジを展開する必要があります。

RODC

RODC は、書き込み可能 DC がオフラインの間も動作を継続できます。 他の DC はどの RODC からも変更を直接レプリケートしないので (特に、スキーマや構成コンテナーの変更がレプリケートされません)、回復中に書き込み可能 DC と同じリスクが生じることはありません。 すべての書き込み可能 DC が回復されてオンラインになったら、すべての RODC を再構築する必要があります。

RODC は、回復操作が並列で実行されている間、それぞれのサイトにキャッシュされているローカル リソースへのアクセスを引き続き許可します。 RODC にキャッシュされていないローカル リソースからは、書き込み可能 DC に認証要求が転送されます。 書き込み可能 DC はオフラインであるため、これらの要求は失敗します。 また、パスワードの変更などの一部の操作も、書き込み可能 DC を回復するまで機能しません。

ハブ アンド スポーク ネットワーク アーキテクチャを使用している場合は、最初にハブ サイトの書き込み可能 DC の回復に集中できます。 リモート サイトの RODC は、後で再構築できます。

侵害された AD データベース

書き込み可能な DC の AD データベースが侵害された場合は、回復後に新しい KDS ルート キーを作成し、侵害のシナリオに応じてすべてのグループ管理されたサービス アカウント (gMSA) を再作成する必要があります。 詳細については、「ゴールデン gMSA 攻撃から回復する方法」をご覧ください。

次のステップ