Amazon Web Services ブログ

セルフマネージド型 Active Directory を AWS Control Tower に拡張

クラウドジャーニーの初期段階によくあるユースケースの 1 つとして、既存のアイデンティティサービス (Microsoft Active Directory など) を使用することが挙げられます。このブログでは、AWS Control Tower をセットアップして、AWS Managed Microsoft AD を介してユーザー認証をセルフマネージド型 Microsoft Active Directory に委任する方法について解説します。既存のオンプレミスの Active Directory を AWS Control Tower に接続する方法を、シミュレート環境でみていきます。

背景

AWS Control Tower には、マルチアカウント環境における SSO アクセスを簡素化するクラウドベースのサービス、AWS Single Sign-on (AWS SSO) が組み込まれています。ユーザー認証の管理は、AWS SSO を使用して、AWS Control Tower に接続されたディレクトリが行います。各ユーザーに割り当てられたアカウントアクセスおよび付与されたアクセス許可のレベルによって、認証が判断されます。

AWS SSO はアクセス許可のセットを使用します。これは、ユーザーのアクセス許可が、所定の AWS アカウントにアクセスするために有効かどうかを判断する、管理者定義ポリシーのコレクションです。アクセス許可のセットには、AWS が管理するポリシーまたは AWS SSO に保存されているインラインポリシーのいずれかが含まれています。ポリシーとは、基本的に、1 つまたは複数のアクセス許可ステートメントのコンテナとして機能するドキュメントのことです。所定の AWS アカウント内でユーザーがどのアクションを実行できるかまたはできないかは、これらのステートメントが判断します。アクセス許可のセットは AWS SSO に保存され、AWS アカウントのみに使用されます。アクセス許可のセットは最終的に、所定の AWS アカウントの AWS Identity and Access Management (IAM) のロールとして作成されます。これらのロールには、ユーザーが AWS SSO を介してロールを引き受けることを可能にする信頼ポリシーが含まれています。

AWS Control Tower は、AWS SSO のデフォルトのアイデンティティソースであるクラウドネイティブのディレクトリと共にセットアップされます。このディレクトリには、事前定義されたグループ、アクセス許可セット、SSO アクセスが含まれています。

ソリューションの概要

このチュートリアルは、AWS Control Tower の作業バージョンをすでに所有しているユーザーが対象です。まだ所有してない方は、Jeff Barr のチュートリアル記事に従って AWS Control Tower を設定できます。お使いの AWS 環境をオンプレミスのネットワークに安全に接続する方法については、AWS VPN または AWS Direct Connect を参照してください。

以下の図は、ユーザー認証の流れを大まかに示したものです。

  1. 外部のアイデンティティソースから接続したエンドユーザーは、AWS SSO を介して、AWS Control Tower が管理するマルチアカウント環境で認証されます。
  2. AWS Managed Microsoft AD がAWS SSO 内のアイデンティティソースとして選択され、ユーザー認証のタスクをセルフマネージド型 Active Directory に委任します。このディレクトリは、個別のパブリックサブネットで実行している EC2 インスタンスでホストされています。
  3. AWS Control Tower は、ユーザーに割り当てられたアクセス許可のセットに基づいて、AWS リソースへのアクセスをユーザーに許可します。

以下のフローチャートは、このチュートリアルで説明する 6 つのステップを示したものです。

  1. テスト環境のセットアップ。このステップでは AWS CloudFormation のスタックを作成し、以下のコンポーネントを含むテスト環境をセットアップします。
    • Virtual Private Cloud (VPC) のセットアップ (2 つのパブリックサブネット付き)。
    • 2 つのドメインコントローラー (それぞれ個別のパブリックサブネットにデプロイされる)。
    • Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上にある AWS Managed Microsoft AD と セルフマネージド型 Active Directory
  2. Active Directory 管理ツールのインストール。AWS Managed Microsoft AD とセルフマネージド型 Active Directory の管理に使用します。
  3. セルフマネージド型 Active Directory の設定。セルフマネージド型 Active Directory 上にネイティブの Active Directory フォレストを作成します。
  4. VPC アウトバウンドルールと DNS 条件付きフォワーダーの設定。
  5. マルチフォレスト間信頼環境の構築。
    • 最初に、セルフマネージド型 Active Directory から AWS Managed Microsoft AD への信頼を構築します。
    • 次に、AWS Managed Microsoft AD からセルフマネージド型 Active Directory への信頼を構築します。これで、AWS Managed Microsoft AD はリソースドメインとして機能できるようになります。オンプレミスのユーザーは、既存のコーポレート認証情報を使用して、AWS SSO を介して AWS のサービスにサインインすることができるようになります。
  6. ユーザー認証をセルフマネージド型 Active Directory に委任するように AWS Control Tower を設定。 最初に、セルフマネージド型 Active Directory からユーザーにアクセスを委任し、次に、このユーザー (testuser) が想定されたとおりに認証可能であることを検証します。

