Azure AD 上で管理しているユーザで、AWS の DaaS ( Desktop as a Service ) である Amazon WorkSpaces を利用する方法を検証してみました。
WorkSpaces は、 AWS の ディレクトリサービスである Simple Active Directory やMicrosoft Active Directory でユーザ情報を管理するか、Active Directory Connector ( AD Connector ) で 既存の Active Directory ( AD ) との接続構成をとる必要があります。後者の場合、 AD Connector は 既存 AD へのプロキシとしての役割を果たし、 ユーザ情報は既存 AD で一元管理されることになります。
AD Connector の使用事例を探してみると、オンプレで自前管理している AD との接続に関する記事が多くヒットしますが、最近では脱オンプレ かつ Azure AD でユーザを一言管理している組織も多いと思います。 Azure AD と AD Connector をつなげる方法がないか調べたところ、こちらの記事にたどり着きました。
Azure AD と Azure Active Directory Domain Services ( AAD DS ) 間でユーザ情報を同期させ、 AD Connector を AAD DS へのプロキシとして構成することで、 WorkSpace （ Windows 10 バンドル ）に Azure AD での管理ユーザでサインインできるようです。
以下の検証環境を構築し、上記が実現できることを確認したので、検証環境構築の作業記録を残しておきます。
ボリュームが膨らんだため、① AWS と Azure の間のネットワーク接続（本記事）、② AD Connector と AAD DS の接続、のふたつに記事を分けています。
②はこちらです。
- 前提
- ステップ① AAD DS 関連コンポーネントの作成
- ステップ② WorkSpaces 用の VPC ・サブネットを作成
- ステップ③ AWS ・ Azure のネットワークを VPN で接続
- まとめ
- 参考情報
前提
検証に利用した Azure の環境です。
Azure サブスクリプション
Free Trial を利用しました。今回の検証（ ¥20,000 分）はこの無償枠内でおさまりました。
https://azure.microsoft.com/ja-jp/free
Azure AD のプラン
Microsoft 365 E5 を使用している関係で、検証環境は Azure AD Premium P2 エディション となっています。
こちらの比較表を確認した限りでは Office 365 に紐づく Free エディションでも同様の確認ができるように思いますが、支障が出た場合はトライアルで上位プランを試してみてください。
テナント名
独自ドメイン ( pirox.dev ) で Azure のテナントを作成しています。今回の検証では独自ドメインの必要性はないと思いますが、念のため記載しておきます。
ステップ① AAD DS 関連コンポーネントの作成
こちらのチュートリアルを参考にして、 Azure AD DS 関連のコンポーネントを作成します。
作成開始
Azure Portal で、 Azure Domain Serviece > 追加 をクリックします。
基本設定
事前に作成した Free Trial のサブスクリプション内で、 sample-pirox というリソースグループを新規作成して登録しました。
DNS ドメイン名にはカスタムドメイン ( pirox.dev )を指定しましたが、デフォルトの設定でも問題ないかと思います。
場所（リージョン）はお好みですが、 東日本 を選択しました。（ WorkSpaces も東京リージョンで利用したため。）
フォレストの種類は、チュートリアルの指定どおり ユーザ とします。
ネットワーク設定
デフォルト設定のまま、 AAD DS を配置する仮想ネットワークとサブネットを作成します。
※仮想ネットワークの CIDR = サブネットの CIDR で作成されるため、後続の設定で仮想ネットワークを拡張します。
管理設定
こちらもデフォルト設定のままです。
同期
デフォルト設定のまま次へ。
確認および作成
各種設定値の確認画面が表示されるので、内容に問題がなければ「作成」をクリックします。
40分ほどかかって、以下のリソースが作成されました。
（参考）デプロイの待ち時間中に AAD DS のお勉強
AAD DS は、サーバの管理不要で Active Directory Domain Service の機能が利用できるマネージドサービスです。 裏では仮想サーバ ( Domain Controller ) が複数の Azure Availability Zone に分散配置され、一定の可用性が担保されるようですね。
Azure Active Directory Domain Services (Azure AD DS) では、Windows Server Active Directory と完全に互換性のあるマネージド ドメイン サービス (ドメイン参加、グループ ポリシー、ライトウェイト ディレクトリ アクセス プロトコル (LDAP)、Kerberos 認証、NTLM 認証など) が提供されます。 クラウドでドメイン コントローラーのデプロイ、管理、および修正プログラムの適用を行わなくても、これらのドメイン サービスを使用することができます。 Azure AD DS は既存の Azure AD テナントと統合されるので、ユーザーは既存の資格情報を使用してサインインできるようになります。
Azure AD から 以下のユーザ属性情報が自動同期されるとのこと。
- UPN
- SAMAccountName
- パスワード ※ハッシュ値
- プライマリ ユーザーおよびグループの SID
- ユーザーとグループの SID 履歴
従来の Acitive Direcotory Domain Services （自己管理型 AD DS）との比較表を見ると、ドメイン/フォレストの信頼が不可といった一部制約があるものの AAD DSでほとんどの機能が代替可能なように思います。 新たに構築する場合は、ほぼ AAD DS の選択となるのではないでしょうか。 docs.microsoft.com
マネージドドメインをデプロイ
AAD DS のデプロイ直後は、以下のとおりマネージドドメインの構成が進行中となっています。完了までに30分ほどかかるため、先にステップ②を進めておくとよいです。
ステータスが「実行中」（構成完了）となったら、仮想ネットワーク内の DNS サーバ 情報を設定します。（ 「仮想ネットワークの DNS サーバ設定の更新」 で「構成」をクリック）
この操作により、仮想ネットワークの DNS サーバとして AAD DS の IP アドレスが指定されます。
ステップ② WorkSpaces 用の VPC ・サブネットを作成
AWS のマネージドコンソールで、 VPC とサブネットを作成します。
今回は sample-workspaces という名前（タグ）で VPC を作成します。
後続ステップで Azure の 仮想ネットワーク ( 10.0.0.0/16) と接続するため、重複しないよう CIDR は 10.1.0.0/16 とします。
WorkSpaces は Availability Zone が異なるサブネットを2つ必要とするので、以下のとおり作成します。
| 名前タグ | Availability Zone | CIDR |
|---|---|---|
| private-subnet-1 | ap-northeast-1a | 10.1.1.0/24 |
| private-subnet-2 | ap-northeast-1c | 10.1.2.0/24 |
※今回の検証とは別の目的でプライベートサブネット（インターネットとの接続を制限）としたかったため、このような名称にしています。
ステップ③ AWS ・ Azure のネットワークを VPN で接続
それぞれのネットワークを マネージド VPN （ソフトウェア VPN ）でつなぎ、 AD Connector から AAD DS へ接続可能な状態とします。
設定手順は クラメソさんのブログを参考にさせていただきました！！
※ここから AWS ・ Azure 間で手順が行き来するのでご注意ください。
Azure で作業 / ゲートウェイサブネットの作成
Azure VPN Gateway を配置するサブネットを作成します。
はじめに、現状では仮想ネットワーク ( aadds-vnet ) の IP アドレスがすべて aadds-subnet (10.0.0.0/24) に割り当てられてしまっているため、 CIDR の設定を変更します。
サブネットの設定画面に戻り、「ゲートウェイサブネット」をクリックします。
CIDR は 10.0.254.0/24 で作成します。今回は検証目的であるため、ネットワークセキュリティグループ等、他の設定は行わずに進めます。
作成が完了すると、以下のとおり表示されます。
Azure で作業 / Azure VPN Gateway の作成
作成したゲートウェイサブネットに Azure VPN Gateway をデプロイするため、 Marketplaces から 仮想ネットワークゲートウェイを選択して作成を開始します。
以下のとおり設定します。作成完了までに30分ほどかかりました。
作成が完了したら、 Azure VPN Gateway に割当てられたグローバル IP アドレスをメモしておきます。（後続作業の AWS カスタマーゲートウェイの設定時に必要な情報です。）
AWS で作業 / AWS カスタマーゲートウェイの作成
AWS のマネジメントコンソールに移り、 VPC のサービス画面でカスタマーゲートウェイを作成します。
静的ルーティングで設定し、 IP アドレスには Azure VPN Gateway に割り当てられたグローバル IP アドレスを入力します。
AWS で作業 / 仮想プライベートゲートウェイの作成
VPC のサービス画面から、仮想プライベートゲートウェイを作成します。
設定は以下のとおりです。
作成後、 VPC にアタッチします。
AWS で作業 / サブネットルートテーブルの作成
AD Connector - AAD DS 間で通信可能となるよう、ルートテーブルを作成しておきます。 AD Connector の ENI が WorkSpaces 用のサブネットに配置されるようなので、該当サブネットと Azure 間の経路情報を設定します。
名前タグを設定して、検証用の VPC に割り当てます。
作成したルートテーブルを指定し、「ルートの編集」をクリックして経路情報を設定します。
Azure の仮想ネットワーク(10.0.0.0/16) 向きの通信を、仮想プライベートゲートウェイにルーティングするよう設定します。
ルートテーブルを、サブネットに明示的に関連付けます。
WorkSpaces 用の2つのサブネットを指定して保存します。
AWS 側作業 / サイト間 VPN の作成
VCP のサービス画面で、サイト間の VPN を作成します。
作成済みの仮想プライベートゲートウェイやカスタマーゲートウェイを指定して、 VPN 接続を作成します。
作成後、 VPN の設定ファイルをダウンロードします。
サイト間 VPN では複数の Availability Zone に 2つの IPsec トンネルが提供されるため、接続情報が2つ用意されています ( IPSec Tunnel #1 / #2 ) 。それぞれの Pre-Shared Key と Virtual Private Gateway の情報を確認しておきます。
なお、設定ファイル内では IKE のバージョンが IKEv1 と記述されていますが、実際には IKEv2 を使用します。（ サイト間 VPN は IKEv2 を サポート済み ）
IPSec Tunnel #1
================================================================================
- IKE version : IKEv1
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ← IPsec Tunnel #1 の Pre-Shared Key
・・・
Outside IP Addresses:
- Customer Gateway : A.A.A.A
- Virtual Private Gateway : B.B.B.B ← IPsec Tunnel #1 の AWS 側グローバル IP アドレス
・・・
IPSec Tunnel #2
================================================================================
・・・
- Pre-Shared Key : yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy ← IPsec Tunnel #2 の Pre-Shared Key
・・・
- Virtual Private Gateway : C.C.C.C ← IPsec Tunnel #2 の AWS 側グローバル IP アドレス
・・・
Azure で作業 / ローカルネットワークゲートウェイの作成
ローカルネットワークゲートウェイを作成します。
IP アドレスには、IPsec トンネルで対向となる グローバル IP アドレスを入力します。
作成したローカルネットワークゲートウェイの接続情報を設定します。
Pre-Sharaed key の値を入力します。※繰り返しですが、 IKE プロトコルは IKEv2 を利用します。
同様の手順で、IPSec Tunnel #2 用のローカルネットワークゲートウェイも作成します。
接続の確認
設定に問題がなければ、5分ほどで VPN 接続が確立します。
これで両クラウドのネットワークが繋がりました。
まとめ
- AAD DS の各種コンポーネントを作成した
- AD Connector と AAD DS を接続するためのネットワークを作成した
AWS 、 Azure ともに VPN サービスを使ったことがなかったので、良い機会となりました。 また、手動でポチポチ作成するのがなかなか辛かったため、 IaC ツールでのテンプレート作成にも挑戦してみたいと思います。
次回の記事で、実際に Azure AD での管理ユーザで WorkSpaces へのサインインが可能になります。
