こんにちは、クラウドインテグレーション2部 技術1課 宮形 です。
AWS へオンプレミス環境を移行する際、Microsoft Active Directory サーバー (以下ADサーバー)をどのようにするか毎度検討にあがります。
「EC2 にADサーバーインストールして移行する」が間違いありませんが、せっかくクラウドにするのであれば運用コスト削減できる「マネージドサービス」としたいところです。そこで候補にあがるのが「AWS Managed Microsoft AD」(以下 Managed MSAD)です。
本BLOGでは、Managed MSAD への移行について調査した内容をご紹介いたします。
移行方法
Managed MSAD は、従来 ADサーバー と高い互換性があり ほぼ同等機能 を利用することができますが、残念ながら利用できない機能もあります。その一つが「セルフマネージドADサーバーとのレプリケーション」です。従来のADサーバーと Managed MSAD をレプリケーションして利用することはできません。また、Managed MSAD を利用する場合、新しいドメインを新規作成して構築する必要があります。
これについてADサーバーにお詳しい方だと「レプリケーションせずにADサーバーの過去資産をどのように移行するのか？」という疑問にあたります。この回答として、AWS公式ドキュメントには下記のように記載があります。
Active Directory から AWS Managed Microsoft AD へユーザーを移行する - AWS Directory Service
セルフマネージド AD から AWS Managed Microsoft AD ディレクトリへのユーザーの移行には、Active Directory 移行ツールキット (ADMT) とパスワードエクスポートサービス (PES) を使用します。これにより、ユーザーの AD オブジェクトと暗号化パスワードを簡単に移行できます。
私自身 Active Directory 移行ツールキット (以下 ADMT) とパスワードエクスポートサービス (以下 PES) は使った経験がありませんでした。自分なりに調べまして、ADMT と PES を用いて移行できるもの、できないものを列記してみました。
| ADMTで移行できる | ADMTでは移行できない |
|---|---|
| - ユーザーアカウント(PES併用で パスワード 含む) - コンピュータ - セキュリティグループ |
- 連絡先 - プリンター - 共有フォルダー - OUのディレクトリ構造 - グループポリシーオブジェクト - サイト構成 - スキーマ拡張した情報 - ADSIで手動登録、編集したオブジェクト - 同居するDNSサーバーの設定、ゾーン、レコード |
弊社ラボで実際に試す機会があったので、その記録をご紹介します。
構成
検証時は下記図のように、同一VPC・サブネット上に 移行先の Managed MSAD と 移行元ADサーバー(EC2) を配置しました。実際の環境は移行元ADサーバーがAWS以外のオンプレミスにある場合が多いと思われます。
利用した EC2 のOSは下記の通りです。
移行元ドメイン (miyagata.local)
- 移行元ADサーバー：Windows Server 2016
- ファイルサーバー：Windows Server 2016
- メンバーPC(想定)：Windows Server 2016
移行先ドメイン (miyagata2.aws)
- ADMT実行用EC2(兼 ManagedMSAD 管理用サーバー)：Windows Server 2016
ADMT と PES は Microsoft が提供しますが、下記注意書きの通り Windows Server 2016以降での利用はサポートが無く自己責任となります点、ご注意ください。
ADMT と PES のサポート情報 - Windows Server | Microsoft Docs
Windows Server 2012、Windows Server 2012 R2 以降のバージョンの Windows Server は、最新のアプリケーションとプロファイルの移行についてテストされていません。
セットアップ手順
AWS セキュリティブログ でADMTとPESを用いた移行方法が紹介されていますので、こちらを元に実施します。
下記の手順についてはすでに完了している状態として、本BLOGでの説明は省略します。AWS BlackBelt にわかりやすい資料があるのでご参照ください。
- ADMT実行用EC2(兼 Managed MSAD 管理用サーバー) へ AD・DNS・グループポリシー管理ツールのインストール
- 移行元ADサーバーと、移行先 Managed MSAD との双方向フォレスト信頼関係の構築
参考：AWS Black Belt Online Seminar - AWS Managed Microsoft AD
移行元ドメインでの管理者権限の取得
移行元ADサーバーの「Active Directory ユーザーとコンピューター」を開き、Builtin 配下の Administrators グループに、移行先ADサーバーの管理者ユーザーを追加します。私は最初に作られる admin ユーザーを追加しました。
AWS セキュリティブログでは図解の赤矢印が source.local の Administrator になっており間違いだと思われます。また「Domain Admins」には参加できませんのでご注意ください。
ADMT実行用EC2 への SQL Server Express のインストール
ADMT は SQL Server を必要とします。最新の SQL Server 2019 版 Express (無償利用可) で試しましたが問題なく利用できました。インストーラーは下記から入手します。
Download Microsoft® SQL Server® 2019 Express from Official Microsoft Download Center
「基本」を選択して、あとの選択肢はすべてデフォルトでインストールします。最後に「SSMSインストールしますか？」を聞かれますが、SSMS は使わなくても ADMT は利用可能なので「閉じる」としました。
ADMT実行用EC2 への ADMT インストール
AWSセキュリティブログで紹介されているインストーラー入手先URLは変わってしまっていたようで、私は下記からダウンロードしました。
Download Active Directory 移行ツール バージョン 3.2 from Official Microsoft Download Center
途中 SQL Server の接続名を聞かれるのですが、下記のようなエラーが出ました。
「データベース」を localhost\SQLEXPRESS としていた為でした。.\SQLEXPRESS とすることで成功しました。この注意はAWSセキュリティブログに記載されていました。
ADMT実行用EC2 での暗号化キーの生成
ADMT実行用EC2 の管理者コマンドプロンプトで下記のように実行します。sourcedomain と keypassword は適宜変更します。
admt key /option:create /sourcedomain:miyagata.local /keyfile:c:\ /keypassword:password123
指定したディレクトリ(例では c:\ 配下)に .pes ファイルが作られます。このファイルを、移行元ADサーバーへコピーしておきます。
移行元ADサーバー での PES のインストール
ここの手順は、移行元ADサーバー で実施します。途中ADサーバーのOS再起動が必要なので、システムが停止できるタイミングで実施します。
PES は下記からダウンロードしました。
Download Password Export Server version 3.1 (x64) from Official Microsoft Download Center
「Encryption file」の画面では、先ほど ADMT実行用EC2 で生成した暗号化キーファイルを選択します。
コマンド実行時に指定したパスワード(本例は password123) を入力します。
サービスの実行アカウントを問われる「Run the Service at:」が表示されます。「Local System Account」としました。
インストールが終わると再起動するよう通知されます。システムが停止できることを確認し、「Yes」をクリックしてOSを再起動します。
OS再起動後に「管理ツール」-「サービス」の一覧より「Password Export Server Service」が追加されていることを確認します。
「スタートアップの種類：手動開始」なので、「自動」に変えておきます。「開始」ボタンを押下します。
移行先 Managed MSAD でのOUの準備
移行先 Managed MSAD の管理は、ADMT実行用EC2 のデスクトップより行います。 「管理ツール」-「Active Directory ユーザーとコンピューター」を開始します。移行元ADよりユーザーアカウントおよびコンピューターを移行する先の組織(OU)を事前に作っておきます。移行元ADでOUを大量に作っていた場合は、大変な作業になるかもしれません。
ここまでセットアップを進めると、移行作業を開始する準備が整います。
移行手順
ユーザーアカウント と コンピューター を移行する手順をご紹介します。
ユーザーアカウントの移行
ADMT実行用EC2 に「管理ツール」-「Active Directory 移行ツール」が追加されていますので、実行します。 「Active Directory 移行ツール」を選択し、右クリックメニューより「ユーザー アカウントの移行ウィザード」を選択します。
ウィザードを開始すると「ドメインの選択」が表示されます。移行元ドメインとADサーバー、移行先ドメインとADサーバーを選択します。移行先は Managed MSAD になりますが、ドメインコントローラーが2台候補に出きます。どちらを選んでも問題ありません。
「ユーザーの選択オプション」では「ユーザーをドメインから選択」とします。
「ユーザーの選択」では、移行を行うユーザーアカウントを選択して追加します。
「移行先の OU の識別名を入力します」では、事前セットアップで用意した 移行先 Managed MSAD の OU を選択します。
「パスワードオプション」では、「パスワードの移行」を選択します。「既存のユーザーのパスワードを更新しない」のチェックをオンにすると、移行先ドメインでの初回ログイン時のパスワード変更要求を省略できる筈なのですが、私が検証した場合はうまく有効になりませんでした。移行後にシステム管理者側でパスワード変更要求を手動オフにすることもできますが、他の解決策があれば本BLOG更新させていただきます。
この後いろいろオプション選択を求められますが、今回はすべてデフォルトとしました。 「ユーザー SID を移行先ドメインへ移行」については、sIDHistory といって移行先ドメインでも移行元の時のSIDを利用することが出来る機能です。残念ながら AWSセキュリティブログによると、Managed MSAD では利用サポートされていないとありました。
ウィザードの最後の画面で「完了」を押下すると、移行が開始されます。結果が画面に表示されます。
「Active Directory ユーザーとコンピューター」の画面を確認します。無事ユーザーアカウントが移行先OUに格納されています。
「ユーザーは次回ログオン時にパスワード変更が必要」のチェックが入ります。同じパスワードを継続利用する場合は、オフに変更しておきます。
同様手順で「グループアカウントの移行ウィザード」でセキュリティグループを移行することもできました。
コンピューターの移行
コンピューターの移行を行うと、移行元ドメインのメンバーコンピューターを移行先ドメインへ自動再参加させることができます。 私が確認した点として、下記の条件があります。
- 移行命令時にメンバーのコンピューターが起動している必要がある
- ADMT実行コンピューターよりメンバーコンピューターに対して、管理者共有 ADMIN$ でアクセスできる必要がある
- メンバーコンピューターの Windows ファイアウォールで SMBアクセスを許可している必要がある
条件 2. 3. が環境によっては達成が難しいと思われます。ADMTの実行ユーザーは移行先ADのドメイン管理者ユーザー(本例では admin) になりますが、移行元ADの Domain Admins セキュリティグループに参加できません。メンバーのコンピューター各々のローカル Administrators グループへ参加させる設定が必要です。グループポリシーの「制限されたグループ」を活用するなど工夫が必要です。Windows ファイアウォールもデフォルトではSMBは拒否なので、変更する必要があります。
これら条件が達成したことを確認して、ウィザードを開始します。
「Active Directory 移行ツール」を選択し、右クリックメニューより「コンピューター アカウントの移行ウィザード」を選択します。
手順はユーザーアカウント移行とほとんど同じです。「コンピューターの選択」では、移行するコンピューターを選択します。
「移行先の OU の識別名を入力します」では、事前セットアップで用意した 移行先 Managed MSAD の OU を選択します。
この後いろいろオプション選択を求められますが、今回はすべてデフォルトとしました。
ウィザードの最後の画面で「完了」を押下すると、移行が開始されます。結果が画面に表示されます。 この時点では、メンバーコンピューターはまだ移行元ドメインに参加した状態です。
この直後に「Active Directory 移行ツールのエージェント ダイアログ」が表示されます。
「エージェントの動作：事前確認を実行する」を選択して「開始」すると、メンバーのコンピューターが前提条件を達しているか確認できます。
前提条件がパスすると「事前確認：合格」となります。「事前確認とエージェントの操作を実行する」を選択し、「開始」を押下します。
しばらくすると「エージェントの操作：成功」となります。メンバーコンピューターで自動的に移行先ドメインへの参加と再起動が行われます。その後、「事後確認：合格」となります。
メンバーコンピューターで確認すると、移行先ADに参加していることがわかります。念のため nltest /sc_query で検証しましたが問題無さそうです。
動作確認
ファイルサーバー と メンバーPC のコンピューターを Managed MSAD へ移行し、移行したユーザーアカウントでサインインしてファイルサーバーの共有フォルダへアクセスしてみますが、残念ながらエラーです。 厳密には異なるユーザーアカウントでありSIDが違うため、アクセス許可が無いと判断されます。sIDHistory を設定すれば解決しそうですが、Managed MASD ではサポートされていません。システム管理者でアクセス許可を付けなおししましょう。
まとめ
AWSセキュリティブログに記載の方法で無事、移行元ADサーバー より Managed MSAD へ移行を行うことができました。ただし、ADMT は制限事項が多い点は注意が必要です。また、コンピューターのFQDNや SID も変わってしまうので、この影響調査は十分行う必要がありそうです。 本番環境で利用する場合は、他にも懸念点やリスクが出てくると想像します。
個人的には、グループポリシーが移行できない点が気になります。Microsoft 公式サイトの方法でグループポリシーを移行先ドメインへコピーする方法もありますので、次回BLOGで Managed MSAD で使えるか検証しております。ご興味あれば御覧ください。
本BLOGが皆様のクラウド移行の参考になれば幸いです。
