Help us understand the problem. What is going on with this article?

【AWS】AWS環境上にADサーバを立てて、複数アカウントにシングル・サインオンする【ADFS】

More than 3 years have passed since last update.

この記事で紹介すること

この記事では、複数のAWSアカウント間でSingle Sign-On(SSO)を実装するための方法について解説します。

AWSのアカウント間でSSOを実装するには、google等のアカウントを利用して認証を行う方法と、自前のActive Directory(AD)サーバの認証を利用するActive Directory Federation Services (ADFS) を用いる方法があります。

この記事では、後者のADFSを用いた認証を利用してSSOを実装する方法を紹介していきます。

前提知識

この記事ではADFSを用いたSAML認証プロバイダの作り方について紹介します。
以下の内容についてある程度触ったことのある方が見てわかる内容を目指しています。

  • AWSのIAMを触ったことがある
  • AWS Security Token Serviceがどのようなものかイメージがつく
  • Active Directoryがどのようなものか知っている
  • Windowsサーバを触ったことがある
  • SSL証明書が何かわかる
  • DNSの基本的な概念を理解している

作業環境

作業用のPCはmacを使用しています。
作業PC以外は全てAWS上のリソースを利用しています。

複数のアカウントにログインする。のを試すため、AWSのアカウントを2つ以上持っている事を前提とします。
AWSのアカウントはメールアドレスが異なれば同じクレジットカードでも作ることが出来るため、この記事の内容を試す前に2つ目のアカウントを取得することをおすすめします。

なぜ、SSOが必要なのか

実装方法を紹介する前に、なぜSSOを利用しようと思ったかについて簡単に説明します。

私は、いつの間にか個人アカウントが何個も出来上がってしまいました。
最初は複数のアカウント間でSwitch Roleの機能を使ってアカウントを切り替えていたのですが、読み取り・操作等も考慮にいれるとアカウント番号を入力したりと切り替えがかなり面倒になっていました。

ADFSを利用したSSOであれば、一度ADサーバの認証を通してしまえばアカウント間・ロールの切り替え時に面倒な認証をしなくて良いのでストレスフリーです。

できるだけ面倒なことをしないために、あとIdP興味あるじゃろ?
という理由で個人環境にADFSを実装してみようというお話です。

なお、今回は個人環境での利用を前提としているため可用性を考えた構成は取りません。落ちたら素直にIAMログインしよう!の精神です。

環境構成

今回実装する環境は以下のようになります。

環境構成図

アカウント情報

アカウント番号 用途    以後のアカウント表記
123456789012 ADサーバ稼働アカウント アカウント蘭子
098765432109 別アカウントにログイン出来るか確認用アカウント アカウント幸子

ええ、趣味です。

AD+ADFSサーバ

今回はADとADFSは同一サーバ上(1台)で構成します。
SimpleADを利用して構築しても可能ですが、無料枠が750時間なのでEC2上で組んでいます。

  • Windows Server 2012 R2 Japanese
  • AMI ID:ami-af6f85ce
  • インスタンスタイプ:t2.micro
  • Windowsマシン名:ad01
  • セキュリティグループはHTTPS/RDPを使用

ドメイン

ADサーバで利用するドメインは以下のものを使用します。
今回はドメインは取得していない状態での作業を想定しているため、端末のhostsファイルを用いて名前解決をします。
外部公開可能なドメインをお持ちの方はRoute53と組み合わせてそちらを利用しても大丈夫です

adfs-sso.local

IAMロール

ADFSによるフェデレーションログインでは、IAMロールの権限を引き受けることになるため、2つのアカウントにそれぞれ下記のポリシーを当てたロールを用意します。

  • AdministratorAccess
  • SecurityAudit

以上が今回使用する環境の説明です。
では、Windowsインスタンスを用意し実際に作業していきます。

[アカウント蘭子] Windowsインスタンス上での作業

前提条件:WindowsServerインスタンスが起動し、RDP接続が確立している

Windowsインスタンスに以下の役割をインストールします

  • Active Directory ドメインサービス
  • Active Directory Federation Services
  • Webサーバー(IIS)

スクリーンショット_2016-06-30_17_51_41.jpg

IISに関しては、ADFS構築時にSSL証明書の入力を求められるため、オレオレ証明書を簡単に用意するために導入しています。

役割のインストールが終了したらWindwosのホスト名を変更します。

ホスト名変更(参考)

スクリーンショット_2016-06-30_18_12_47.jpg

一通りの作業が完了したら下記の手順で作業をしていきます。

  1. Active Directoryの構築
  2. ADサーバのグループとユーザーの作成
  3. SSL証明書の準備
  4. Active Directory Federation Servicesの設定

Active Directoryの構築

AD環境を準備します。

新しいフォレストを作成し、ルートドメイン名を入力します

