Amazon Web Services ブログ
Amazon FSx for Windows File ServerをAzure ADDSドメインと使用する方法
このブログはAdeleke Coker (Sr. Cloud Support Engineer)によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。
ADDS上でホストされているActive Directoryにユーザーのアイデンティティがある場合、アイデンティティをAWSに移行または同期する必要なく、そのActive DirectoryでAmazon FSx for Windows File Serverを使用することができます。このブログでは、ラボ環境での例を用いて、Amazon FSxを既存のADDSに参加させる方法を示します。既存のADDSのアイデンティティは、保存されたファイルにアクセスするためにこの共有を利用することができ、Amazon FSx for Windows File Serverのファイル共有に対して認証するためにAzure ADのユーザーを使用することができます。AWS上にActive Directory環境を展開して設定する必要はなく、ユーザーのアイデンティティをAWSに同期させる必要もなく、既存のADDSにプラグアンドプレイで簡単に導入できます。なお、Amazon FSx for Windows File ServerはAzure Active Directory(AAD)をサポートしていません。AADは、クラウドネイティブな認証ディレクトリで、ユーザーとグループのみを含むことができ、Kerberos認証やグループポリシーをサポートしていません。
ソリューションの前提条件
- AWS内の条件
- Azure Virtual Network (Vnet)へ接続するためのAmazon Virtual Private Cloud (Amazon VPC)
- ファイルシステムとして使用するAmazon FSx for Windows File Server
- Transit GatewaysやVPN接続などを作成するための適切な権限を持つAWS Identity and Access Management (IAM)ユーザー/ロール
- テスト用のAmazon Elastic Compute Cloud (Amazon EC2)インスタンス
- Azure内の条件
- AWSとのサイト間VPN接続で使用する仮想ネットワークゲートウェイ
- AWSへのVPN接続で使用するローカルネットワークゲートウェイ
- Amazon FSx for Windows file serverをドメインに参加させるための、Azure AD Domain ServicesのDNS IPアドレス
例えば、以下のようなIPレンジを使用します(Amazon VPCのCIDRとAzureのCIDRは重ならないように注意してください):
Amazon VPC CIDR: 172.25.0.0/16
Private Subnet | 172.25.10.0/24 |
Public Subnet | 172.25.20.0/24 |
既存のAzure Vnet CIDR: 192.168.0.0/16
Public Subnet | 192.168.10.0/24 |
Private Subnet | 192.168.20.0/24 |
ソリューションの概要
このソリューションには、AWSとAzureのステップがあり、適切に動作させるためには、順次完了させる必要があります。一部のコンポーネントでは、AWSの前にAzureでのステップを完了する必要があり、その逆もまた然りです。
次のステップは、Azure上で完了させます:
- 既存のリソースグループとバーチャルネットワークで、ゲートウェイサブネットを作成します。
- 仮想ネットワークゲートウェイ(VNG)を作成します。
- ローカルネットワークゲートウェイ(LNG)を作成します。
- VPN接続を作成します。
次のステップは、AWS上で完了させます:
- 既存のAmazon Virtual Private Cloud(VPC)で、Customer Gatewayを作成します。
- 仮想プライベートゲートウェイ(VPG)を作成します。
- サイト間VPN接続を作成します。
- Dynamic Host Configuration Protocol (DHCP) オプションセットを作成します。
- EC2インスタンスをAzure Active Directory Domain Services Domainに参加させ、ファイルシステムのOU構造を作成します。
- Amazon FSxをAzure Active Directory Domain Services Domainで起動します。
ゲートウェイサブネットの作成 – (Azure, step 1)
Vnetにゲートウェイサブネットを作成します。マイクロソフトでは、ゲートウェイサブネットに/28または/27を使用することを推奨しています。
仮想ネットワークゲートウェイ(VNG)の作成 – (Azure, step 2)
AzureでVNGを作成するには、既存の仮想ネットワークを選択し、VPNタイプにルートベース、パブリックIPアドレスに新規作成を選択します。その他はデフォルトのままにしておきます。
この作業は平均30分で完了します。完了したら、作成されたパブリックIPアドレスをメモしてください。これは、AWS上にカスタマーゲートウェイを作成するために必要です。
カスタマーゲートウェイ、バーチャルプライベートゲートウェイ、サイト間VPN接続の作成 – (AWS, steps 1-3)
- AWSマネジメントコンソールからVPCにアクセスします。
- カスタマーゲートウェイを作成します; ここで先ほどメモしたAzureの仮想ネットワークゲートウェイのパブリックIPアドレスを使用します。
- 仮想プライベートゲートウェイ(VPG)の作成 – Amazon default ASNを選択します。
- 作成した仮想プライベートゲートウェイを選択し、Actions→Attach to VPCを選択して、仮想プライベートゲートウェイ(VPG)をAmazon VPCにアタッチします。
- Azureへのサイト間VPN接続を作成します。先に作成したカスタマーゲートウェイとバーチャルプライベートゲートウェイを選択します。ルーティングオプションでスタティックを選択し、スタティックIPプレフィックスにAzureのVnet CIDRを指定します。
- 利用可能になったら、サイト間VPN接続をクリックして、サイト間接続を確立するVPNトンネルの情報を含む設定をダウンロードします。この画面では、VendorオプションとしてGenericを選択しています。
ダウンロードした設定ファイルを使用して、Azureでローカルネットワークゲートウェイと接続を作成します(手順は以下)。設定ファイルには多くの情報が含まれていますが、ここでは主に、両方の VPN トンネルの Pre-Shared Key と 仮想プライベートゲートウェイ(VPG) に注目します。以下のサンプルをご覧ください:
ローカルネットワークゲートウェイの作成 – (Azure, step 3)
Amazon VPNの各トンネルに1つずつ、2つのローカルネットワークゲートウェイを作成します。Azureでローカルネットワークゲートウェイ(LNG)と接続を作成するには、先程ダウンロードしたコンフィグレーションの情報が必要です。IPアドレスも同じくダウンロードしたコンフィグレーションの情報を使用します。Address spaceにはAWS Production VPCのCIDRを入れますが、後からIPアドレスを追加することができます。同じ手順で2つ目のトンネルの構成情報を使用し、2つ目のローカルネットワークゲートウェイを作成します。
VPN接続の作成 – (Azure, step 4)
ローカルネットワークゲートウェイ(LNG)の設定が完了したら、今度はそれぞれのローカルネットワークゲートウェイ(LNG)に接続を作成します。
- 1つ目のローカルネットワークゲートウェイ(LNG)をクリックし、接続をクリックして追加をクリックします。
- 接続に名前を付け、先ほど作成した仮想ネットワークゲートウェイ(VNG)を選択します。
- 接続タイプとしてSite-to-site (IPsec)を選択します。
- Shared key (PSK)に、ダウンロードした設定ファイルにあるトンネル1のPre-shared key を使用してください。コピーしたpre-shared keyが、ローカルネットワークゲートウェイ(LNG)で作成したトンネルと同じものであることを確認してください。
- IKE ProtocolにIKEv2 を選択します。AWSの設定ファイルではIKEv1となっていますが、v1にするとAzureでの接続ができなくなります。
- OKをクリックして、接続を作成します。同じ手順を繰り返して2つ目の接続も作成します。
- 作成したら、ステータスがConnectedに変わるのを待ちます。AWSのトンネル側はUPと表示されているはずです。
仮想ネットワークゲートウェイ(VNG)と各ローカルネットワークゲートウェイ(LNG)への接続:
Azureのサイト間VPNでは、接続がConnectedと表示されます:
AWSのVPN接続ではトンネルのステータスがUPと表示されます:
次に、Amazon VPCのRoute Table上にRoutesを作成します。ここでは、Azureネットワーク192.168.0.0/16のルートを作成し、ターゲットにAmazon VPCのバーチャルゲートウェイを指定します。
AWSでDHCPオプションセットを作成 – (AWS, step 4)
既存のAzure Active Director Domain ServicesからDNSのIPアドレスを取得します。2つのIPアドレスとDNS名を使用して、AWSでDHCPオプションセットを作成し、これをAmazon VPCに関連付けます。Amazon VPCのDHCPオプションセットを変更すると、これに依存する他のサービスに影響を与える可能性があることに注意してください。
それでは、Amazon VPCからAzureへの接続をテストしてみましょう。このAmazon VPC内でAmazon EC2(Windows)インスタンスを起動し、Azure Active Directoryドメインに参加して、そのドメインの管理インスタンスとして動作させる必要があります。すべてが正しく設定されていれば、そのVPC内のEC2インスタンスからAzure Active Directoryドメイン名を解決できるはずです。
EC2インスタンスをAzure Active Directory Domain Servicesドメインに参加させましょう。なお、Azure Active Directory Domain Servicesを新規に導入する場合、オンプレミスのユーザーに対してAzure AD Domain Servicesのパスワードハッシュの同期を有効にしていない場合は、有効にする必要があります。Azure Active Directoryで直接作成されたようなクラウドネイティブのユーザーアカウントの場合、Azure AD Domain Servicesに同期するためのハッシュのパスワードをリセットする必要があります。このプロセスはこのブログでは解説しませんので、詳細はこちらを参照してください。Azure AD DSのユーザーアカウントを有効にするおよびAzure AD DSでパスワードの同期を有効にする。
- 同じAmazon VPCとリージョンでEC2インスタンスを起動します。
- Azureでユーザーのパスワードをリセットしたことを確認します。
- ユーザーアカウントをAzure Active DirectoryのAzure Active Directory DC Administratorsグループに追加します。
- EC2インスタンスをADDS {ds.awslab.com}ドメインに参加させます。
Amazon FSx ファイルシステムの OU 構造の構成 – (AWS, step 5)
- OUやその他のドメインポリシーを管理するためのRSATツールをインストールします。
- Amazon FSxとGroupのOUを作成します。
Amazon FSxをAzure Active Directoryドメインサービスドメインで起動する – (AWS, step 6)
これで、ファイルサーバー用のOUとサービスアカウントができましたので、Active Directoryに参加するAmazon FSxファイルシステムの作成に進みます:
- 完全修飾ドメイン名はADDSドメイン名であり、DNSサーバーのIPアドレスはADDSドメインのもので、DHCPオプションセットの作成にも使用したものです。サービスアカウントのユーザー名とサービスアカウントのパスワードは、Azure Active Directory DC Administratorsグループに追加したユーザーアカウントです。OUは、前のステップで作成したものです。
- Delegated file system administratorsグループには、Azure Active DirectoryまたはAzure Active Directory Domain Services内にネイティブに作成されたグループを指定する必要があります(オンプレミスからAzure AD Connectで同期されたグループを指定しても機能しません)。グループを指定しない場合、Amazon FSxは、Azure Active Directory Domain ServicesのDomain Adminグループをデフォルトとしますが、これはお客様が管理することはできません。Azure Active Directory Domain Servicesのグループ管理については、こちらをご参照ください。
- 作成が成功すると、コンソール上で状態がAvailableと表示され、Amazon FSxコンピュータオブジェクトが指定されたOUにあるはずです。
指定されたOU内のAmazon FSxコンピュータオブジェクト:
- ここで、ファイルシステムをマウントし、共有にアクセスします。EC2インスタンスやAmazon VPCのサブネットへのローカルトラフィックを許可するために、ファイルシステムに関連付けられたセキュリティグループの編集を忘れないでください(FSx for Windows File Server port requirementsの完全なリスト)。
ファイル共有へのアクセス:
- 今回はPowerShellでのリモート管理でテストします。なお、これを実行するユーザーは、Amazon FSxファイルシステム作成時に指定されたグループのメンバーである必要があります。詳しくはこちらのドキュメントをご覧ください。
事後処理(クリーンアップ):
最後に、展開したリソースを削除して、今後の料金発生を回避します。
Amazon FSx file system
Amazon FSx コンソールから、Amazon FSxで作成したファイルシステムを選択します。Actions メニューをクリックし、Delete file systemをクリックします。最終的なバックアップを作成しないことを選択し、削除を確認するためにファイルシステムIDを入力します。最後にもう一度、Delete file systemをクリックします。
Amazon EC2
Amazon EC2 コンソールから、ADDSドメインに参加するために起動したEC2インスタンスを選択します。Actions、Instance stateを選択し、最後にterminateを選択します。
Amazon VPC
- DHCPオプションセットをクリックし、作成したオプションセットを選択します。Actionsをクリックして、Delete DHCP options setをクリックします。deleteと入力し、Delete DHCP options set をクリックします。
- では、他のVPCリソースをクリーンアップしましょう。Site-to-Site VPN Connectionsをクリックして、作成したVPN接続を選択します。Actionsを選択し、続いてDelete を選択します – 確認のためにもう一度Delete をクリックします。
- Virtual Private Gatewaysをクリックします。このラボで作成したVPGを選択し、Actionsを選択します。その後、Detach from VPCを選択し、Yes と Detachの順に選択します。次に、ActionsからDelete Virtual Private Gatewayを選択し、Yes から Deleteを選択します。
- Customer Gatewaysをクリックします。作成したカスタマーゲートウェイを選択し、Actionsを選択、次にDelete customer gatewayをクリック、最後にYes をクリックします。
- 最後に、このデモのために作成したVPCを選択します。ActionsからDelete VPCを選択し、Delete VPCをクリックすると、このAmazon VPC内に作成されたすべてのサブネット、ゲートウェイ、エンドポイント、ネットワークインターフェース、セキュリティグループ、ルートテーブルが削除されます。
まとめ
この記事では、Amazon FSx for Windows File ServerをAzure Active Directory Domain Servicesのマネージドドメインに参加させる方法を示しました。最初にAmazon VPCとAzure Virtual Networkの間の通信を正常に確立しました。その後、Azure Active Directoryユーザーを使用して、ユーザー資格情報をAWSに同期する事なくファイル共有を認証しました。このソリューションにより、Azureのユーザーは、コンプライアンスやAWSへのユーザーIDの移行や同期の管理オーバーヘッドを気にすることなく、Amazon FSxファイル共有の機能やメリットを利用することができます。
このブログ記事を読んでいただきありがとうございます。今後も、Amazon FSx for Windows File Serverを簡単に活用して、ビジネスアプリケーションの最適化に役立てる方法をブログで紹介していきたいと思います。ご質問やご意見がございましたら、ご遠慮なくコメント欄にお寄せください。