Active Directory フォレストの回復 - 初期復旧を実行する

  • [アーティクル]

適用先: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2 および 2012

このセクションには、次の手順が記載されています。

各ドメイン内の最初の書き込み可能なドメイン コントローラーを復元する

フォレスト ルート ドメインの書き込み可能な DC から、このセクションの手順を完了し、最初の DC を復元します。 フォレスト ルート ドメインは、Schema admins グループと Enterprise Admins グループを格納するため、重要です。 また、フォレスト内の信頼階層を維持するのにも役立ちます。 また、フォレストのルート ドメインは、通常、フォレストの DNS 名前空間の DNS ルート サーバーを保持します。 そのため、そのドメインの Active Directory 統合 DNS ゾーンには、フォレスト内の他のすべての DC のエイリアス (CNAME) リソース レコード (これはレプリケーションに必要) とグローバル カタログ DNS リソース レコードが含まれています。

フォレスト ルート ドメインを回復した後、同じ手順を繰り返して、フォレスト内の残りのドメインを回復します。 複数のドメインを同時に回復できます。ただし、信頼階層または DNS 名前解決の中断を防ぐために、子を回復する前に常に親ドメインを回復するようにしてください。

回復するドメインごとに、バックアップから書き込み可能な DC を 1 つを復元します。 これは、DC がフォレストの障害の原因によって影響を受けていないデータベースを持っている必要があるため、回復の最も重要な部分です。 実稼働環境に導入される前に、完全にテストされた信頼できるバックアップを用意することが重要です。

次に、以下の手順のようにします。 特定の手順を実行する手順については、「AD フォレストの回復 - 手順」を確認してください。

  1. 物理サーバーを復元する場合は、ターゲット DC のネットワーク ケーブルが接続されておらず、実稼働ネットワークに接続されていないことを確認してください。 仮想マシンの場合、ネットワーク アダプターを削除するか、別のネットワークに接続されているネットワーク アダプターを使用して、実稼働ネットワークから分離した状態で回復プロセスをテストすることができます。

  2. これはドメイン内の最初の書き込み可能 DC なので、AD DS の権限のない復元と SYSVOL の権限のある復元を実行する必要があります。 復元操作は、Windows Server バックアップ (推奨) などの Active Directory 対応のバックアップおよび復元アプリケーションを使用して完了する必要があります。 ホストで Hyper-Vistor 生成 ID がサポートされている場合は、VM スナップショットを使用して非認証復元を実行することもできます。

    • 障害から復旧した後、新しいインスタンスで SYSVOL フォルダーのレプリケーションを再開する必要があるため、最初に復旧した DC では SYSVOL の権限のある復元が必要です。 ドメインに追加されたそれ以降のすべての DC は、SYSVOL フォルダーを権限があると選択されたフォルダーのコピーで再同期する必要があります。

      警告

      フォレスト ルート ドメインで復元される最初の DC に対してのみ、SYSVOL の権限のある (またはプライマリ) 復元操作を実行します。 他の DC で SYSVOL のプライマリ復元操作を誤って実行すると、SYSVOL データのレプリケーションの競合が生じます。 AD DS の権限のない復元と SYSVOL の権限のある復元を実行するには、次の 2 つのオプションがあります。

    • サーバーの完全復旧を実行し、SYSVOL の権限のある同期を強制します。 詳細な手順については、「サーバーの完全復旧の実行」と「DFSR レプリケートされた SYSVOL の権限を持つ同期を実行するには」を参照してください。

    • サーバーの完全復旧を実行し、その後にシステム状態の復元を実行します。 このオプションを使用するには、完全なサーバー バックアップとシステム状態のバックアップの両方の種類のバックアップを事前に作成する必要があります。 詳細な手順については、「サーバーの完全復旧の実行」と「認証されていない Active Directory Domain Services 復元の実行」を参照してください。

  3. 書き込み可能 DC を復元して再起動した後、障害が DC のデータに影響していないことを確認します。 DC データが破損している場合は、別のバックアップを使用して手順 2 を繰り返します。

    • 復元されたドメイン コントローラーが操作マスターの役割をホストしている場合は、書き込み可能なディレクトリ パーティションのレプリケーションが完了するまで AD DS が使用できないようにするために、次のレジストリ エントリを追加する必要がある場合があります。

      HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl
Perform Initial Synchronizations

      データ型が REG_DWORD で、値が 0 のエントリを作成します。 フォレストが完全に回復したら、このエントリの値を 1 にリセットできます。これは、再起動し操作マスターの役割を保持するドメイン コントローラーが、自身をドメイン コントローラーとして提供しクライアントにサービスを提供し始める前に、既知のレプリカ パートナーとの AD DS 受信および送信レプリケーションが正常に行われる必要があることを示します。 初期同期要件の詳細については、「Active Directory FSMO ロール」を参照してください。

  4. データを復元して検証してから、このコンピューターを実稼働ネットワークに参加させる前に、次の手順に進みます。

  5. フォレスト全体の障害がネットワークの侵入や悪意のある攻撃に関連していると思われる場合は、Enterprise Admins、Domain Admins、Schema Admins、Server Operators、Account Operators グループなどのメンバーを含むすべての管理アカウントのアカウント パスワードをリセットします。 krbtgt アカウントの完全なパスワード リセット手順も必要です。. 管理アカウントのパスワードのリセットは、フォレストの回復の次のフェーズで、追加のドメイン コントローラーをインストールする前に完了する必要があります。

    この場合も、管理アカウントが引き継がれたかのようにすべての GMSA パスワードを置き換える作業を行います。攻撃者は、GMSA として認証できる情報を取得している可能性があります。 詳細については、「ゴールデン GMSA 攻撃」を参照してください。

  6. ユーザー アカウントが侵害されたと思われる場合は、ドメイン内のすべてのユーザーのユーザー パスワードリセットを計画する必要もあります。

  7. フォレスト ルート ドメイン内の最初に復元された DC で、すべてのドメイン全体およびフォレスト全体の操作マスターの役割を強制します。 エンタープライズ管理者とスキーマ管理者の資格情報は、必要に応じてフォレスト全体の操作マスター ロールを押収するために必要です。

    各子ドメインで、必要に応じてドメイン全体の操作マスターの役割を強制します。 操作マスターの役割は復元された DC に一時的にのみ保持される場合がありますが、これらの役割を強制することで、フォレストの回復プロセスでどの DC がこの時点でホストしているかを確認できます。 回復後のプロセスの一部として、必要に応じて操作マスターの役割を再配布できます。 操作マスターの役割の強制の詳細については、「操作マスターの役割を強制する」を参照してください。 操作マスターの役割を配置する場所に関する推奨事項については、「操作マスターとは」を参照してください。 「AD DC での柔軟なシングル マスター操作 (FSMO) の配置と最適化」も参照してください。

  8. バックアップから復元していない、フォレスト ルート ドメイン内の他のすべての書き込み可能な DC (この最初の DC を除く、ドメイン内のすべての書き込み可能な DC) のメタデータをクリーンアップします。 Windows Server 2012 以降、または Windows 10 以降の RSAT に含まれる Active Directory ユーザーとコンピューターまたは Active Directory サイトとサービスのバージョンを使用している場合、DC オブジェクトを削除するとメタデータのクリーンアップが自動的に実行されます。 また、削除された DC のサーバー オブジェクトとコンピューター オブジェクトも自動的に削除されます。 詳細については、「削除された書き込み可能 DCのメタデータのクリーニング」および「AD DS サーバー メタデータのクリーンアップ」を参照してください。

    別のサイトの DC に AD DS がインストールされている場合、メタデータをクリーンアップすることで、NTDS 設定オブジェクトが重複しないようにすることができます。 また、知識整合性チェッカー (KCC) において、DC が存在しない場合にレプリケーション リンクを作成する手間を省くことができる可能性があります。 さらに、メタデータのクリーンアップの一部として、ドメイン内の他のすべての DC の DC ロケーター DNS リソース レコードは、DNS から削除されます。

    ドメイン内の他のすべての DC のメタデータが削除されるまで、この DC は、回復前の RID マスターの場合、RID マスターの役割を担いません。したがって、新しい RID を発行することはできません。 イベント ビューアーのシステム ログにこの失敗を示すイベント ID 16650 が表示される場合がありますが、メタデータをクリーンアップした後しばらくすると、成功を示すイベント ID 16648 が表示されるはずです。

  9. AD DS に格納されている DNS ゾーンがある場合は、復元した DC にローカル DNS サーバー サービスがインストールされ、実行されていることを確認します。 この DC がフォレスト障害の前に DNS サーバーではなかった場合は、DC に DNS サーバーの役割をインストールして構成するか、復元環境で DNS サーバーを使用できる必要があります。

    フォレスト ルート ドメインで、復元された DC の IP アドレスを優先 DNS サーバーとして構成します。 この設定は、ローカル エリア ネットワーク (LAN) アダプターの TCP/IP プロパティで構成できます。 これは、フォレスト内の最初の DNS サーバーです。 詳細については、「ドメイン ネーム システム (DNS) クライアント設定の推奨事項」を参照してください。

    各子ドメインで、復元された DC を、優先 DNS サーバーとして、フォレスト ルート ドメイン内の最初の DNS サーバーの IP アドレスで構成します。 この設定は、LAN アダプターの TCP/IP プロパティで構成できます。 詳細については、「ドメイン ネーム システム (DNS) クライアント設定の推奨事項」を参照してください。

    _msdcs とドメインのDNSゾーンで、メタデータのクリーンアップ後に存在しなくなった DC の NS レコードを削除します。 クリーンアップした DC の SRV レコードが削除されているかどうかを確認します。 DNS SRV レコードの削除を高速化するために、次のように実行します。

    nltest.exe /dsderegdns:server.domain.tld

  10. 使用可能な RID プールの値を 100,000 上げます。 詳細については、「使用可能な RID プールの値の引き上げ」を参照してください。 RID プールを 100,000 引き上げることが特定の状況では不十分であると考える理由がある場合は、環境での RID の平均消費量を考慮に入れて、使用しても安全な最も低い増加を考慮に入れて判断する必要があります。 RID は有限のリソースであり、不必要に使用するべきではありません。

    復元に使用するバックアップの実行後に、ドメインに新しいセキュリティ プリンシパルが作成された場合、これらのセキュリティ プリンシパルは特定のオブジェクトに対するアクセス権を持っている可能性があります。 回復がバックアップに戻されたため、これらのセキュリティ プリンシパルは回復後に存在しなくなりました。ただし、アクセス権はまだ存在している可能性があります。 復元後に使用可能な RID プールが引き上げられない場合、フォレストの回復後に作成された新しいユーザー オブジェクトは、同一のセキュリティ ID (SID) を取得し、本来は意図されていなかったオブジェクトにアクセスできる可能性があります。

    たとえば、新しい従業員がいる可能性があります。 ユーザー オブジェクトは、ドメインの復元に使用されたバックアップの後に作成されたため、復元操作の後にはもう存在していません。 ただし、そのユーザー オブジェクトに割り当てられたアクセス権は、復元操作後も保持される可能性があります。 復元操作後にそのユーザー オブジェクトの SID が新しいオブジェクトに再割り当てされた場合、新しいオブジェクトはそれらのアクセス権を取得します。

  11. 現在の RID プールを無効にします。 システム状態の復元後、現在の RID プールは無効になります。 ただし、システム状態の復元が実行されていない場合は、復元された DC がバックアップの作成時に割り当てられた RID プールから RID を再発行するのを防ぐために、現在の RID プールを無効にする必要があります。 詳細については、「現在の RID プールの無効化」を参照してください。

    注意

    RID プールを無効にした後で、SID を使用してオブジェクトを初めて作成しようとすると、エラーが発生します。 オブジェクトを作成しようとすると、新しい RID プールへの要求がトリガーされます。 新しい RID プールが割り当てられるため、操作の再試行は成功します。

  12. この DC のコンピューター アカウントのパスワードを 2 回リセットします。 詳細については、「ドメイン コントローラーのコンピューター アカウントパスワードのリセット」を参照してください。

  13. krbtgt パスワードを 2 回リセットします。 詳細については、「krbtgt パスワードのリセット」を参照してください。 krbtgt パスワードの履歴は 2 つのパスワードであるため、パスワードを 2 回リセットして、パスワードの履歴から元の (障害前の) パスワードを削除します。

    注意

    フォレストの回復がセキュリティ侵害に対応するものである場合、信頼パスワードをリセットすることもできます。 詳細については、「信頼の一方の側で信頼パスワードをリセットする」を参照してください。

  14. フォレストに複数のドメインがあり、障害が発生する前に復元された DC がグローバル カタログ サーバーであった場合は、NTDS 設定のプロパティの [グローバル カタログ] チェック ボックスをオフにして、DC からグローバル カタログを削除します。 この規則の例外は、ドメインが 1 つだけのフォレストが一般的なケースです。 この場合、グローバル カタログを削除する必要はありません。 詳細については、「グローバル カタログの削除」を参照してください。

    他のドメインの DC を復元するために使用される他のバックアップよりも新しいバックアップからグローバル カタログを復元することにより、残存するオブジェクトが導入される可能性があります。 例を次に示します。 ドメイン A では、時刻 T1 で取得されたバックアップから DC1 が復元されます。 ドメイン B では、時刻 T2 で取得されたグローバル カタログ バックアップから DC2 が復元されます。 T2 が T1 よりも新しい場合、T1 と T2 の間にいくつかのオブジェクトが作成されたとします。 これらの DC が復元された後、グローバル カタログである DC2 は、ドメイン A の部分レプリカに対して、ドメイン A 自身が保持しているデータよりも新しいデータを保持しています。 DC2 はこの場合、これらのオブジェクトが DC1 に存在しないため、残留オブジェクトを保持します。

    残留オブジェクトが存在すると、問題が発生する可能性があります。 たとえば、ユーザー オブジェクトがドメイン間で移動されたユーザーに電子メール メッセージが配信されない可能性があります。 古くなった DC またはグローバル カタログ サーバーをオンラインに戻すと、両方のユーザー オブジェクトのインスタンスがグローバル カタログに表示されます。 両方のオブジェクトが同じ電子メール アドレスを持っています。そのため、電子メール メッセージを配信できません。

    もう一つの問題は、存在しなくなったユーザー アカウントが依然としてグローバル アドレス一覧に表示される可能性があることです。

    さらに、存在しなくなったユニバーサル グループが、ユーザーのアクセス トークンにまだ表示されている可能性があることです。

    グローバル カタログである DC を誤って、または信頼できる唯一のバックアップとして復元した場合は、復元操作の完了後すぐにグローバル カタログを無効にすることで、残留オブジェクトが発生しないようにすることをお勧めします。 グローバル カタログ フラグを無効にすると、コンピューターはすべての部分的なレプリカ (パーティション) を失い、通常の DC の状態に降格します。

  15. gMSA アカウントを使用している場合は、パスワード生成の詳細が攻撃者に公開される可能性があるため、それらを再作成する必要がある場合があります。次を参照してください:
    ゴールデン gMSA 攻撃から回復する方法

    gMSA を置き換え、セキュリティで保護されたキー マテリアルを使用する手順については、「AD フォレストの回復 - マルチドメイン フォレスト 内の単一ドメインの回復」を参照してください。

  16. Windows タイム サービスを構成します。 フォレスト ルート ドメインで、外部タイム ソースから時刻を同期するように PDC エミュレーターを構成します。 詳細については、「PDC エミュレーターでの フォレスト ルート ドメインの Windows タイム サービスの構成」に関する記事を参照してください。