スクリーンショット 2016-06-30 17.57.16.png

デフォルト値のままでパスワードを指定します

今回使用したパスワード:adadmin123!

スクリーンショット 2016-06-30 17.59.59.png

以後は全てデフォルト値のままで次へを選択

スクリーンショット 2016-06-30 18.03.28.png

上記画面まで遷移したら「インストール」します

再起動すればADサーバの構築は完了です。

グループとユーザーの作成

Active Directory上にユーザーと、ユーザーが所属するグループを作成します。
マネジメントコンソールへのログインは、このユーザーのログイン情報を元に今後行います。

Active Directory ユーザーとコンピュータを起動

スクリーンショット_2016-06-30_18_15_58.jpg

今回はOU:AWSを作成してその中にユーザーを追加しました。これは、後で作ったものを表示する際に見やすくするためにしています。

Usersの中にそのままユーザーを作成しても問題ありません。

ユーザーAdminを作成します

スクリーンショット 2016-06-30 18.20.26.png

スクリーンショット 2016-06-30 18.21.08.png

今回使用したパスワード awsPass123!

後の手順でメールAD情報のメールアドレスを使用するため設定しておきます

スクリーンショット 2016-07-01 16.31.41.png

続けてグループを作成します

スクリーンショット 2016-06-30 18.33.31.png

ここでのグループ名の名づけ方には注意が必要です。後のADFSの設定で、このグループ名とAWS側のロールの名前を紐付ける必要があります。
今回後に設定する書式ではアカウント番号12桁-ロール名 となります。

従って、個々では上記の様に名付けてください。

無論、蘭子アカウントなのでこの番号になっていますが、ここは個々人の環境により異なります。

このようになっていれば完了です

スクリーンショット 2016-06-30 18.37.23.png

Adminを作成したグループに追加します

スクリーンショット_2016-07-01_16_30_22.jpg

SSL証明書の準備

ADFSを用いたSSOの実装にはHTTPS通信を使います。
よって、サーバにSSL証明書をインストールする必要があります。

自身で認証局の証明書を持っている方はその証明書をインストールし、使用してください。
ここでは、所謂オレオレ証明書(自己署名の証明書)を使用する手順を紹介します。

IISの管理画面を出します

スクリーンショット_2016-06-30_18_40_22.jpg

サーバー証明書を選択

スクリーンショット_2016-06-30_18_41_53.jpg

自己署名入り証明書の作成を選択

スクリーンショット_2016-06-30_18_43_54.jpg

ADFSの構築

Active Directory Federation Servicesの設定をします。

サーバーマネージャーから飛びます

スクリーンショット 2016-06-30 18.48.58.png

デフォルト値のまま進めます

スクリーンショット 2016-06-30 18.50.12.png

そのまま進み、証明書の選択へ

スクリーンショット 2016-06-30 18.50.57.png

ここで、先ほどインストールした証明書を選択します。
フェデレーションサービスの表示名は、SSOで認証するときにページに表示されるだけなのでお好きな文字列を入れてください。

PowerShellを使用します

スクリーンショット 2016-06-30 18.55.06.png

ホップアップに記載されているように、PowerShellコマンドを打ち込まないと上の選択が出来ないため、PowerShellで下記コマンドを入力します

コマンド
Add-KdsRootKey -EffectiveTime(get-Date).AddHours(-10)

スクリーンショット 2016-06-30 19.00.46.png

adfsadmin を作成しました。

移後はそのまま画面を進め「構成」します。

[アカウント蘭子] IdPの作成

メタデータのXMLを取得します。

Windowsサーバー上から取得しても良いのですが、後ほどhostsに登録するので下記のように
クライアントのhostsに追記します

IPAddressは各環境のインスタンスのGIPで置き換えてください

/etc/hosts
00.000.00.00    ad01.adfs-sso.local

クライアントから下記URLに接続します。
環境の名称等を変更している方はad01.adfs-sso.localの部分を適時自身の環境に合わせてください。

今まで一言も触れてきませんでしたが、SGでHTTPSを許可しないと接続できません。

url
https://ad01.adfs-sso.local/FederationMetadata/2007-06/FederationMetadata.xml

オレオレ証明なので警告は出てきますがアクセスします

スクリーンショット 2016-07-01 16.03.39.png

接続するとXMLファイルが落ちてきます。このファイルは次の手順で使用します。

AWS上にIdPを作成します。

コンソール上のIAMに IDプロバイダ というものがあるのでそちらを選択します

作成を押下してSAML選びます

スクリーンショット 2016-07-01 11.04.18.png

先ほど取得したXMLを選択して作成します。

作成したプロバイダのARNを控えておきます。後ので順で使用します。

スクリーンショット_2016-07-01_16_07_45.jpg

ここからが今回の設定で一番重要です

