LoginSignup
5
0
BeeXAdvent Calendar 2023Day 24beex-inc
@handy-dd18(半田 大樹)in株式会社BeeX

AWS IAM Identity CenterとMicrosoft Entra IDを統合させてみる

Last updated at Posted at 2023-12-23

この記事はBeeX Advent Calendar 2023の24日目の記事です。
※AWSアップデートのことについて書こうとしてましたが、思ったよりも検証に時間がかかりそうだったので急遽ネタ変更しました。

はじめに

タイトル通り、AWS IAM Identity CenterとMicrosoft Entra IDを統合させてみましたので、記録として残しておきます。

手順としては以下を参考にしました。

尚、検証用のEntra IDは以下の方法で準備しました。

作業内容

前提条件

ドキュメントには以下の2つが前提条件として記載されていました。

  • Microsoft Entra サブスクリプション。
  • AWS IAM Identity Center が有効なサブスクリプション。

今回はどちらも事前に準備済みでしたので、説明は省略します。

Microsoft側作業

Microsoft Entra ID側でアプリケーションを追加する

Entra IDとIdentity Centerを統合するには、Entra ID側でエンタープライズアプリケーションを追加する必要があります。

Entra IDのポータルから「エンタープライズアプリケーション」を選択します。
image.png

「新しいアプリケーション」画面で"AWS IAM Identity Center"を検索し、出てきたアプリを選択します。
image.png

以下のような画面が表示されるので、何も変更せずに作成ボタンを押下します。
image.png

少し待つとアプリが追加されました。
image.png

Microsoft Entra SSOを有効にする

同じ画面の左ペインからシングルアサインオンを選択し、表示されたシングルサインオン方式からSAMLを選択します。
image.png

セットアップ画面に遷移するので、基本的なSAML構成の編集ボタンを押下します。
image.png

ここではSAML構成を設定します。必須となっている識別子と応答URLの2つを追加する必要があります。
具体的なその2つの設定値は、本記事下部の「AWS IAM Identity CenterのSSOを有効にする」の手順で確認してください。
image.png

以下のように設定して、Entra ID側の設定ができたら左上の保存ボタンを押下します。
image.png