復元した書き込み可能な各ドメイン コントローラーを共通ネットワークに再接続する

この段階では、フォレスト ルート ドメインと残りの各ドメインに 1 つの DC (および回復手順) が復元されている必要があります。 これらの DC を環境の他の部分から分離された共通ネットワークに参加させ、フォレストの正常性とレプリケーションを検証するために次の手順を実行します。

注意

物理 DC を分離されたネットワークに参加させる場合、IP アドレスの変更が必要になることがあります。 このため、DNS レコードの IP アドレスは間違っています。 グローバル カタログ サーバーは使用できないため、セキュリティで保護された DNS の動的更新は失敗します。 この場合、仮想 DC は、IP アドレスを変更せずに新しい仮想ネットワークに参加できるため、より便利です。 これは、フォレストの回復中に復元する最初のドメイン コントローラーとして仮想 DC を推奨する理由の 1 つです。

フォレスト レプリケーションの正常性を確認する

検証後、DC を実稼働ネットワークに参加させ、フォレスト レプリケーションの正常性を確認する手順を完了します。

  • 名前解決を修正するには、DNS 委任レコードを作成し、必要に応じて DNS 転送とルート ヒントを構成します。
  • repadmin /replsum を実行して、DC 間のレプリケーションを確認します。
  • 復元された DC が直接レプリケーション パートナーでない場合、レプリケーションの回復は、それらの間に一時的な接続オブジェクトを作成することによってはるかに高速になります。
  • メタデータのクリーンアップを検証するには、Repadmin /viewlist \* を実行して、フォレスト内のすべての DC のリストを表示します。 Nltest /DCList:***\<domain\>* を実行し、ドメイン内のすべての DC のリストを表示します。
  • DC と DNS の正常性を確認するには、DCDiag /v を実行して、フォレスト内のすべての DC でエラーを報告します。