ステップ 1: テスト環境のセットアップ

AWS CloudFormation のテンプレートを起動する前に「Amazon VPC のクォータ」を参照して、デフォルトの制限を越えていないことを確認します。

  1. お使いの AWS Control Tower がデプロイされているリージョンに、新しいキーペアを作成します。本記事の執筆時点で AWS Control Tower が利用できるリージョンは、米国東部 (オハイオ)、欧州 (アイルランド)、米国東部 (バージニア北部)、米国西部 (オレゴン) です。
  2. [Launch Stack] (以下の画像) をクリックし、AWS Control Tower ホームリージョンにテスト環境をセットアップする CloudFormation のテンプレートを起動します。

.    

    • スタック名は AWSControlTowerADStack と設定します。
    • デフォルト管理ユーザーのパスワードを付与します。このパスワードは後ほど MyManaged\Admin にログインするときに使用します。
    • ステップ 1.1 で作成したキーペアを選択します。
    • 他のフィールドはデフォルトのままにします。[次へ] を 2 回選択します。[AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します] をクリックします。[スタックの作成] を選択します。CloudFormation スタックが約 1 時間かけて必要なリソースをデプロイします。デプロイを許可して作業が正常に完了したら「ステップ 2: Active Directory 管理ツールのインストール」へ進みます。

ステップ 2: Active Directory 管理ツールのインストール

  1. Amazon EC2 コンソールで、以下のステップにしたがって corp.example.com-mgmt インスタンスに接続します。
  2. スタートメニューから [Server Manager] を選択し、次に [ロールと機能の追加] を選択します。[次へ] をクリックします。
  3. [インストールタイプの選択] ページでロールベースのインストールか機能ベースのインストールを選択します。[次へ] を 2 回クリックします。
  4. [機能の選択] ページで次の操作を行います。
    • [グループポリシーの管理] を選択します。
    • [リモートサーバー管理ツール] を展開します。続いて [ロール管理ツール] を展開します。[AD DS および AD LDS ツール] と [DNS サーバーツール] を選択します。[次へ] をクリックし、[インストール] を選択します。

サインアウトし、以下のステップに従って自分の MyManagedAD.corp.example.com ドメインが機能していることを確認します。

  1. corp.example.com-mgmt EC2 インスタンスに接続します。「ステップ 1:テスト環境のセットアップ」のステップ 2 で CloudFormation スタックに付与したパスワードを使って、MyManagedAD\Admin としてログインします。
  2. スタートメニューの Windows 管理ツールの下で、[Active Directory ユーザーおよびコンピューター] をクリックします。
  3. MyManagedAD.corp.example.com を展開すると 2 つのドメインコントローラーがあることがわかります。これらは AWS Managed Microsoft AD をプロビジョニングしたときに自動的に作成されたものです。次のスクリーンショットを参照してください。corp.example.com-mgmt からサインアウトします。

ステップ3: セルフマネージド型 Active Directory の設定

このセクションでは、新しい Active Directory フォレストを作成し、名前解決でローカルの DNS サーバーを使用できるようにセルフマネージド型 Active Directory を設定します。

Active Directory Domain Services のインストール

  1. Amazon EC2 のコンソールで、 example.local-DC接続します
  2. スタートメニューから [Server Manager]、[ロールと機能の追加] を順に選択します。[次へ] をクリックします。
  3. [インストールタイプの選択] ページでロールベースのインストールか機能ベースのインストールを選択します。[次へ] を 2 回クリックします。
  4. [サーバーロールの選択] ページで [Active Directory Domain Services] を選択します。[(存在する場合) 管理ツールを含める] が選択されていることを確認します。[機能の追加] をクリックします。[次へ] を 2 回クリックし、[インストール] を選択します。