あまりよくわかっていないですが、アプリケーションを構成する時は「IDP Initiatedモード」と「 SP開始モード」の2種類があり、「SP開始モード」で構成したい場合はサインオンURLに以下の形式でURLを設定する必要があるようです。

  • [https://portal.sso..amazonaws.com/saml/assertion/]

image.png

以下を見た限りだと、「IDP Initiatedモード」だとAzure ADのサインイン画面、「SP開始モード」だとAWSのサインイン画面が表示されるようです。
どちらの認証情報でログインするかによって選択する感じでしょうか。
今回はMicrosoft Entra IDの認証情報でサインインしたいので、「IDP Initiatedモード」で設定してみます。

「SAML証明書」設定内の「証明書（Base64）」と「フェデレーション メタデータXML」をダウンロードします。
image.png

「AWS IAM Identity Center (successor to AWS Single Sign-On) のセットアップ」設定内のURLや識別子をコピーしておきます。
image.png

ここまでできたらAWS側の設定に移ります

AWS側作業

AWS IAM Identity CenterのSSOを有効にする

個人所有のAWSアカウントでIdentity Centerを有効化しているので、Identity Center画面の設定から「アイデンティティソースを変更」を押下します。
image.png

外部IDプロバイダーを選択します。
image.png

サービスプロバイダーのメタデータが表示されるので、この値をMicrosoft Entra ID側で設定します。
image.png

「アイデンティティプロバイダーのメタデータ」設定では、Microsoft側の手順でダウンロードした2つのファイルをそれぞれ選択します。
image.png

確認画面が表示されるので、問題なければ"承諾"を入力し、ボタンを押下します。
image.png
image.png

アイデンティティソースや認証方法が変更されていることが確認できました。
image.png

テストユーザー作成

ここまでできたらSSO設定が双方できたので、テスト用のユーザーを作成して試してみます。

Entra ID側作業

Entra IDのユーザー画面から新しいユーザーを作成します。
image.png
image.png

作成したユーザーをEntra IDの「AWS IAM Identity Center」アプリケーション側でユーザーの割り当てを行います。
image.png

作成したテストユーザーを選択して割り当てします。ロールは既定のままにします。
image.png

無事割り当てできました。
image.png

AWS側作業

AWS側でも同じようにテストユーザーを作成します。
image.png

プライマリ情報を入力します。ユーザー名とEメールアドレスはMicrosoft側で作成したテストユーザーと一致させます。
※後述していますが、ユーザー名を「testuser」にするとうまくいかなかったため、Entra IDのユーザープリンシパル名である「testuser@xxxxxxxx.onmicrosoft.com」を設定してみてください。
※もしくは自動でEntra ID割り当てユーザー→Identity Centerユーザーにプロビジョニングしたい時は、本作業とテスト実行(1回目)の作業をスキップして、その次のトラブルシュート作業の自動プロビジョニング設定の手順に移ってください。
image.png

AWSユーザー側の権限は事前に作成したグループに追加することで割り当てます。
image.png

ユーザーが作成できました。
image.png

テスト実行(1回目)

SSO構成の構築とテストユーザーの作成・割り当てができたので、Microsoft側からテストを実施してみます。
作成したテストユーザーを使用して、Azureポータルにログインします。
image.png

Entra IDのエンタープライズアプリケーションから「AWS IAM Identity Center」アプリケーションを表示し、シングルサインオン画面下部にテストボタンがあるので、これを押下してみます。
image.png

以下の画面が表示されるので、「サインインのテスト」を押下します。
image.png

認証情報を聞かれるので、必要な情報を入力してログインしてみます。
image.png

「このコードは使用できません。もう一度試してください。」というエラーが発生しました。
image.png

トラブルシュート

プロビジョニングログを見ているとtestuserの作成でエラーが出ていることがわかりました。
image.png

色々調べてみたところ、Entra ID側で作成したユーザーとIdentity Center側で作成したユーザーがうまくマッピングされていないことが原因じゃないかと思いました。
そのため、手動設定ではなくなってしまいますが、手動作成したIdentity Center側のユーザーを全て削除し、Entra ID→Identity Centerに自動プロビジョニングする設定を追加で行いました。
image.png

以下の記事を参考にプロビジョニングを有効にしました。

自動プロビジョニングを有効化し、Entra IDの「AWS IAM Identity Center」アプリケーション側から"プロビジョニングの再開"を押下しました。(必要かどうかはあまりわかってないです)
しばらく待つとプロビジョニングが成功しました。
image.png

よく見たら「プロビジョニング間隔(固定)：40分」と表示されていたので、"プロビジョニングの再開"を押下しなくても反映されたのかもしれません。
image.png

AWS IAM Identity Center側にも無事反映されていました。
image.png

テスト実行(2回目)

もう一度Entra IDのシングルサインオン画面からテストを実行すると、今度はエラーが出ずにAWS画面にアクセスできました。(権限設定はまだしていないので、ログイン先のAWSアカウントは何も表示されていません)
image.png

権限を割り当てるために、Identity CenterのコンソールのAWSアカウントメニューから、割り当てするAWSアカウントを選択し、「ユーザーまたはグループを割り当て」ボタンを押下します。
image.png

権限を割り当てる対象と許可セットを選択し、設定します。
image.png

もう一度テストを実行すると、今度は許可したAWSアカウントが表示されていることを確認できました。
image.png

AWS アクセスポータルの URLからログイン

最後にIdentity Center画面の「AWS アクセスポータルのURL」からアクセスしたときに想定通り認証が行われるか確認します。

Identity Center画面のURLはawsドメインですが、ブラウザからアクセスするとMicrosoftドメインのURLにリダイレクトされました。
image.png

認証情報を入力して、AWSアクセスポータルが表示されることも確認しました。
image.png

追記

後で気づきましたが、ドキュメントを見返すと以下の記載があったことに気が付きました。

AWS IAM Identity Center に入力したユーザー名が、ユーザーの Microsoft Entra サインイン名と一致していることを確認します。 これにより、認証の問題を回避することができます。

自動プロビジョニングした後のIdentity Center側のユーザー名を見ると「testuser@xxxxxxxx.onmicrosoft.com」となっておりました。
ドキュメント内の手順では「testuser」で良いと記載されていましたが、もしかしたら「testuser@xxxxxxxx.onmicrosoft.com」という名前でユーザーを作成しておけば自動プロビジョニングにしなくてもうまくいったのかもしれません。

おわりに

設定できることは知っていましたが、やったことはなかったので試してみました。
また、自分が確認した限りはGoogle等を検索したときに出てくる統合検証記事は名前が変わる前(AzureAD)のものがほとんどで、名前が変わって(Entra ID)からの記事はなかったので、供給する意味合いでも書いてみました。

この記事がどなたかの参考になれば幸いです。

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
0