はじめに
皆様お疲れ様です。
今回はオンプレミス環境からAWS環境に、ADサーバーを移行していきたいと思います。
AWSにAD移行となれば、主に「AWS Managed Microsoft AD」と「Active Directory Server on EC2」の2つがあると思います。
下記にメリット・デメリット、コストの比較を記載します。
| AWS Managed Microsoft AD | Active Directory Server on EC2 | |
|---|---|---|
| メリット | ・管理の簡素化: AWSが管理・運用を担当するため、管理の負担が軽減される。 ・セキュリティの向上: AWSのセキュリティベストプラクティスに準拠し、セキュリティ機能が強化されている。 ・スケーラビリティ: ユーザー数やリソースの増減に柔軟に対応できる。 |
・柔軟性: ユーザーが自由に設定やカスタマイズを行えるため、柔軟性が高い。 ・制御: ユーザーが独自に管理・運用できるため、制御が容易。 ・低コスト: EC2インスタンスを使用するため、従量課金制であり、必要なときにリソースを削減できる。 |
| デメリット | ・柔軟性の制限: AWSが管理するため、カスタマイズや制御が限られる場合がある。 ・コスト: マネージドサービスとして提供されるため、料金がかかる場合がある。 |
・管理の負担: ユーザーが自ら管理・運用するため、管理の負担が大きい場合がある。 ・高可用性の実現: 高可用性を確保するためには、ユーザーが手動で冗長構成を実装する必要がある。 ・セキュリティ: セキュリティ機能の実装や管理が、AWS Managed Microsoft ADに比べてユーザーが負担する必要がある。 |
| コスト （月/単一のVPCでの運用/東京リージョンの場合） |
[Standard Edition]ディレクトリオブジェクト最大30,000の場合（ユーザー数最大5000人） ドメインコントローラー1つにつき0.073USD/1時間 デフォルトでドメインコントローラーが2つ作成されるので0.146USD/1時間 24時間×30日=720時間 0.146×720=月105.12USD [Enterprise Edition]ディレクトリオブジェクト最大500,000の場合 |
ユーザー数などのオブジェクトの数で変動するためAWS Managed Microsoft ADのStandard Editionに合わせて5000人のユーザーがいると仮定し下記の要件とする。 （条件によりハードウェア要件は変動し価格も変わってくるということをご承知おきください。） CPU-8 メモリ-16 インスタンスタイプ-c6i.2xlarge EBS-100GB,gp3 [オンデマンド] |
Active Directoryハードウェア要件に関して下記サイトを参考にしました。
「AWS料金見積もりツール」
「Windows Serverのハードウェア要件」
「Active Directory Domain Services のキャパシティ プランニング」
「Windows Serverのサイジング」
今回はAWS Managed Microsoft ADへの移行とActive Directory Server on EC2への移行を行い、ブログを作成いたしました。
AWS Managed Microsoft ADへの移行では信頼関係を構築しオンプレADドメインの参照ができるようにし、移行ツールを使用してユーザーやコンピューターなどのオブジェクトの移行します。
Active Directory Server on EC2への移行ではドメインを完全に移行します。on EC2をドメインコントローラーに昇格させて、FSMOの移行を行い完全にプライマリサーバーにします。
Active Directory Server on EC2への移行のブログもありますので参考にしてみてください。
「Active Directory Server on EC2への移行」
AWS Managed Microsoft ADはドメインを完全に変更せずに移行するのには向かないです。
移行をする際は要件にあった適切なサービスを選択してください。
要件・構成図・目次
今回の要件・構成図は下記になります。
AWS Managed Microsoft ADは高可用性のため作成時にマルチAZ構成になります。
最初にAWS Managed Microsoft ADを構築します。構築後に信頼関係をオンプレミスADサーバーとAWS Managed Microsoft ADで結ぶためです。
また前提としてAWS Managed Microsoft ADでは「Administrator」権限ではなくそれよりも弱い管理者「Admin」権限が与えられます。
管理用EC2はなぜ必要かというと、AWS Managed Microsoft ADの中に直接入ることができないため「Admin」ユーザーで管理用EC2に入りAWS Managed Microsoft ADを管理するためです。
また今回はオンプレミスのソースドメイン「CPI.Local」とAWS Managed Microsoft ADの新規ドメイン「AWS.CPI.Local」を使用します。
要件
- オンプレミス環境は既存の環境。
- Site to SiteVPN接続は構築済み。
- AWS環境も既存の環境を使用。
- 移行先のADは「AWS Managed Microsoft AD」を使用する。
- オンプレミスのドメインを移行先で変更してはならない。
（今回はAWS Managed Microsoft ADへの移行では参照できれば良い）
構成図
今回の構成図はこちらになります。
目次
AWS Managed Microsoft ADの構築
AWS Managed Microsoft ADの前提として
・AZが別のサブネットが2つ必要
・「Administrator」の管理者権限は与えられず、代わりに「Admin」権限が与えられます。
・Managedサービスなので直接中に入って操作ができない。
それではさっそく構築していきたいと思います。
構築手順
まずDirectoryServiceのコンソール画面に行き、「ディレクトリのセットアップ」を押下します。
ディレクトリタイプで「AWS Managed Microsoft AD」を選択し次へ。
エディションは「Standard Edition」、ディレクトリ名は任意の名前、各オプションは明けて作成いたします。Adminパスワードは任意確認欄にも入力して次へ。
VPCは今回のAWS環境のVPCを選択、サブネットも作成した2つを選択し次へ。
確認画面で間違いなければ、「ディレクトリの作成」を押下し完了です。
管理用EC2の作成
上記の前提で書いたように、AWS Managed Microsoft ADの中に入ることができないので管理用のEC2を立てて中に入りたいと思います。
その前にDNS解決ができるように、「DHCPオプションセット」を作成していきます。
「DHCPオプションセット」を作成後、EC2にアタッチするIAMロール・セキュリティグループの作成してEC2を起動します。
EC2起動後にもIAMロール・セキュリティグループはアタッチすることができるのですが、起動とまとめてできるので先に作成します。
DHCPオプションセット
VPCコンソール画面に行き、左ペインから「DHCP オプションセット」→「DHCP オプションセットを作成」を押下。
オプションセット名を任意、ドメイン名をAWS Managed Microsoft ADで作成したドメイン名に、ドメインネームサーバーにAWS Managed Microsoft ADサーバーのIPアドレスで「DHCP オプションセットを作成」を押下で作成完了。
左ペインから「お使いのVPC」→作成したVPCを選択→「アクション」→「VPCの設定を編集」→「DHCP設定」で先ほど作成したオプションセットを選択し保存を押下。
＊VPCの設定を編集画面に「DNS設定」項目があるのですが、「DNS 解決を有効化」「DNS ホスト名を有効化」にチェックが入っていなければチェックを入れておいてください。
管理用EC2の作成
作成したAWS Managed Microsoft ADのコンソールから作成する方法もあるのですが、今回はEC2のコンソールから作成していきます。
AWS Managed Microsoft ADのコンソール画面から作成する際は、「アクション」→「ディレクトリ管理EC2インスタンスの起動」から行います。
IAMロールの作成
まずIAMロールの作成を行います。
IAMコンソール画面に行き、左ペインから「ロール」→「ロールを作成」を押下。
信頼されたエンティティタイプで「AWSのサービス」を選択、ユースケースで「EC2」を選択し次へ。
許可ポリシーで、「AmazonSSM ManagedInstanceCore」と「AmazonSSM DirectoryServiceAccess」を選択し次へ。
ロール名を決めそのほかはデフォルトのまま「ロールを作成」を押下し完了。
セキュリティグループの作成
管理用EC2にアタッチするセキュリティグループを作成していきます。
EC2もしくはVPCのコンソール画面左ペインから「セキュリティグループ」→「セキュリティグループを作成」を押下。
セキュリティグループ名を任意、説明も任意（今回はセキュリティグループ名と同じものを入力します）、VPCは作成したものを選択し、ルールを追加します。
インバウンドルールはこちら
| プロトコル | ポート | ロール |
|---|---|---|
| TCP/UDP | 53 | DNS |
| TCP/UDP | 88 | Kerberos |
| TCP/UDP | 389 | LDAP |
| TCP/UDP | 464 | Kerberosパスワードの変更/設定 |
| TCP | 135 | レプリケーション |
| TCP | 445 | SMB/CIFS |
| TCP | 636 | LDAP SSL |
| TCP | 3268-3269 | LDAP GCおよびLDAP GC SSL |
| TCP | 3389 | リモートデスクトップ |
| TCP | 49152-65535 | RPC |
| 全て | 全て | LocalVPC内 |
アウトバンドルールはこちら
| プロトコル | ポート | ロール |
|---|---|---|
| 全て | 全て | 全てのトラフィック |
ルールの設定が完了しましたら「セキュリティグループの作成」を押下して完了。
管理用EC2の作成
下準備が整いましたので、Ec2のコンソールから「インスタンス」→「インスタンスを起動」を押下。
インスタンス名を任意で、AMIでクイックスタートの「Windows」、AMIを「Microsoft Windows Server 2019 Base」（GUIがあるため）を選択。
インスタンスタイプを「t3.small」にします。（t2.microだと正常に動作しなかったので、正常に動作させるためにt3.small以上を選んだほうが良いです。）
キーペアは既存もしくは新規作成した自身所有のもの。
ネットワーク設定で、VPC・サブネットを移行先環境のもの、パブリックIPの自動割り当てを有効化。
セキュリティグループは「既存のセキュリティグループを選択するで」先ほど作成したものを選択。
高度な詳細を開いて、ドメイン結合ディレクトリで先ほど作成したAWS Managed Microsoft ADのドメインを選択、IAMインスタンスプロフィールにも先ほど作成したIAMロールを選択する。
間違いがないか確認して「インスタンスを起動」を押下、EC2の作成は完了。
EC2のセットアップ
EC2の作成は完了したので次はセットアップに入ります。
今回はSite to SiteVPN接続しているのでプライベートIPアドレスでRDP接続できるのですが、接続方法はほかにもあり、SSM接続などがあります。こちらも要件に合わせて選択してください。
EC2のセットアップ
今回はSSMを使用してRDP接続します。
＊英語表記かと思うので、不便な方は設定から日本語表記をダウンロードして表記を変えてください。
EC2インスタンス内に入れたら、虫眼鏡アイコンを押下し「servermanager」と入力し押下します。
ダッシュボードの「役割と機能の追加」を押下。
「サーバーの選択」まで次へを押下し、EC2を選択し次へ。
「機能」まで次へを押下し、
・「グループポリシー設定」
・「リモートサーバー管理ツール」→「役割管理ツール」→「AD DSおよびAD LDSツール」
・「DNSサーバーツール」
にチェックを入れ、確認ウィンドウまで次へを押下。
確認画面で間違いがなければ「インストール」を押下して完了。
EC2ログイン確認
「Administrator」でログインしている場合はログアウトしてサインインしなおします。
ログアウトして、再度リモートデスクトップを開きEC2のIPアドレスと「Admin@XX.XX（ドメイン名）」を入力。
パスワードを求められたら、AD作成の際に作成したパスワードを入力してログイン。
うまくログインできれば完了です。
ADサーバーの移行・信頼関係の構築
オンプレミスのADサーバーとAWS Managed Microsoft ADで信頼関係を構築します。
ユーザーなどのオブジェクトの移行やAWS環境からの参照を行えるようにしたいと思います。
こちらのドキュメントを参考にしました。
今回の移行作業で1番トラブルが起きたのがここです。
なかなか信頼関係が構築できませんでした。もし同じようにここでひっかかるようでしたら、ネットワークの確認と信頼関係の内容、DNSを見直してみてください。
ルートテーブルにも優先順位があるのでPingコマンドで疎通確認取れるがエラーが出たりします。
オンプレミスの信頼関係設定
オンプレミスの信頼関係の設定を行います。
オンプレミスのファイアウォール設定
オンプレミスのファイアウォールに下記の許可を追加します。
| プロトコル | ポート | ロール |
|---|---|---|
| TCP/UDP | 53 | DNS |
| TCP/UDP | 88 | Kerberos認証 |
| TCP/UDP | 389 | LDAP |
| TCP | 445 | SMB |
| TCP | 2049 | NFS |
Kerberos事前認証を有効化
デフォルトで有効になっているが、確認をする。
オンプレミスのサーバーマネジャーから、「ツール」→「Active Directoryユーザーとコンピューター」を押下。
「Users」を押下し、右ペインの任意のユーザーを右クリックし「プロパティ」を押下。
「アカウント」タブを開き、「Account options」の「Kerberos事前認証を必要としない」にチェックが入っていないことを確認する。
DNS条件付きフォワーダーの構成
サーバーマネジャーから「ツール」→「DNS」を押下。
「条件付きフォワーダー」を右クリックし、「新規条件付きフォワーダー」を押下。
「DNSドメイン」にAWS Managed Microsoft ADのドメインを入力し、「マスターサーバーのIPアドレス」にAWS Managed Microsoft ADのIPアドレス2つを入力する。
「このActive Directory」に条件付きフォワーダーを保存し…」にチェックを入れ、「このドメインのすべてのDNSサーバー」を選択し、OKを押下。
（検証項目などでエラーが出るが無視してよい）
オンプレミスの信頼関係構築
サーバーマネジャーから「ツール」→「Active Directory ドメインと信頼関係」を押下。
ドメインを右クリックし、「プロパティ」を押下。
信頼タブで、「新しい信頼」を押下。
新しい信頼ウィザードの開始を次へ、
信頼の名前にAWS Managed Microsoft ADのドメイン名、
信頼の種類で「フォレストの信頼」を選択、
信頼の方向を「双方向」を選択、
認証で「フォレスト全体の認証」を選択、
任意の信頼パスワードを入力。AWS Managed Microsoft AD側で信頼関係を構築する際に使用するのでメモを取る。
最後まで次へを押下し完了。
AWS Managed Microsoft ADの信頼関係構築
AWS Managed Microsoft ADの信頼関係の設定を行います。
セキュリティグループの設定
AWS Managed Microsoft ADのセキュリティグループに以下のインバウンドルールを追加する。
| プロトコル | ポート | ロール |
|---|---|---|
| TCP/UDP | 53 | DNS |
| TCP/UDP | 88 | Kerberos認証 |
| TCP/UDP | 389 | LDAP |
| TCP/UDP | 49152-65535 | RPC用の一時ポート |
| TCP | 135 | RPC |
| TCP | 636 | LDAPS |
| TCP | 2049 | NFS |
| TCP | 3268-3269 | グローバルカタログ |
| UDP | 123 | NTP |
Kerberos事前認証を有効化
オンプレミスと同様、デフォルトで有効になっているが確認をする。
AWS Managed Microsoft AD管理用EC2のサーバーマネジャーから、「ツール」→「Active Directoryユーザーとコンピューター」を押下。
「Users」を押下し、右ペインの任意のユーザーを右クリックし「プロパティ」を押下。
「アカウント」タブを開き、「Account options」の「Kerberos事前認証を必要としない」にチェックが入っていないことを確認する。
信頼関係の構築
AWSのDirectory Serviceコンソールから、「ディレクトリ」→AWS Managed Microsoft ADのIDを押下。
ディレクトリの詳細の「ネットワークとセキュリティ」の「信頼関係」から、「アクション」→「信頼関係の追加」を押下。
信頼関係情報で「フォレストの信頼」、
既存または新しいリモートドメインにオンプレミスのドメイン、
信頼パスワードをオンプレミスの信頼関係作成時にメモを取ったものを入力、
信頼の方向を「双方向」、
条件付きフォワーダーにオンプレミスのIPアドレスを入力し「追加」を押下。
信頼関係のステータスが「検証済み」になれば完了。
移行ツールのインストール
AWS Managed Microsoft ADの管理用EC2に、移行ツールをインストールしていきます。
Microsoft SQL Express 2019をインストール
リンクからMicrosoft SQL Express 2019を管理用EC2にインストールします。
ADMTをインストール
下記のリンクからADMTバージョン3.2を管理用EC2にインストールします。
ADMTのセットアップ
ADMTのインストーラ―を実行しセットアップを行います。
Database SelectionウィンドウのDatabaseに「.\SQLEXPRESS」を入力し次へ、
DatabaseImportウィンドウで「No,do not…」を選択し次へ、
そのほかはデフォルトのままインストールを完了させます。
パスワード移行キーの作成・コピー
PES（パスワードエクスポートサーバー）を使用して、暗号化処理しパスワードを同期します。
管理用EC2で管理者権限のコマンドプロンプトを開き、
admt key /option:create /sourcedomain:ドメイン名 /keyfile:ドライブ指定 /keypassword:任意のパスワード
こちらのコマンドで暗号化キーを作成します。
例）
admt key /option:create /sourcedomain:source.local /keyfile:c:\ /keypassword:password123
作成したキーをオンプレミスにコピーします。
リンクからオンプレミスのドメインコントローラーにPESをインストールします。
インストーラーが走ったら、「ADMTパスワード移行DLLセットアップ」ウィンドウでコピーした暗号化キーファイルを参照する。
プロンプトが表示されたら、ADMT暗号化で使用するパスワードを入力する。
再起動が入った後、虫眼鏡アイコンから「services.msc」を検索しPassword Export server serviceを開始する。
オブジェクトの移行
移行ツールがインストールできたので移行をしてみます。
ユーザーとパスワードの移行
サーバーマネジャーの「ツール」→「Active Directory Migration Tool」を押下。
「Active Directory Migration Tool」を右クリックして、移行オプションを表示する。
「User Account Migration Wizard」を押下して次へ、
ソースドメインにオンプレミス、ターゲットドメインにAWS Managed Microsoft ADのドメイン名を入力し次へ。
移行先のOUを選択し次へ、
パスワードオプションウィンドウでパスワードの移行を選択し次へ、
アカウント移行ウィンドウでユーザーオブジェクトの移行処理方法を選択（Target same as sourceを選択した）し次へ、
Users Optionsウィザードで「Update user rights」「Migrate associated user groups」「Fix users’group memberships」を選択し次へ、
Conflict Managementウィザードで「Do notmigrate…」を選択し次へを押下すると移行が開始されます。
コンピューターの移行
ユーザーオブジェクトの移行と同様に、サーバーマネジャーの「ツール」→「Active Directory Migration Tool」を押下。
「Active Directory Migration Tool」を右クリックして、移行オプションを表示する。
「Computer Migration Wizard」を押下して、ソースドメインにオンプレミス、ターゲットドメインにAWS Managed Microsoft ADのドメイン名が入っていることを確認して次へ。
移行するコンピューターを選択し次へ、
Translate Objectsウィザードで移行中のアクセス制御のオプションを選択し完了。
移行検証
移行の検証で「mochizuki」というユーザーを作成して上記の「User Account Migration Wizard」からユーザーオブジェクトを移行してみる。
ターゲットドメインにAWS Managed Microsoft ADのドメイン、ユーザー「mochizuki」の指定を行い、移行を実行。
完了後にAWS Managed Microsoft ADの管理用EC2から確認すると無事移行できていました。
無事ログインもできました。
AWSサポートへの問い合わせ
AWSサポートに
①「AWS Managed Microsoft ADに移行する際に、ドメイン名を変更せずに移行できるか」
②「ActiveDirectoryサーバー on EC2に仮想環境のドメイン名と違うドメイン名で構築する。そこに仮想環境からオブジェクト全てを移行する。AWSManagedMicrosoftADをオンプレミスのドメイン名を使用して新規作成して、ActiveDirectoryサーバー on EC2からオブジェクトを移行する。のような方法ではできるか」
との問い合わせをしたら以下の回答が返ってきた。
AWSサポートからの回答
①オンプレミスのActive Directoryドメインメインを変更せずにAWS Managed Microsoft ADに移行する方法は確認できていないとのこと
②ドメイン名を変更せずに移行が行える可能性が考えられるが、オブジェクトのSIDが異なったものとなるのでシステムの挙動がおかしくなる可能性がある。とのこと
まとめ
今回はAWS Managed Microsoft ADへの移行を行いました。
構築やセットアップ自体は特別難しくはないですが、サービスとサービスが絡み合ってくるので確認作業が大事になってきます。間違えて構築してしまうと作成し直しもあるので、余計にコストがかかってしまいますからね。
また、信頼関係の構築ができない場合はDNSサーバーーの見直しをしてみてください。
おわり！！
参考
AWSドキュメント
「How to migrate your on-premises domain to AWS Managed Microsoft AD using ADMT」
Serverworksブログ
「オンプレミスADサーバーから AWS Managed Microsoft AD への移行 (ユーザーとコンピューター編)」