AD (Active Directory) 環境を AWS Backup でバックアップし Authoritative Restore してみよう

!!! 注意 !!!

AWS Backup で Active Directory（以降、AD と表記）環境のバックアップ、リストアを AWS はサポートしません。
AWS は現在、下記 URL で公開している通り、「AD の整合性のあるバックアップを AWS Backup コンソールから直接作成、管理、および復元できる。」としていますが、この内容は誤りで、AD に関しては、バックアップ、リストアはサポートしていない事を、AWS サポートとのやり取りで確認しました。今後、下記ドキュメントは更新されるそうですが、更新予定日は未定とのことです。

https://aws.amazon.com/jp/about-aws/whats-new/2020/09/aws-backup-supports-application-consistent-backups-of-microsoft-workloads-on-ec2/

Windows 環境のアカウント情報や、アクセス制御等の機能を一元管理するサービスを提供する AD。会社の規模が大きくなればなるほど導入を迫られ、また、その規模に比例して重要度が増していくシステムです。

本ブログ執筆時、この AD サービスを提供する Domain Controller サーバ（以降、DC と表記）を、 Windows Server Backup 以外で、楽にバックアップ運用できるサービスがないかと探して辿り着いた AWS Backup 。公開ドキュメントでサポートしていると明記されており、実際リストアも成功したのですが、リストア手順の確認で AWS サポートとやり取りをするなかで、最終的に冒頭の回答を受けました。

従いまして、本ブログの内容は、所謂やってみた系の内容となっております。

ただ、私個人の意見では、バックアップ、リストアはできるんじゃないのかなと思ってます。
その辺りの見解は、まとめに記載します。

なお、本ブログを執筆するにあたり弊社検証環境でテストを実施しておりますが、検証目的の為バックアップ・リストアに関わること以外の AWS のセキュリティや、 OS 設定等の項目は考慮しておりません。

AD 環境を AWS Backup でバックアップし Authoritative Restore してみよう《要件とリストアシナリオ》

DC は、AD システムの性質上、誤ったバックアップファイルでリストアを行うと、AD のデータベースが論理的に破損し、サービスが利用できなくなります。 こちら のサイトが、バックアップの考慮ポイント等を一通り解説しておりますので、ご一読されることをお勧めします。

上記サイトの「正しいバックアップ・リストア」に記載されている通り、 AD 環境のバックアップには、下記 5 通りの方法があります。

・DC 新規追加型のリストア

・Microsoft VSS サービス

・Windows Server バックアップ（2008以降）

・その他 DC 対応のバックアップ・リストア用ソフト

・2012以降の Hyper-V スナップ・ショットの戻し操作。

今回は、AWS Backup で、VSS 連携を行ったバックアップを取得しますので、DC のバックアップ要件を満たせます。

本ブログの内容から少し道がそれた話となりますが、上記サイトでは、Hyper-V スナップショットからのリストアが可能と記載されています。ですが、AWS の基盤となる Xen では VM-GenerationID に対応していません。AWS 環境で、この VM-Generation ID を考慮しないリストアを行うと、USN ロールバックが発生します。この点にご注意ください。

続きまして、リストアシナリオです。

こちら のサイトの、26 ページ 〜 29 ページの通り、AD 環境のリストアには、下記 4 通りのシナリオが想定されます。

① DC（非 FSMO）障害からの復旧

② DC（FSMO）障害からの復旧

③ DC 全台障害からの復旧

④ 特定オブジェクト破損からの復旧

本ブログでは、④のシナリオで、AD のゴミ箱からオブジェクトを復元できない場合や、オブジェクトの論理破損が発生した場合を想定し、戻したいデータを保持するバックアップから、Authoritative Restore する手順を記述します。

AD 環境を AWS Backup でバックアップし Authoritative Restore してみよう《環境概要》

検証環境は下図の通りです。

DC は 2 台構成とし、それぞれを異なる AZ のプライベートサブネットに配置します。
また、NAT ゲートウェイを配置せず、閉じたネットワーク内での運用を想定します。

(図2-1) 検証環境図

両 DC の OS 環境は、下記の通りです。

・OS のバージョンは、Windows Server 2019
・Windows FW を、すべて無効に変更
・タイムゾーンを、UTC + 9:00（札幌、東京、大阪）に変更
・ホスト名を、識別しやすい名称に変更
・ローカル administrator ユーザのパスワードを変更
・他は、デフォルト設定

AD 環境を構築し、ユーザを追加します。

(図2-2、2 - 3) DC #1（左）と、 DC #2（右）のユーザ情報

DC のレプリケーション状態を確認するコマンドを実行し、正常稼働していることを確認します。

(図2-4、2-5)
DC #1 での repadmin /showrepl コマンド（左）と、 repadmin /syncall コマンド（右）の実行結果

