Active Directoryを活用したAWS Management ConsoleへのSSO（AD Connector編）

藤本真司

2015.08.31 03:00

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

藤本です。

先日、ADFSをIdPとしたActive DirectoryとAWS Management Consoleの連携方法をご紹介しました。 Active Directory資産を活用したAWS Management ConsoleへのSSO

AD Connectorを活用すれば、更に簡単にActive DirectoryとAWS Management Consoleを連携できましたので、ご紹介します。

概要

AWSのサービスの一つにActive Directoryのようなディレクトリ管理サービスをフルマネージドで提供するDirectory Serviceがあります。更にその中に既存のActive Directoryとの接続を可能とするAD Connectorがあります。このAD ConnectorはActive Directoryへのプロキシとして動作し、AWSサービスとの連携を提供します。

今回ご紹介する方式はAD Connectorによって提供されるWebログインページからオンプレミスのユーザー名、パスワードを入力することでAD ConnectorがオンプレミスのActive Directoryにユーザー認証を行います。その結果、取得したユーザー情報からAssumeRoleを行い、IAM Roleを取得し、Management Consoleを操作することができます。

こちらの方式は公式のSAブログが大変わかり易いので、ご参照いただければと思います。 AD ConnectorをつかったオンプレミスのActive DirectoryからAWSへの接続方法

私が感じた今回の方式と前回の方式とのメリット／デメリットは以下になります。

【今回の方式の優位性】

他AWSサービスとの連携 AD ConnectorはAWS Management Consoleのユーザー認証をオンプレミスのADと連携することが目的ではなく、AWS内の他サービスの認証をオンプレミスのActive Direcotryにプロキシしてくれる機能です。そのためAmazon WorkSpaces、EC2インスタンスのドメイン参加やAmazon WorkDocs、Amazon WorkMailのユーザー認証も提供されます。
保守性前回の方式はADFSを構築、運用保守しなくてはいけませんでした。今回の方式は基本的にAWSがフルマネージドで提供してくれます。そのため運用保守が必要ありません。

【前回の方式の優位性】

セキュリティ前回の方式はログインページをADFSが持つことで外部からの通信を遮断出来ましたが、今回の方式はログインページがパブリックアクセスが可能です。またユーザー認証情報がAWSからオンプレミスに流れることからセキュリティ面は高いとは言えません。間違いなくVPN、もしくはDXによる情報の隠蔽が必要となります。

【ケースバイケース】

導入の敷居前回の方式はオンプレミスにADFSを導入する必要があり、今回の方式はセキュリティの話で上がった通り、VPN、DXの通信経路を確保する必要があります。こちらは何ともいえないところですね。

環境

AD OS : Windows Server 2012R2 ミドルウェア : Active Directory ドメインサービス、DNSサーバー ADドメイン : fujimoto-home 利用するADアカウント : sfujimoto (所属グループ : AWS-developer)

やってみた

前提として、オンプレミスに既にADがあり、AWSからオンプレミスのADの通信経路が確保されていることとします。ちなみに今回は暗号化なしのインターネット経由でAWSとオンプレミスを通信しています。バッドパターンです。本番環境で利用する時は必ずVPN、もしくはDXでオンプレミスとの通信経路を確保してください。

設定の流れは以下となります。

AD Connector作成
アクセスURL生成
IAM Roleマッピング
動作確認

AD Connector作成

オンプレミスのActive DirectoryへプロキシするAD Connectorを作成します。 AD Connectorは複数AZに必ず配置する必要があります。東京リージョンの場合、ap-northeast-1a/ap-northeast-1cへそれぞれ配置します。

Directory ServiceからAD Connectorの作成を行います。必要な設定は以下となります。

Directory DNS : ドメイン認証用FQDN Connector account username : AD認証用のユーザー名 Connector account password : パスワード DNS address : Directory DNSからActive DirectoryのIPアドレスを名前解決をしてくれるDNSサーバを指定

余談となりますが、今回はインターネット経由でAWSからAD Connectorへアクセスしましたが、AD ConnectorにはパブリックIPアドレスが付与されません。そのためNATインスタンスを利用してインターネットアクセスする構成とする必要がありました。

アクセスURL生成

ログインページのURLを生成します。ログインページのFQDNはサブドメインを指定することができます。<指定可能>.awsapps.comがFQDNとなります。

作成したAD Connectorの詳細ページを開き、Access URLのテキストボックスに指定したいサブドメインを入力します。

アクセスURLが生成されたら、Single Sign-Onを有効化にします。

IAM Roleマッピング

Active Directoryが持つユーザー名、もしくはグループ名とIAM Roleをマッピングします。 AD Connectorの詳細ページからIAM Roleを作成しつつ、ユーザー名、もしくはグループ名をマッピングすることが可能です。

[Apps & Services]の[AWS Management Console]の[Manage Access]を選択します。
[New Role]を選択します。
今回は新しくRoleを作成するため、[Create New Role]を選択します。
割り当てたいポリシーを選択します。今回はテンプレートに「PowerUser」を選択します。
ロール名はそのまま「PowerUser」とします。ポリシーを細かく調整したいのであれば、JSON形式のポリシーから設定することが可能です。
マッピングするユーザー、もしくはグループを選択します。今回もActive Directoryのユーザーが持つグループとIAM Roleをマッピングしたいのでグループを選択して、「AWS-developer」を選択します。テキストボックスに入力すると前方一致でActive Directorから情報を読み取って候補が表示されます。
設定内容を確認して、Roleを作成します。

動作確認

ログインページへアクセスします。 AWS Management Consoleのログインページは以下のURLにアクセスします。 https://<指定したサブドメイン>.awsapps.com/console

普段のAWS Management Consoleのログインページと違いますね。

Active Directoryのユーザー名、パスワードを入力します。

ログイン出来ましたね。権限も「PowerUser」のIAM Roleを得ることができています。

まとめ

いかがでしょうか？ ADFSを利用した連携と比べると、とにかく簡単でした。ADFSの要求規則という複雑な指定も書かなくて済みます。ただやはり気になるのはログインページがパブリックにあり、誰でもアクセス可能なところです。概要のメリット、デメリットにも記載しましたが、複数の方式があるということは機能のトレードオフとなります。サービスを利用するには何かしらの目的があってのことで、どこに重きを置くか目的を見失わずに実装方式を選択しましょう。