フォレスト ルート ドメインのドメイン コントローラーにグローバル カタログを追加する

グローバル カタログは、次のような理由で必要です。

  • ユーザーのログオンを有効にする。
  • 各子ドメインの DC で実行されている Net Logon サービスを有効にして、ルート ドメイン内の DNS サーバーのレコードを登録および削除する。

フォレスト ルート DC がグローバル カタログであることが推奨されますが、一般に、すべての DC がグローバル カタログであることを決定することを推奨されます。

Note

DC は、フォレスト内のすべてのディレクトリ パーティションの完全同期を完了するまで、グローバル カタログ サーバーとして提供されません。 そのため、DC は、フォレスト内の復元された各 DC を使用して強制的にレプリケートする必要があります。

イベント ビューアーでディレクトリ サービスのイベント ログを監視して、この DC がグローバル カタログ サーバーであることを示すイベント ID 1119 を確認するか、次のレジストリ キーの値が 1 になっていることを確認します。

**HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Global Catalog
Promotion Complete**

詳細については、「グローバル カタログの追加」を参照してください。

この段階では、安定したフォレストがあり、ドメインごとに 1 つの DC とフォレスト内に 1 つのグローバル カタログが存在している必要があります。 復元した各 DC の新しいバックアップを作成する必要があります。 AD DS をインストールし、追加のグローバル カタログ サーバーを構成することで、フォレスト内の他の DC の再デプロイを開始できるようになりました。

次のステップ