はじめに
Azureにおけるバックアップ・リストアでは、Azure Backupを利用することが多いかと思います。Azure Backupを利用することで、仮想マシンを停止せずにバックアップを取得することが可能です。
一般的なワークロードでは、公式ドキュメントの手順に従うことで、簡単にリストアすることができます。ですが、Active Directory（以降AD）のリストアについてはどうでしょう。Azure VM ドメインコントローラーの復元については、下記の通り記載があります。
単一ドメイン内の 1 つのドメイン コントローラー VM または複数のドメイン コントローラー VM を復元する場合は、他の VM と同じように復元します。 ディレクトリ サービス復元モード (DSRM) も利用できるので、Active Directory の復元シナリオはすべて実行可能です。
私はこれを読んで、具体的にどういう手順でリストアできるかのイメージがまったくわきませんでした。。。
Windows Server バックアップを利用したバックアップ・リストアについては多くの記事で解説されていますが、Azure Backupを用いた手順に関してはほとんど見かけません。
本記事では自身の備忘録もかねて、Microsoft社のサポートに確認をしながら検証した内容をまとめます。
環境によって、リストアの手順が変わる場合があります。本記事はあくまで参考として確認いただき、実際にADのリストアを行う際は、必ず検証環境で入念な確認を行ってください。
ADのバックアップに関する前提知識
本題に入る前に、ADのバックアップ・リストアにおいて、最低限知っておきたい知識について記載します。
権限のある復元と権限のない復元
ADのリストアには「権限のある復元」と「権限のない復元」の2種類があります。
-
権限のある復元 (Authoritative Restore)：
権限のある復元は、対象のドメインコントローラーが持つデータを「最新情報」として、他のドメインコントローラーに複製します。ADのデータをバックアップ時点に戻すために使用されます。権限のある復元を行うためには、ドメインコントローラーをリストアした後にntdsutilコマンドを使った明示的な設定が必要です。（設定を行わないと、既存ADの方が最新のデータを持っているため上書きされてしまいます） -
権限のない復元 (Non-Authoritative Restore)：
権限のない復元は、他のドメインコントローラーが持つ情報（既存ADの情報）を複製します。環境に正常なドメインコントローラーが存在する場合、基本的にはこのリストア方法を選択します。
ドメインコントローラーには、「ADデータベース」と「SYSVOL」という二つのデータ領域が存在し、それぞれ別の仕組みで同期されています。各データ領域で権限のある復元を実行することができます。
なお、ドメインコントローラーを全台リストアするようなケースでは、最初にリストアしたドメインコントローラーで「SYSVOL」の権限のある復元を行います。
※「ADデータベース」の権限のある復元は不要
USNロールバック
ドメインコントローラーでは、ユーザーやグループ、コンピューター等のオブジェクトがADデータベースに保存されています。データベースの情報はドメインコントローラー間で複製されるため、全てのドメインコントローラー間で同様の情報を保持しています。
ドメインコントローラーでデータの更新を行うと、内部でUSN（Update Sequence Number：更新シーケンス番号）という値が更新されます。USNは、変更履歴を管理するための内部的な識別子です。USNを見ることで、ドメインコントローラー間でどこまで情報が複製されたかを判断しています。
また、バックアップに関わる内部データとして、Invocation IDという値があります。Invocation IDはADデータベースに割り当てられたIDです。
スナップショットからのリストアや、サポートされていないツールによるバックアップを行った場合、Invocation IDが更新されていな状態で、USNが巻き戻ってしまいます。この状態になると、ドメインコントローラー間で正常にデータの複製が行われなくなります。これをUSNロールバックと呼びます。
逆に、ADのリストアをサポートしているツールでバックアップを行うと、Invocation IDが更新されます。上図で言えば、リストアしたドメインコントローラーのInvocation IDがA→Bになります。これにより、リストア後も正常なドメインコントローラー間の複製が維持されます。
VM-Generation ID
VM-Generation IDは、仮想環境で利用される識別子です。仮想マシンが作成される際、ハイパーバイザーによってVM-Generation IDが割り当てられます。このIDはADのデータベースに保存され、VMの起動時にデータベースに保存されたIDと、現在割り当てられているIDを比較します。
VM-Generation IDが異なる場合、仮想化セーフガードがトリガーされます。仮想化セーフガードがトリガーされると、Invocation IDがリセットされます。これによって、スナップショットからリストアした場合でも、USNロールバックを防ぐことができます。
仮想化セーフガードの仕組みは、公式ドキュメントの図が分かりやすいです。
Azure VMは、VM-Generation IDに対応しています。
Azure Backupによるリストアシナリオ
Azure Backupによるリストアシナリオは、下記の通りです。
※DC=ドメインコントローラー
| シナリオ | リストア概要 | 考慮事項 |
|---|---|---|
| ①一部のDCで障害 | A.障害が発生しているDCのディスクを復元 B.障害が発生しているVMを削除し、新しいVMを作成 |
Bの手順の場合、旧VMで利用していたIPアドレスやNSGの設定を、新しいVMに設定し直す必要がある |
| ②すべてのDCで障害 | 1台目のDCをリストアし、SYSVOLの権限のある復元を実行。その後、2台目以降をリストア。 | バックアップ取得後に発生したオブジェクトの変更情報は失われる |
| ③オブジェクト誤削除等の理由により、バックアップ時点に復元 | リストアしたDCで権限のある復元を実行 | 事前にリストアするDC以外のDCで、FW(NSG)にてリストアするDCとの通信をブロックする必要がある |
ごみ箱機能を有効にしている環境では、③のシナリオによるリストアよりも、ごみ箱からの復元の方が簡単です
Azure Backupで復元したVMについては、いくつか注意点があります。バックアップ・リストアの計画時は、必ず公式ドキュメントを確認してください。
リストア手順
環境前提
本記事の前提は、以下の通りです
- Azure VM上で動作するドメインコントローラー×2台
- OSは、Windows Server 2022
- OSディスクのみ
- フォレスト・ドメイン機能レベルは、Windows Server 2016
- Azure Backupで日次バックアップを取得
※ADのディスクは分けることが推奨されていますが、私の担当した案件はコストの観点からOSディスクのみを利用しており、本記事ではこの前提で進めます
①-A. 一部のDCで障害（ディスクを復元）
一部のDCに障害が発生した場合は、ディスクを復元し交換することでリストアが可能です。普通のAzure VMを復元する場合と同様の手順となります。復元ポイントを選んで、ディスクを復元します。
リストア対象のAD（仮想マシン）を停止し、「OSディスクのスワップ」からディスクを交換します。ディスク交換後、元々関連付けられていたディスクの削除を忘れず実施しましょう。
Azure VMでADを運用する場合、ポータルからのシャットダウンは非推奨です。ですが、本リストアシナリオではポータルからでも問題ありません。
- Active DirectoryリポジトリのVM-GenerationIDとInvocation IDがリセットされる
⇒VM-GenerationIDとInvocation IDはスナップショットからのリストアしたことを検出する値のため、リストアシナリオでは問題なし - 現在のActive Directory相対識別子(RID)プールが破棄される
⇒ADのリストア時は、バックアップ時点で保有していたRIDプールは破棄し、新しいRIDプールを取得するため問題なし - sysvolフォルダーが権限なしとしてマークされる
⇒リストアにより、他の正常なADからsysvol情報を初期複製するため問題なし
①-B. 一部のDCで障害（新しいVMを作成）
新しいVMを作成しリストアする場合は、最初に障害が発生したVMを削除します。その後、新しいVMをリストアし、IPアドレスやNSGの設定を行います。
VMを削除した後、新しいVMをリストアします。
新しいVMをリストアするとVMが起動されるため、OS内部からシャットダウンします。
その後、IPアドレスをリストア前の値に設定し、Azure Portalから再度VMを起動します。
VMが起動したら、OSにログインし参照先のDNSを設定します。（VMとして復元した場合、優先DNS、代替DNSの設定がリセットされます）
新しいVMから復元するパターンとしては、障害が発生したVMがそもそも使えない場合や、異なるVNETに復元したい場合などが考えられます。単に過去の状態に戻したい場合は、ディスクの復元によるリストアを推奨します。
②すべてのDCで障害
本シナリオの手順は、以下の通りです。
- 1台目のDCをリストア
- 1台目のDCのIPアドレスを設定（OS内部からシャットダウン）
- 1台目のDCで、Authoritative Restore（SYSVOL）を実行
- 2台目のDCをリストア
- 2台目のDCのIPアドレスを設定（OS内部からシャットダウン）
※台数に応じて、4～5を繰り返す
手順1、2では、①-Bと同じ操作で1台目のDCをリストアします。その後、リストアしたDCでSYSVOLのAuthoritative Restoreを実行します（手順3）。手順4、5では再度①-Bと同じ操作でDCをリストアします。
※手順1、2の段階では、優先DNSだけを設定しておき、最後に代替DNSを設定します。
以降に手順3のAuthoritative Restore（SYSVOL）を実行する方法を記載します。
手順1、2でリストアしたDCのログインした後、[Active Directory ユーザーとコンピューター]を起動します。[Win＋R]>[dsa.msc]から起動できます。
起動した後、[表示]メニューから下記を有効にします。
- コンテナーとしてのユーザー、連絡先、グループ、コンピューター
- 拡張機能
左ペインのツリーを [Active Directory ユーザーとコンピューター] - [<ドメイン名>] - [Domain Controllers] - [<リストアを実施したドメイン コントローラー>] - [DFSR-LocalSettings] - [Domain System Volume] の順に展開します。
右ペインの [SYSVOL Subscriptions] を右クリックし、[プロパティ] を起動します。
[属性エディター] タブの [属性] 列が [msDFSR-Options] となっている行をダブルクリックします。
[値] に1と入力し、[OK]をクリックします。その後も[OK]をクリックします。
[Active Directory ユーザーとコンピューター]を閉じた後、管理者としてコマンドプロンプトを起動し、DFS Replicationサービスを再起動します。
net stop dfsr && net start dfsr
ここまで作業が完了したら、①-Bと同じ操作でDCをリストアします。
③オブジェクト誤削除等の理由により、バックアップ時点に復元
本シナリオの手順は、以下の通りです。
- 事前にリストアするDC以外のVMのNSGにて、リストアするDCとの通信をブロックする
- Azure VM バックアップにて、VMをリストアする
- リストア後に DSRMで起動するよう設定し再起動する
- ntdsutil コマンドで削除したオブジェクトのバージョン番号を上げる (Authoritative Restore)
- 1 で設定したブロックを解除して、通常モードで起動する
- 削除されたオブジェクトが復旧したことを確認する
最初に、リストアするDCからの通信を遮断するため、それ以外のVMのNSGでリストアするDCとの通信をブロックします。通信をブロックしておくことで、リストアしたドメインコントローラーがすぐに既存のドメインコントローラーからデータを複製してしまうことを防ぎます。
その後、①の手順にてVMをリストアします。リストア後、DSRMで起動します。
DSRMで起動するためには、[Win＋R]>[msconfig]を実行します。
[ブート] タブの [セーフ ブート] をオンにし、
[Active Directory 修復] を選択し、[OK] をクリックします。
ポップアップが表示されるので、[再起動] をクリックします。
OSが起動したら、ディレクトリサービス復元モードの Administrator でサインインします（ADインストール時に指定したパスワードが必要）。サインインが完了したら、コマンドプロンプトを起動します。
コマンドプロンプトに、下記の順で入力しEnterを押します。
① ntdsutil
② activate instance ntds
③ authoritative restore
④ list nc crs ※存在するパーティション一覧を表示
⑤ restore subtree <権限のある復元を実施したいパーティションの DN>
例) restore subtree DC=azure,DC=lab
"この Authoritative Restore を実行しますか?" と表示されたら、[はい] クリックします。
その他にも権限のある復元を実施したいパーティションがある場合には、④、⑤を実行します。その後、qと入力してEnterを押すことを2回繰り返し、ntdsutilを終了します。
ntdsutilを終了したら、[Win＋R]>[msconfig]を実行します。
[ブート] タブの [セーフ ブート] をオフにし、[OK] をクリックします。
ポップアップが表示されるので、[再起動] をクリックします。
ここまでの作業が完了したら、最初に設定したNSGのブロックを解除します。その後、削除されたオブジェクトが復旧していることを確認します。
DSRMで起動した際に、NLAが有効になっているとRDPによる接続ができない場合があるようです。私はAzure Bastionで問題なく接続できましたが、もしDSRMで起動した後に接続できない場合はNLAの無効化を試してみてください。Azureポータルの対象のVMリソースを開き、[操作] >[実行コマンド] >[DisableNLA]からNLAを無効化できます。実行後は、AzureポータルからVMを再起動することで設定を反映します。
ADの正常性確認
ADの正常性を確認する方法はいくつかありますが、最低限下記の観点で動作確認しておくことを推奨します。確認はドメイン内に存在する全てのドメインコントローラーで実施します。
ADデータベースの複製確認
「Active Directory ユーザーとコンピューター」で実際にユーザーを作成し、オブジェクトが複製されることを確認します。
SYSVOLの複製確認
SYSVOLのPoliciesフォルダでテスト用のテキストファイルを作成し、他ドメインコントローラーで複製されることを確認します。
以下は、デフォルトのパスです。（ADインストール時の設定により異なる場合があります）
C:\Windows\SYSVOL\domain\Policies
AD複製コマンドの確認
コマンドプロンプトから、下記のコマンドを実行します。実行結果にエラーが含まれないことを確認します。リストア直後に実行すると一部エラーが出力される場合がありますが、正常に復元できている場合は1時間程度で成功になります。
repadmin /showrepl
イベントログの確認
リストア作業の完了以降で、システム、ディレクトリサービス、DNSサーバー、DFS Replicationのイベントログを確認し、エラーが出力されていないことを確認します。
リストア作業中は一時的にドメインコントローラー間の疎通ができない等の理由で、いくつかエラーが記録されます。そのため、リストア作業の完了以降でエラーがでていないことを確認することが重要です。
最後に
Active Directoryのバックアップ・リストアは考慮すべきポイントが多く大変でした。本記事が、少しでも皆様のお役に立てば幸いです。