Active Directory Domain Services の設定

  1. Server Manager を開くと、画面トップにある管理という文字の横にフラグがあります。黄色い旗の下にある、[このサーバーをドメインコントローラーに昇格する] をクリックします。
  2. [デプロイ設定] ページで、[新規フォレストの追加] をクリックします。ルートドメイン名に example.local と入力し、[次へ] をクリックします。
  3. [ドメインコントローラーオプション] ページで次の操作を行います。
    • フォレストの機能レベルとドメインの機能レベルの両方で Windows Server 2016 を選択します。
    • [ドメインコントローラー機能の指定] で、Domain Name System (DNS) サーバーと Global Catalog (GC) が両方とも選択されていることを確認します。
    • ディレクトリサービス復元モード (DSRM) のパスワードを入力します。[次へ] を 2 回クリックします。
  4. [追加のオプション] ページで、NetBios のドメイン名が EXAMPLE であることを確認します。[次へ] を 3 回クリックします。サーバーが、ドメインコントローラーの前提条件を検証します。
  5. [インストール] をクリックします。サーバーが再起動し、インストールが完了します。この時点でサーバーは機能ドメインコントローラーになっています。

ステップ 4: VPC アウトバウンドルールと DNS フォワーダーの設定

VPC アウトバウンドルールの設定

  1. AWS Directory Service のコンソールから [ディレクトリ] へ進み、[MyManagedAD.corp.example.com] のボタンを選択します。次のスクリーンショットで示されている、MyManagedAD.corp.example.com の Directory ID をコピーしておきます。
  2. Amazon VPC コンソールの左サイドバーで [セキュリティグループ] を選択します。画面上部の検索バーに、前のステップでコピーした Directory ID をペーストします。このセキュリティグループは、AWS Managed Microsoft AD を最初にプロビジョニングしたときに自動的に作成されたものです。
  3. [アウトバウンドのルール] タブをクリックし、[編集] を選択します。[別のルールの追加] をクリックし、次の値を追加します。
    • [種類] では、[すべてのトラフィック] を選択します。
    • [送信先] には、0.0.0.0/0 と入力します。
  4. [保存] をクリックします。

DNS 条件付きフォワーダーの設定

  1. AWS Directory Service コンソールMyManagedAD.corp.example.com を選択し、両方の DNS アドレスを特定しメモします。次のスクリーンショットを参照してください。
  2. example.local-DC ドメインコントローラーに戻り、Server Manager を開きます。[ツール] メニューで [DNS] をクリックします。
  3. DNS サーバーを展開します。[条件付きフォワーダー] へ進みます。[新しい条件付きフォワーダー] を右クリックします。[DNS ドメイン] に [MyManagedAD.corp.example.com] と入力します。
  4. マスターサーバーの IP アドレスでは <Click here to add …> を選択し、本セクションでメモした 1 つ目の DNS アドレスを入力します。[入力] を選択します。2 つ目の DNS アドレスでもこのステップを繰り返します。
  5. [Active Directory にこの条件付きフォワーダーを保存し、次の方法でレプリケートする] の左にあるチェックボックスを選択します。次のスクリーンショットのとおり、[このフォレストのすべての DNS サーバー] を選択し、[OK] をクリックします。

セルフマネージド型 Active Directory にユーザーを作成する

  1. example.local-DC ドメインコントローラーから Server Manager へ進みます。画面トップの右側にあるメニューにある [ツール] から、[Active Directory ユーザーおよびコンピューター] を選択します。[example.local] を展開し、[ユーザー] を右クリックして testuser という新しいユーザーを作成します。
  2. testuser にパスワードを付与します。

ステップ 5: マルチフォレスト間信頼環境の構築

セルフマネージド型 Active Directory から AWS Managed Microsoft AD への信頼を構築する

  1. example.local-DC に接続したまま Server Manager を開き、[DNS] を選択します。DNS サーバー用として表示された IPv4 アドレスをメモします。このアドレスは、セルフマネージド型 Active Directory で MyManagedAD.corp.example.com から example.local ディレクトリへの条件付きフォワーダーを作成する際に使用します。次のスクリーンショットを参照してください。
  2. [ツール] で、[Active Directory ドメインと信頼] をクリックします。[example.local] を右クリックし、[プロパティ] を選択します。次の操作を行います。
    • [信頼] タブで、[新しい信頼] を選択します。
    • [信頼の名前] ページで、MyManagedAD.corp.example.com と入力します。
    • [信頼のタイプ] ページで、[フォレストの信頼] を選択します。
    • [信頼の方向] ページで、[双方向] を選択します。
    • [信頼のサイド] ページで、[このドメインのみ] を選択します。
    • [出力方向の信頼認証レベル] ページで、[フォレスト全体の認証] を選択します。
    • [信頼パスワード] ページで、自分の信頼パスワードを 2 回入力します。[次へ] を 3 回選択します。[完了] 、[OK] の順にクリックします。