(図2-6、2-7)
DC #2 での repadmin /showrepl コマンド（左）と、 repadmin /syncall コマンド（右）の実行結果

ログが長い為画像を添付していませんが、 dcdiag /a コマンドを実行し、エラーが無いことも確認しています。

AD 環境を AWS Backup でバックアップし Authoritative Restore してみよう《バックアップ手順》

3-1. 事前準備

Amazon EC2 上の DC を VSS バックアップする為には、バックアップ対象ノードに AWS が提供する VSS バックアップ用のコンポーネントをインストールする必要があります。

詳細は こちら のサイトをご参照ください。

インストールにあたり、対象ノードが System Manager のフリートマネージャで管理できている状態である必要がありますが、この状態を実現する為には対象ノードを System Manager のエンドポイントに接続させる必要があります。この接続の為の通信は通常インターネットを経由しますが、今回の検証環境は、対象ノードがプライベートサブネットに所属しているので、NAT ゲートウェイか VPC エンドポイントを配置する必要があります。今回は、VPC エンドポイントを利用します。

下記 5 つの VPC エンドポイントを作成します。

ssm 、 ssmmessages 、 ec2 、 ec2messages 、 s3

(図3-1-1 ) エンドポイント画面

続いて、SSM を利用するための IAM ロールを、バックアップ対象の Amazon EC2 に付与します。詳細は こちら のサイトをご参照ください。

なお、VSS スナップショットのための権限も付与する必要があります。
今回はバックアップ・リストア検証を主目的としている為、「Administrator Access」ポリシーを保持したロールを割り当てています。

(図3-1-2) IAM ロール画面

マネージドノード画面に、バックアップ対象のノードが表示されました。

(図3-1-3) マネージドノード画面

それでは、VSS コンポーネントをインストールしてみます。
SystemManager 画面の左カラムから、「Run Command」をクリックします。
画面遷移後、画面右カラムの「コマンドを実行する」をクリックします。

(図3-1-4) Run Command 画面

コマンド実行画面に遷移します。
コマンドドキュメントの検索欄に、「AWS-ConfigureAWSPackage」と入力し、検索を実行します。

(図3-1-5) コマンドドキュメント画面 1

検索結果が表示されます。
表示された「AWS-ConfigureAWSPackage」を選択します。

(図3-1-6) コマンドドキュメント画面 2

コマンドのパラメータの Name 欄に、「AwsVssComponents」と入力します。

(図3-1-7) コマンドのパラメータ画面

ターゲットの「インスタンスを手動で選択する」を選択し、インスタンスに表示されたバックアップ対象ノードを選択します。

(図3-1-8) ターゲット、インスタンス画面

設定が完了したら「実行」をクリックします。画面が、コマンドのステータスに遷移します。
実行結果が、成功であることを確認します。

(図3-1-9) コマンドのステータス画面

対象ノードに、Aws Vss Components コンポーネントがインストールされました。

(図3-1-10) 対象ノードの、C:\Program Files\Amazon フォルダ配下

3−2 バックアップ取得

DC の VSS バックアップを取得してみます。
AWS Backup 画面の左カラムから、「ダッシュボード」をクリックします。

(図3-2-1) AWS Backup 画面

画面遷移後、画面右カラムの「オンデマンドバックアップを作成」をクリックします。

(図3-2-2) ダッシュボード画面

オンデマンドバックアップを作成画面に遷移します。
設定を下記の通りにします。

・リソースタイプ：EC2

・インスタンスID：バックアップ対象ノードの ID

・バックアップウィンドウ：今すぐバックアップを作成

・保持期間：常時

・バックアップボールト：Default

 ・IAM ロール：デフォルトのロール

(図3-2-3) 設定画面

アドバンストバックアップ設定の「Windows VSS」を選択し、「オンデマンドバックアップを作成」をクリックします。

(図3-2-4) アドバンストバックアップ設定画面

バックアップは、実行後 1 時間以内の任意のタイミングで実行されます。
バックアップ実行後、実行結果が「完了」であることを確認します。

(図3-2-5) バックアップジョブ画面

Windows イベントログにも、 VSS バックアップが実行されたログが記録されます。

(図3-2-6、3-2-7) VSS バックアップがキックされたログ(左)と、 VSS バックアップ成功ログ(右)

AD 環境を AWS Backup でバックアップし Authoritative Restore してみよう《Authoritative Restore 手順》

Authoritative Restore は手順が少し複雑なので、簡単な流れを記載します。

① VSS バックアップで取得した AMI のボリュームスナップショットから、ボリュームを作成。

② 作成したボリュームを、復元対象の Amazon EC2 とは別の Amazon EC2 (tmp) にアタッチ。

③ Amazon EC2 (tmp) にアタッチしたボリュームに、ディレクトリサービス復元モード（以降、 DSRMと表記）で OS 起動するフラグを立てる。

④ Amazon EC2 (tmp)で DSRM 起動フラグを立てたボリュームを、復元対象の Amazon EC2 のルートボリュームとボリュームスワップ。

⑤ DSRM で起動した復元対象の Amazon EC2 で、Authoritative Restore を実行。

⑥ 動作確認。

それでは、Amazon EC2 上の DC を、Authoritative Restore してみます。
今回の検証では、FSMO を持つ DC#1 をリストアしますが、FSMO を持たない DC#2 でも実施する手順は同じです。

まずは、リストアシナリオに沿う為に、ユーザを削除します。
DC#1 で削除したユーザが、DC#2 にも反映されました。

(図4-1、4-2) DC#1（左）と、 DC#2（右）のユーザ情報

① AMI のスナップショットからボリュームを作成します。

スナップショット画面から、リストア対象のスナップショットを選択しボリュームを作成します。ボリューム設定のパラメータはデフォルトです。

(図4-3) スナップショット画面

②リストアしたボリュームを、Amazon EC2 (tmp)にアタッチします。

ここで 1 点、注意するポイントがあります。
Amazon EC2 (tmp)の OS バージョンは、復元対象の Amazon EC2 の OS バージョンと異なる必要があります。
今回の環境では、復元対象の Amazon EC2 の OS バージョンは Windows Server 2019 ですので、 Amazon EC2 (tmp)の OS バージョンを WindowsServer2016 にしました。

詳細については、 こちら の、「DSRM でオフラインインスタンスを起動するには」をご参照ください。

ボリュームの画面からリストアしたボリュームを選択し、「ボリュームのアタッチ」をクリックします。

(図4-4) ボリューム画面

ボリュームのアタッチ画面に遷移します。
デバイス名に、「xvdf」と入力し、「ボリュームのアタッチ」をクリックします。

(図4-5) ボリュームのアタッチ画面

③アタッチしたボリュームに、DSRM で起動するフラグを立てます。

Amazon EC2 (tmp)に RDT で接続し、ディスクの管理画面を起動します。
アタッチしたボリュームが、ディスク1として認識されています。

(図4-6) ディスクの管理画面 1

ディスク 1 をオンラインにし、OS に認識させます。

(図4-7) ディスクの管理画面 2

コマンドプロンプトを起動し、下記コマンドを実行します。

bcdedit /store D:\Boot\BCD /set {default} safeboot dsrepair

(図4-8) コマンドプロンプト画面 1

「この操作を正しく終了しました。」と表示されることを確認します。

(図4-9) コマンドプロンプト画面 2

ディスクの管理画面に戻り、ディスク 1 をオフラインにします。

(図4-10) ディスクの管理画面 3

④ DSRM で起動するフラグを立てたボリュームを復元対象の Amazon EC2 のルートボリュームにアタッチします。

ボリュームの画面から、DSRM で起動するフラグを立てたボリュームを Amazon EC2 (tmp)からデタッチします。

(図4-11) ボリューム画面 1

起動中の、復元対象の Amazon EC2 を停止します。

(図4-12) インスタンス画面 1

復元対象の Amazon EC2 のルートボリュームを、デタッチします。

(図4-13) ボリューム画面 2

DSRM で起動するフラグを立てたボリュームを、復元対象の Amazon EC2 にルートボリュームとしてアタッチします。

(図4-14) ボリューム画面 3

ボリュームのアタッチ画面に遷移します。
デバイス名に、「/dev/sda1」と入力し、「ボリュームのアタッチ」をクリックします。

(図4-15) ボリュームのアタッチ画面

⑤ Authoritative Restore を実行します。

復元対象の Amazon EC2 を起動させます。

(図4-16) インスタンス画面 2

しばらくすると、RDT で接続できるようになります。
アカウントは「ホスト名\administrator」と入力します。ホスト名を明記しないと、NLA のエラーが出ます。
ログインが完了すると、予期せぬシャットダウン画面が表示されますが仕様動作なので、無視してください。

(図4-17、4-18) ログイン情報入力画面（左）と、予期せぬシャットダウン通知画面（右）

DSRM で起動した OS に、ローカルユーザでログインできました。

(図4-19) DC#1 DSRM デスクトップ画面

Powershell を管理者権限で起動し、下記コマンドを実行します。

『ntdsutil』

(図4-20) Powershell 画面 1

プロンプトが、「ntdsutil.exe:」に変わることを確認し、下記コマンドを実行します。

『activate instance ntds』

(図4-21) Powershell 画面 2

「アクティブインスタンスが ”ntds” に設定されました。」と表示されることを確認し下記コマンドを実行します。

『authoritative restore』

(図4-22) Powershell 画面 3

プロンプトが、「authoritative restore:」に変わることを確認します。

(図4-23) Powershell 画面 4

下記コマンドを実行します。

『list nc crs』

表示された全てのパーティション情報の、「パーティション：」以降を控えます。
この環境では、1) 〜 5) が、パーティション情報です。

(図4-24) Powershell 画面 5

下記コマンドを実行します。

『restore subtree <パーティション> 』

(図4-25) Powershell 画面 6

Authoritative Restore の確認ダイアログ画面が表示されます。
「はい」をクリックします。

(図4-26) Authoritative Restore の確認ダイアログ画面

「Authoritative Restore が正常に終了しました。」と表示されることを確認します。

(図4-27) Powershell 画面 7

残りのパーティションも同様に Authoritative Restore し、すべてのパーティションの Authoritative Restore を、正常に完了させます。

(図4-28) Powershell 画面 8

下記コマンドを実行し、ntdsuti.exe プロンプトから抜けます。

『quit』

(図4-29) Powershell 画面 9

下記コマンドを実行します。

『msconfig』

(図4-30) Powershell 画面 10

システム構成画面が起動します。
「ブート」タブ内の、「セーフブート」のチェックを外します。

(図4-31) システム構成画面 1

「 OK 」をクリックします。

(図4-32) システム構成画面

OS 再起動通知画面が表示されるので、再起動を実施します。

(図4-33) 再起動通知画面

⑥ 動作確認を行い、削除したユーザが復元されていること、正常に AD 環境に復帰できたことを確認します。

しばらくすると、RDT で接続できるようになります。
ドメインユーザでログインします。

(図4-34) ログイン情報入力画面

削除したユーザが復元されており、その情報が DC#2 に反映されました。

(図4-35、4-36) DC#1（左）と、DC#2（右）のユーザ情報

DC のレプリケーション状態を確認するコマンドを実行し、正常稼働していることを確認します。

(図4-37、4-38)

 DC#1 での repadmin /showrepl コマンド（左）と、repadmin /syncall コマンド（右）の実行結果

(図4-39、4-40)

DC#2 での repadmin /showrepl コマンド（左）と、repadmin /syncall コマンド（右）の実行結果

ログが長い為、画像を添付していませんが、dcdiag /a コマンドを実行し、エラーが無いことも確認しています。
また、FSMO の移行が可能であること、DC#1 で新規ユーザを作成し、DC#2 に反映されることも確認できました。

AD 環境を AWS Backup でバックアップし Authoritative Restore してみよう《まとめ》

いかがでしたでしょうか。検証中は何度も躓きましたが、手順を確立してしまえば思いのほかあっさりとできてしまったなぁ。というのが率直な感想です。これで AWS がサポートしていれば言うことなしですね。

それでは、バックアップ、リストアはできるのではないかという点について、私見を述べていきます。

まず、なぜ AWS Backup は、AD 環境のバックアップ、リストアをサポートしないのか、についてですが、Xen では VM-GenerationID をサポートしていない、という点が根拠でした。

次に、ではどうすれば正しいバックアップ、リストアができるのかですが、そちらについては こちら の「安全な復元の詳細なプロセス」を参照ください。

※ バックアップについては 1 . 《要件とリストアシナリオ》参照

VM - Generation ID とは、仮想マシン作成時、仮想基盤から仮想マシンに割り当てられる一意の値です。この VM - Generation ID を、仮想サーバが DC に昇格する際、自身のデータベース（NTDS.DIT）に格納します。

この状態で、DC サーバを AWS Backup でバックアップし、そのバックアップから、仮想マシンごとリストアします。すると、仮想マシンは新規に作成されることになるので、その仮想マシンに対し、新たな VM - Generation ID が割り当てられます。OS 起動後、DC が自身のデータベース に格納された VM - Generation ID と、仮想マシンの VM - Generation ID を突合して値が異なることを検知します。この際、 VM - Generation ID をサポートしていない環境では、サポートしている環境で色々自動でうまくやってくれることを行えず、正しいリストアができないと解釈しました。フローチャートにもあるように、 VM - Generation ID が存在し、その値が変更されていない場合は、通常起動する仕様です。であれば、仮想マシンを変更せず、アタッチされたディスクのみリストアをすれば、正しく戻るのではないかというのが見解です。

また、Windows Server Backup でのバックアップ、リストアでは正常にリストアできるという AWS サポートの見解があり、Windows Server Backup からのリストアと、AWS Backup からのディスクのみのリストアも、やっている内容は基本的に一緒だというのも、正常にリストアできるだろうという根拠の一つです。

認識が間違ってるのでは？といったご意見がございましたら、ぜひお問い合わせください。

それでは、お読みくださりありがとうございました。