ハイブリッド環境向けに複数リージョンを跨ったAWS Managed Microsoft Active Directoryを設計する

これまで、大規模かつ複雑な構成のMicrosoft Active Directoryを複数の地域に跨って展開しているお客様は、オンプレミスのActive DirectoryをAWSに移行する際に様々な課題に直面してきました。AWS Managed Microsoft Active Directoryとの連携も、容易ではありませんでした。

昨年リリースされたAWS Managed Microsoft Active Directoryの「マルチリージョンレプリケーション」機能を利用すれば、このようなグローバル展開の作業を簡略化し、移行プロジェクトにおける難題を軽減することができます。このマルチリージョン機能を活用し、AWS Managed Microsoft Active Directoryを利用したハイブリッドActive Directoryをどのように設計・構築すれば良いかという質問を多くのお客様から受けています。

この記事では、複数のリージョンにまたがるAWS Managed Microsoft Active Directoryの設計と名前解決（DNS）のアーキテクチャーについて説明していきます。このアーキテクチャーを活用すれば、新しいAWSサービスがAWS Managed Microsoft Active Directoryに参加した際に既存ドメインのユーザー認証を利用し、それらのサービスにアクセスすることができます。

実施手順

以下のアーキテクチャー図（図1）は地理的に離れた2つのデータセンターを示しており、各データセンターにはMicrosoft Active Directoryのドメインコントローラーが存在します。同じフォレスト名を共有していますが、それぞれ異なる子ドメインを持っています。

それぞれのデータセンターはAWS Direct Connectを通じてAWSと通信しており、各AWSリージョン上のAWS Transit Gatewayに接続されています。Transit Gateway間のピアリングが確立されているため、AWS Virtual Private Cloud（VPC）間の相互接続も可能となっています。

この構成は複雑なピアリング関係を必要としないため、ネットワーク構成をシンプルにできます。もし各リージョンにVPCが1つしかない場合は、Transit Gatewayの代わりにコスト効率の高いVPCピアリングを利用しても良いでしょう。

各VPCは2つのアベイラビリティーゾーン（AZ）に分かれており、各AZには1つのパブリックサブネットと2つのプライベートサブネットがあります。パブリックサブネットにはNATゲートウェイが作成され、各データセンターのドメインコントローラーはプライベートサブネット内に作成されたドメインコントローラーに同期を行っています。AWS Managed Microsoft Active Directoryもこのプライベートサブネット内に導入され、既存ドメインのドメインコントローラーと信頼関係により接続されます。そして2つ目のプライベートサブネットにはAmazon Elastic Compute Cloud（EC2）インスタンスが配置されています。

ドメイン名の観点から見ると、フォレスト名はcustomer.comとなっており、配下の子ドメインとしてsg.customer.comとeu.customer.comが存在します。

この場合、両方のリージョンでルートドメインコントローラーを運用すると同時に、各リージョンで自分の子ドメイン用のドメインコントローラーをそれぞれ運用することをお勧めします。AWS Managed Active Directoryの設定が完了したら、ルートドメインへの片方向の信頼関係を確立します。「推移的な信頼関係」を作成するので、各子ドメインも自動的にAWS Managed Microsoft Active Directoryに信頼されます。よって、子ドメインのユーザーの認証情報を利用してAWSリソースにアクセスすることもできます。

図1 – Transit Gatewayを通じて接続されたマルチリージョンアーキテクチャーを示すアーキテクチャー図

接続性

EC2インスタンスやAWS Managed Microsoft Active Directoryを作成する前に、先に2つのAWSリージョン間の基本的な相互接続を確立します。

• 最初に、各リージョンに1つずつ、計2つのAWS Transit Gatewayを作成します。
• 次に、それぞれのVPCをTransit Gatewayにアタッチします。
• 次に、Transit GatewayとVPCの間のルートを追加します。
• 最後に、2つのTransit Gatewayのピアリングを行います。

前述のとおり、各リージョンにVPCが1つしかない場合はVPCピアリングを利用することも検討してください。両方のVPCのサブネットからのネットワークトラフィックをルーティングするには、図2に示すようにルートテーブルを設定します。

図2 – AWSリージョン間の接続を確立するために使用するルートテーブルとTransit Gatewayピアリングを示すネットワークアーキテクチャー

AWS Managed Microsoft Active Directoryを複数のリージョンに展開する

まず、新しいEnterprise Editionのディレクトリを作成する必要があります。すでにEnterprise Editionのディレクトリを利用している場合は、そこでマルチリージョン機能を有効化することもできます。

マルチリージョンレプリケーションをサポートするのはEnterprise Editionのみである点にはご留意ください。今回は、aws.localという新しいディレクトリを作成するとします。「.local」を使用するのは、インターネットドメインと区別するためです。新しいディレクトリを作成する際には、AWS Managed Microsoft Active Directoryで使用するFQDN（Fully Qualified Domain Name）とNetBIOS名が、オンプレミスのドメインと同一ではないことを確認してください。

ここではeu-west-1リージョンにディレクトリを作成するため、ここがプライマリリージョンとなります。プライマリリージョンのドメインコントローラーが稼働可能な状態になったら、「マルチリージョンレプリケーション」セクションで他のリージョンを追加することができます。

図3 – AWS Managed Microsoft Active Directoryが導入されているAWSリージョンの一覧

図4 – AWS Managed Microsoft Active Directoryの一覧の中でマルチリージョン機能が有効になっているものを見分ける方法

サイトリンク

サイトリンクは2つ以上のActive Directoryサイトをつなぐために利用され、サイト間の推移性を実現します。サイトリンクに属する一方のサイトと、それ以外のサイトとの間のレプリケーションコストを計算するためにはKCC（Knowledge Consistency Checker）が用いられます。

レプリケーションのフローを制御するために、図5に示すようにAWS上のActive Directoryサイトとオンプレミスの間のサイトリンクを作成しました。レプリケーションのフローの最適化のために、on-prem-sgとeu-west-1サイト間には直接のレプリケーションは行われません。Managed Active Directoryのサイトリンクはディレクトリ作成時に追加されるため、手動で設定する必要はありません。ただし、最も近い既存Active Directoryのサイト名でサイトを更新しておくことをお勧めします。

そうすれば、クライアント側が既存ドメインのDCを検索する際に、AWS Managed Microsoft Active Directoryの中で該当のドメインと一致するサイトのDCを常に見つけることができるようになります。図5は、今回の環境でのActive Directoryサイトとサイトリンクの構成を論理的に示しています。

図5 – 既存Active Directory上のサイトとサイトリンク、及びAWS Managed Microsoft Active Directoryの独立したサイトリンク

既存ドメインのeu-siteとsg-site両方をActive Directory Site and Servicesコンソール上で確認できました。

図6 – 各リージョンのActive Directoryドメインコントローラーが表示されているActive Directory Sites and Servicesコンソール

DNS設計

ハイブリッド構成でのActive Directoryの展開において、DNSは非常に重要な役割を果たします。フォレスト間信頼関係を確立する前に、名前解決が正しく機能していることを確認する必要があります。

オンプレミスのネットワークからのDNSリクエストをAWS Managed Microsoft Active Directoryに転送するために、既存のドメインに典型的な条件付きフォワーダーを設定します。

図7 – aws.localドメインの条件付きフォワーダーが設定されたDNS Managerコンソール

Resolve-DnsNameコマンドを実行することによってDNS解決を検証できます。稼働中の4つのAWS Managed Microsoft Active Directoryドメインコントローラーインスタンスへの正常な名前解決を確認できました。

図8 – PowerShellでAWS Managed Microsoft Active Directoryのaws.localドメインに対するDNSクエリを実行する

一方、AWS上では条件付きフォワーダーとAmazon Route53を両方活用します。AWS Managed Microsoft Active Directoryで条件付きフォワーダーを設定します。これは、既存のフォレストと新しいAWS Managed Microsoft Active Directoryのフォレストの間でフォレストの信頼を確立するために必要です。これについては、信頼関係のセクションで詳細に説明します。

最初に、既存ドメインに対するDNSクエリに自動的に答えるためのRoute 53 Resolverを作成します。そのResolverのアウトバウンドエンドポイントを通じて、新しく作成されたEC2インスタンスがDNSクエリを送信できるようにするためです。

customer.com、sg.customer.com、eu.customer.com等の一部クエリのみを転送させるには、Resolverのルールを作成し既存のDNSサーバーのIPアドレスにクエリを送れるように設定します。

Resolverのルールに明記されていないその他ドメイン名については、Resolverはパブリックネームサーバに対して再帰的問い合わせを行います。図9は、EC2インスタンスから発信されたDNSクエリの処理の流れを示しています。

図9 – プライベートサブネットにあるEC2インスタンスからの、Amazon Route 53 ResolverのアウトバウンドElastic Network Interfacesを経由したDNS解決の様子。このDNSクエリはEC2上で稼働する既存ドメインのドメインコントローラーに対して送信される

図10に示される2つのIPアドレスはアウトバウンドElastic Network Interface（ENI）のアドレスです。customer.comドメインに対するクエリは既存のDNSサーバーに転送されるようルールを作成しています。

図10 – 2つのElastic Network InterfaceのIPアドレスと条件付きフォワードルールが設定されたアウトバウンドエンドポイントの管理画面

これで、PowerShellを利用し既存のドメイン名をDNS サーバーが解決できるか確認できます。

図11 – customer.comドメインに対するPowerShellでのDNSクエリの実行

信頼関係

DNS解決の検証が済んだら、次にAWS Managed Microsoft Active Directoryから既存のルートドメイン（customer.local）に対する片方向のフォレスト信頼関係を確立することができます。図12は、既存のフォレストとAWS Managed Microsoft Active Directoryの間にどんな信頼関係が存在しているかを表しています。

AWS Managed Microsoft Active Directory（aws.local）から既存のルートドメイン（customer.com）に対するフォレスト信頼関係を確立すると、sg.customer.comやeu.customer.comの認証情報を使用してaws.localドメインのリソースにアクセスできるようになります。それらの子ドメインがルートドメインに対して推移的信頼関係を持っているためです。

図12 – customer.comのルートドメインはsg.customer.comとeu.customer.comそれぞれの子ドメインに対して親子の信頼関係を持つ。同時に、ルートドメインはAWS Managed Microsoft Active Directoryのaws.localドメインからの片方向のフォレスト信頼関係を持つ

AWS Managed Microsoft Active Directoryからの信頼関係は、今回の構成でプライマリリージョンとなっているeu-west-1から作成することができます。それ以外のリージョンでは信頼関係を作成するオプションが無効となっており、設定は「プライマリリージョンから継承される」旨のメッセージが表示されます。

図13 – AWS Managed Microsoft Active Directoryのプライマリリージョン以外での信頼関係設定画面

プライマリリージョンから、既存のルートドメインへの信頼関係を確立します。条件付きフォワーダーの転送先として利用する既存のドメインのDNSサーバーのIPアドレス等、必要な情報を入力します。これにより、AWS Managed Microsoft Active Directoryは信頼関係を確立するために必要なcustomer.comドメインの名前解決が可能なDNSサーバーを見つけることができます。

図14 – Forest trustを選択し、既存のcustomer.comドメインと信頼パスワード及び条件付きフォワーダーのIPアドレスを入力して信頼関係を作成する

前のステップで指定した信頼パスワードと同一のものを使用し、既存のドメインが信頼関係を受け付けるよう設定します。

図15 – customer.comドメインがaws.localドメインからの信頼関係を受け付けるよう設定する

これで、ハイブリッド Active Directory構成に必要なすべてのセットアップが完了しました。次に、既存のドメインの認証情報を使用して AWS リソースにアクセスする方法を見てみましょう。

図16は、sg.customer.comのユーザーがAmazon FSx for Windows File Server上に作成されている共有フォルダにアクセスする際の流れを表しています。

図16 – Amazon FSx for Windows File Server上のリソースに対するユーザーアクセスの流れ

この一連の動作は、以下の4つのステップで説明できます。

1. ユーザーが sg.customer.comの認証情報を用いてクライアントにログインし、\\fsx1\share にアクセスする
   1. a. クライアントコンピュータは、ドメインコントローラー上のKerberos KDCにコンタクトし、FSx for Windows File ServerのSPNのサービスチケットを要求する
   2. b. グローバルカタログサーバー上でcustomer.comのフォレストが持っている信頼関係の情報が検索される
   3. c. 片方向のフォレスト信頼関係が見つかると、信頼関係に登録されているドメイン名サフィックスと要求されたSPNのサフィックスが比較され、一致するものが検索される
2. クライアントはルートドメインであるcustomer.comのドメインコントローラーにコンタクトし、aws.localフォレストへのリファラル（参照）を要求し、ルートドメインはこれに応答する
3. クライアントはaws.localのフォレストにコンタクトし、同じSPNのサービスチケットを要求する。aws.localドメインはグローバルカタログからそのSPNを検索し、結果をクライアントに返す
4. クライアントは再度aws.localドメインのKDCにコンタクトし、ユーザーの代わりにFSx for Windowsファイルサーバーへのアクセス権を得るためのネゴシエーションを実施する

クライアントはサービスチケットを受け取ると、それをFSx for Windows File Serverに送信し、FSx for Windows File Server側はこのチケットに基づきユーザーのセキュリティ資格を検証した上でそれに応じたアクセストークンを作成します。

クリーンアップ

PoCまたはご自身のテストのために今回の実装を行った場合は、不要な利用料金の発生を防ぐために、テスト完了後には以下のサービスを削除しおいてください。

1. Amazon EC2インスタンス
2. Route53
3. AWS Managed Microsoft Active Directory
4. Transit Gateway
5. AWS VPC

まとめ

今回は、AWS Managed Microsoft Active Directoryのマルチリージョン機能を活用し、ハイブリッド構成のActive Directoryの導入を簡単に実施する方法をご紹介しました。

この記事を通して、お客様の目的を達成するために必要なすべての主要コンポーネントとステップを、さまざまな観点から説明してきました。今回扱った構成例では複数のドメインと複数のフォレストが存在していましたが、同じシナリオを単一のドメインと単一のフォレストを使用する小規模な環境にも適用できます。AWS上でActive Directory Domain Servicesのアーキテクチャーを設計する際のその他のベストプラクティスについては、Active Directory Domain Services on AWSのホワイトペーパーをご参考ください。

本投稿はKyaw Soe HlaingとBrett Speddingによる記事を翻訳したものです。翻訳はソリューションアーキテクトRyan Choが担当しました。

元の記事：https://thinkwithwp.com/blogs/architecture/field-notes-designing-multi-region-aws-managed-microsoft-active-directory-for-hybrid-environments

投稿者について

Kyaw Soe HlaingはWindowsワークロードを担当するAWSのパートナーソリューションアーキテクトです。Kyawは様々なシステムの移行及びモダン化プロジェクトを成功に導くために、日々AWSのお客様とパートナーを支援しています。

Brett SpeddingはMicrosoftワークロードを専門とするAWSのシニアソリューションアーキテクトです。Brettはお客様のビジネスにおける複雑な問題の解決にやりがいを感じており、15年以上の経験を活かしお客様のクラウドジャーニーをご支援しています。