Windowsサーバに戻って作業します。作成したAD上のグループとAWSのIAMグループのひも付け等を行います。

スクリーンショット 2016-06-30 19.46.52.png

スクリーンショット 2016-06-30 19.47.32.png

スクリーンショット 2016-06-30 19.48.17.png

URL
https://signin.aws.amazon.com/static/saml-metadata.xml

デフォルトのまま最後まで確定します。

スクリーンショット_2016-07-01_10_22_30.jpg

スクリーンショット 2016-06-30 19.50.22.png

この変換のルールをこれから4つ作成します。
この辺は下記の参考にもまとめましたが詳細は以下の記事を参考にしてください。
ここでは、今回やるための設定のみを紹介します。

Active Directory資産を活用したAWS Management ConsoleへのSSO
ADFS利用による複数AWSアカウントへのSSO
ADFS 3.0を使ってActive DirectoryのアカウントでAWSにログインする

【1つ目】WindowsID -> 名前ID (入力方向の要求を変換)

スクリーンショット 2016-07-01 10.31.56.png

【2つ目】E-mail Address (LDAP属性を要求として送信)

スクリーンショット 2016-07-01 10.47.58.png

Emailの値
https://aws.amazon.com/SAML/Attributes/RoleSessionName

【3つ目】ADのグループ名取得 (カスタム規則を使用して要求を送信)

スクリーンショット 2016-07-01 10.51.50.png

入力値
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

【4つ目】AWSのIAMロール名取得 (カスタム規則を使用して要求を送信)

スクリーンショット 2016-07-01 16.13.39.png

入力値
c:[Type == "http://temp/variable", Value =~ "(?i)^アカウント番号-"]
 => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "アカウント番号-", "ここに先ほど控えたプロバイダのARNを入力する,arn:aws:iam::アカウント番号:role/ADFS-"));

プロバイダのARNは自身の環境のものに置き換えてください。

いま最後に作成した4つ目のルールをログインしたいアカウントの数だけ増やしていくことでSSOでログインするアカウントを増やしていけます。

[アカウント蘭子] IAMロールの作成

先ほど作成したADFSのルールに対応するIAMロールを作成します。
4つ目のルールで使用した入力値で、AWSのロールの頭が ADFS- で始まるものをマッチングさせると記述しました。
従って、AWS上で作成するIAMロールは ADFS-XXXX というネーミングに従う必要があります。

ADFS-Admin
という名前でAdministratorの権限を持つロールを1つ
ADFS-ReadOnly

という名前でSecurityAuditの権限を持つロールを1つ
合計2つのロールを作成しましょう

注意するところは下の2箇所です

スクリーンショット_2016-07-01_16_21_03.jpg

スクリーンショット_2016-07-01_16_21_23.jpg

[アカウント蘭子] 認証のテスト

以上でアカウント蘭子に対してのSSOの設定が完了しました。
では実際にアクセスしてテストしてみましょう。

url
https://ad01.adfs-sso.local/adfs/ls/IdpInitiatedSignOn.aspx

ADサーバで作成したユーザのメールアドレスとパスワードでログインします

手順にそって作成していれば

ユーザー名 admin@adfs-sso.local
パスワード awsPass123!

でログインができます

スクリーンショット_2016-07-01_16_33_36.jpg

画面のように、作成したロール権限を選択してログインが可能です。
読み取りのみ可能、管理者権限があるの2種類でログインが出来ることを確認してください。

ATODEKESUは私の都合上付いているだけなので気にしないでください。

[アカウント蘭子] Windowsインスタンス上での作業

2つ目のアカウントを追加しましょう。
といっても、一度やっている事を再度やり直すだけです。

[Active Directory] グループの追加

ADサーバ上でグループを2つ作成し、Adminユーザーを追加しましょう

グループ名
098765432109-Admin
098765432109-ReadOnly

[ADFS] 設定の追加

IdPの作成

先ほどの手順と同様にプロバイダを作成し、ARNを控えておきます

ルールの追加

Windowsサーバ上で 4つ目】AWSのIAMロール名取得 (カスタム規則を使用して要求を送信) を行います。
ARNの値は幸子アカウントのものを使用します

IAMロールの作成

蘭子アカウントと同じ手順で同じものを作成します。

[アカウント幸子] 認証のテスト

もう一度ログインして、蘭子アカウント、幸子アカウントの両方でログイン出来るかを確認します。

まとめ

かなり長くなってしまいましたが、AWS環境でのSSOを構築することができました。
IAMユーザーは増えてくると管理が面倒なのでADサーバに寄せる事ができるのは良いことだと思います。

参考

クラメソさんマジクラメソさん
Active Directory資産を活用したAWS Management ConsoleへのSSO
ADFS利用による複数AWSアカウントへのSSO
ADFS 3.0を使ってActive DirectoryのアカウントでAWSにログインする

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした