こんにちは、クラウドインテグレーション2部 技術1課 宮形 です。
Windows Server 限定のテーマになりますが、Actice Directory ドメイン参加したメンバーサーバー(以下 "AD参加した” と略) の EC2 を、AMI としてオンラインバックアップする運用において、復元時に AD参加した状態が維持されるのか調査しました。ネットを調べても意外と情報がなかったので本BLOGにてご紹介します。
前提条件
ご自分でセットアップして運用する EC2 から、Amazon マシンイメージ (AMI) を作成することができます。主な目的としては下記いずれかだと思います。
- サーバーのシステムイメージバックアップとして利用
- サーバーの複製を行うために利用
今回は 1. の利用目的についてとなりますが、1. と 2. の違いを意識する必要があります。
Windows には各OS毎にセキュリティID (SID) という固有の識別子をもっています。このSIDはいろいろな所で利用されていて、Active Directory でも利用されています。このSIDですが、各コンピューター毎に一意である必要があります。
パソコン大量セットアップでHDDクローンツールを使った事がある方だとご存知だと思いますが、 このSIDは重複しないよう注意する必要があります。すでにAD参加したコンピュータの場合、いったんWORKGROUPに戻してからsysprepコマンドでSIDリセットしたりします。
逆の見方をすると、AD参加したコンピューターをバックアップから復元して元通りに利用する場合は、このSIDは元の値を維持する必要があります。つまり下記のようになります。
- サーバーのシステムイメージバックアップとして利用 (=SIDは一致させる)
- サーバーの複製を行うために利用 (=SIDは重複しないようにする)
SIDが重複しても条件がそろえば運用可能という情報もあったりますが ここでは「別のOSとする場合はSID重複はNG」という立場とします。
マシン SID の重複神話 https://technet.microsoft.com/ja-jp/windows/mark_12.aspx
前提が長くなってしまいましたが、つまり「AD参加したままでオンライン取得した EC2 AMI から EC2 を再作成(≒復旧) したときに、AD参加の状態が維持できるのか？！」が疑問であり、調べても明確な情報がなかったので検証することにしました。また、付随するWindows関係の考慮事項にもふれております。
検証した結果
結論としては、AD参加したままオンライン取得した EC2 AMI からEC2 を再作成しても、AD参加の状態は維持可能でした。
AMI 取得前の状態確認、AMI 取得
EC2上でADドメイン名を解決するため、DNSサーバーの参照先はOS上から手動変更しています。
AMI取得前の SID 値を控えておきます。whoami コマンドでローカルAdministratorのSIDを控えます。
whoami /user
nltest コマンドで、正しくAD参加ができていることを確認します。
nltest /sc_verify:ドメイン名
EC2コンソールより対象EC2を選択し、「アクション」-「イメージとテンプレート」-「イメージを作成」を押下します。
「イメージを作成」の画面となります。「イメージ名」「イメージの説明」に任意値を設定します。「再起動しない」はオンラインバックアップの想定なので「有効」とします。画面下部へスクロールして「イメージを作成」を押下します。しばらくすると AMI の取得が完了します。
AMI からの EC2 再作成
EC2 の障害を想定して、今ほど取得した AMI から EC2 を再作成(≒復旧) します。今回は元々あった EC2 はインスタンス終了して削除しております。EC2 を残した状態で実施すると、SID重複が発生して元々の EC2 が AD へ認証が出来なくなるなどトラブルになる可能性があります。本番環境の EC2 では実施しないようご注意ください。
EC2コンソールより「AMI」の画面へ移動します。一覧に表示される今ほど取得したEC2を選択し、「アクション」-「AMIからインスタンスを起動」を選択します。
「インスタンスを起動」の画面となります。「名前」に任意値を設定します。「キーペア(ログイン)」では。「キーペアなしで続行 (推奨されません)」とします。後述しますが Windows Server の EC2 においてはここでキーペアを設定しても意味をなしませんでした。「ネットワーク設定」は環境に合わせて適切に設定します。最後に「インスタンスを起動」を押下します。
インスタンスの起動により EC2 再作成が行われ、リモートデスクトップでサインインが行えることを確認します。 この時のローカルAdministratorユーザーのパスワードはAMI取得前と同じ値です。
復旧した EC2 の Windows OS の状態
オンライン取得したAMIから復旧した Windows 系のEC2では、初回ログイン時に「シャットダウン イベント追跡ツール」が表示されます。 これは AMI をオンラインで取得したため、サーバーが正常にシャットダウンされていないと判断されるためです。適当な理由を入力して「OK」で応答します。
Windows OS はAD参加した状態が維持されているようです。
whoami コマンドで確認するローカルAdministratorユーザーのSIDは一致しており、nltest コマンド結果も正常です。 正常なAD参加の状態と判断できそうです。
この後下記の確認もしましたが、いずれも正常動作しておりました。
- グループポリシー適用
- ADユーザーでのサーバーへのサインイン
- ファイルサーバーへのシングルサインオン
EC2 キーペアの取り扱い
「AMIからインスタンスを起動」で任意キーペアを指定したり、新たに作成したりできます。残念ながら、オンライン取得したカスタムAMIの Windows Server においては、意味をなさないようです。
AMI より復旧したEC2のパスワードをEC2コンソールから取得しようとしますが、下記のように「パスワードは使用できません」となります。時間を待ってもこの画面のままです。
EC2コンソールでパスワードを取得するための条件として、EC2 Launch (EC2 Config) から Administrator Password: Random にした状態で Sysprep を実施する必要があります。今回はこの条件に達していないため、パスワード取得が行うことができなくなっています。
DNSサーバー参照の設定
OS上から手動変更していたDNSサーバーの参照先は設定踏襲されています。ここは、環境に応じて DHCPオプションセットや、Route 53 Resolver 等の活用も有効かと思います。弊社先輩のBLOGもご参照ください。
まとめ
今回の検証で、オンラインバックアップ目的として取得した AMI から Windows Server を復旧した場合、AD参加の状態が維持されることがわかりました。私の検証ではAWSマネージメントコンソールから手動でAMIを取得しましたが、弊社提供の Cloud Automator を使えば自動的にスケジュールでAMIを取得することができます。運用の自動化としてぜひご検討ください。
今回BLOGで触れませんでしたが、「2. サーバーの複製を行うために利用」においては逆にSIDリセットが必要です。 EC2のSIDリセットは EC2 Launch (EC2 Config) から行う必要があります。通常の sysprep.exe コマンドからは実行してはいけませんのでご注意ください。
本BLOGの内容が、皆様の課題解決の参考になれば幸いです。