AWS Managed Microsoft AD とセルフマネージド型 Active Directory の間に信頼を作成する

  1. AWS Directory Service コンソールでMyManagedAD.corp.example.com ディレクトリを選択します。[ネットワークとセキュリティ] タブをクリックします。
  2. [信頼関係] のセクションで、[アクション] を選択し、[信頼関係の追加] を選択します。次のスクリーンショットを参照してください。
  3. [信頼関係の追加] で次の入力を行います。
    • [信頼のタイプ] で、[フォレストの信頼] を選択します。
    • リモートドメイン名に、[example.local] と入力します。
    • 信頼パスワードに「セルフマネージド型 Active Directory から AWS Managed Microsoft AD への信頼を構築する」のステップ 9 で作成したパスワードを記入します。
    • 信頼の方向は [双方向] を選択します。
    • 条件付きフォワーダーには「セルフマネージド型 Active Directory から AWS Managed Microsoft AD への信頼を構築する」のステップ 1 でメモした DNS サーバーの IP アドレスを入力します。
    • [追加] をクリックします。次のスクリーンショットを参照してください。
  4. 信頼の検証プロセスには約 15 分かかります。信頼の検証が完了すると、[ステータス] 欄に [検証済み] と表示されます。次のスクリーンショットを参照してください。

これで、マルチフォレスト間 Active Directory 環境が完全に機能するようになりました。

ステップ 6: ユーザー認証をセルフマネージド型 Active Directory に委任するように AWS Control Tower を設定

このセクションでは、ユーザー認証をセルフマネージド型 Active Directory に委任するように AWS Control Tower を設定します。

  1. AWS Control Tower コンソールから [ユーザーとアクセス] へ進みます。画面の右側で [AWS Single Sign-On で表示する] をクリックします。
  2. [ID ソースを選択] を選択します。[ID ソースを変更] を選択します。[Active Directory] を選択します。米国東部 (バージニア北部) リージョンでは、[既存のディレクトリ] の下にある [MyManagedAD.corp.example.com] を選択します。[次へ] を選択します。
  3. ボックスに [CONFIRM] と入力します。[完了] をクリックします。
  4. これで、AWS Managed Microsoft AD による信頼の委任を介して、AWS Control Tower のデフォルトの ID ソースとしてセルフマネージド型 Active Directory を使用できます。

セルフマネージド型 Active Directory からのユーザーへのアクセスを委任する

  1. AWS Single Sign-On ページに戻り、[AWS アカウント]、[ログアーカイブ]、[ユーザーの割り当て] の順に選択します。
  2. ドロップダウンメニューから、[example.local] を選択します。[ユーザー] をクリックします。検索フィールドに testuser と入力します。[次へ: アクセス許可セット] をクリックします。
  3. [AWSReadOnlyAccess] を選択します。[完了] をクリックします。

testuser を認証できるか検証する

  1. AWS SSO コンソールの一番下にある、AWS SSO ユーザーポータル URL をコピーします。次のスクリーンショットを参照してください。
  2. この URL を新しいブラウザのタブに貼り付けます。「セルフマネージド型 Active Directory で testuser を作成する」のステップ 2 で作成したパスワードを使って、testuser としてログインします。これで、ログアーカイブのアカウントに、testuser として読み取り専用でアクセスできます。

クリーンアップ

今後、料金が発生しないようにするため、CloudFormation のコンソールから AWSControlTowerADStack CloudFormation スタックを削除してサンプルのリソースを削除するか、次の AWS コマンドラインインターフェイス (AWS CLI) コマンドを実行します。

aws cloudformation delete-stack –stack-name AWSControlTowerADStack

まとめ

本記事では、セルフマネージド型 Active Directory を AWS Control Tower に拡張する方法についてご紹介しました。これで、オンプレミスのユーザーが自分のコーポレート認証情報を使ってマルチアカウント環境内にある AWS リソースにアクセスする方法を管理できるようになります。

著者について

Cher Simon は AWS のシニアテクニカルアカウントマネージャーです。AWS の顧客と連携し、アーキテクチャやオペレーション、コスト最適化といった課題の解決に取り組んでいます。