先日 Entra ID と AWS IAM Identity Center を SAML 連携し、Entra ID の資格情報で AWS にシングルサインオンする検証をしましたが、同じ環境でさらに自動プロビジョニングを構成しました！
現在の構成は以下です：
| - | 構成 |
|---|---|
| IdP (Identity Provider) | Microsoft Entra ID |
| SP (Service Provider) | AWS IAM Identity Center |
| ユーザープロビジョニング | 自動 |
| SSO 認証方式 | SP-initiated SSO |
備忘録を兼ねて、検証で確認できた動作を俯瞰的に本記事にまとめます。
以前公開した記事に引き続き、本記事が「ちょうど AWS IAM Identity Center の連携例を探していた」といった方や、AWS に限らず「とりあえず自動プロビジョニングの構成例・構築例を知識として蓄えたい」といった方のご参考になれば嬉しいです！
本記事の前提環境
Entra ID と AWS IAM Identity Center が SAML 連携され、自動プロビジョニングが有効な環境にて検証しています。
-
SAML 連携の実装方法：
Entra ID 資格情報で AWS にシングルサインオン！(②検証例) -
自動プロビジョニングの実装方法：
Entra ID で AWS ユーザーを一元管理！(②実装例)
Agenda
構成
自動プロビジョニング編は 3パートシリーズです！
検証してみると奥が深く、これを記録したい！となると記事が非常に長くなってしまうことが分かりましたので、試しにパート分けをしてみました...🙏
| Part | 記事タイトル | 概要 |
|---|---|---|
| 1 | Entra ID で AWS ユーザーを一元管理！(①動作例) ★本記事！ |
SAML連携、自動プロビジョニングを有効にしてユーザーを一元管理するとは？の全体像をざっくり記事にまとめました |
| 2 | Entra ID で AWS ユーザーを一元管理！(②実装例) | AWS、Entra ID 双方で自動プロビジョニングを有効化し、属性マッピングを設定、初回プロビジョニングとサインインを見届けるまでを記事にまとめました |
| 3 | Entra ID で AWS ユーザーを一元管理！(③運用例) | ユーザー新規作成 ~ プロパティ情報更新 ~ 無効化 ~ 削除といった、ユーザーアカウント運用の一般的ライフサイクルをなぞってプロビジョニング処理結果を記事にまとめました |
本記事の目次
本記事は以下の構成です：
| # | 章題 | 概要 |
|---|---|---|
| 1 | 実装イメージ | 検証時のシステム構成を図をまじえて紹介します |
| 2 | 動作イメージ | 自動プロビジョニングの動作概要と同期対象の範囲をまとめます |
| 3 | プロビジョニング処理の例 | 実際に確認できた処理結果を、代表的な例で紹介します |
| 4 | さいごに | 本記事の振り返りと次回記事予告です |
| Appendix | 属性マッピング設定の既定値 | Entra ID にて確認した既定の属性マッピング設定を一覧で掲載します |
1. 実装イメージ
下図 (↓) は、検証時の構成を簡易にまとめてみたものです。
今回自動プロビジョニングを構成したことにより、Entra ID からユーザーとグループが AWS IAM Identity Center に同期されるようになりました。
自動プロビジョニングはまず AWS 側で有効化し、次に Entra ID にて有効化する際に AWS のテナント情報 (SCIM エンドポイントリンクとアクセストークン) を入力し連携を構成します。
自動プロビジョニングの実装方法
詳細にご興味のある方は、以下の記事もぜひご覧ください！
2. 動作イメージ
検証時に確認できた動作を、公開情報の参考リンクを添えて以下順でまとめます。
2-1. 概要
自動プロビジョニングを有効にすると、Entra ID のユーザーとグループが AWS に連携されます。
同期の方向は Entra ID から AWS IAM Identity Center への一方向となり、Entra ID がユーザーとグループの管理主体になりました。
プロビジョニング対象
同期対象範囲は、既定で Entra ID エンタープライズアプリに割り当てられたユーザーとグループです。
(エンタープライズアプリに直接割り当てられたユーザーアカウントとグループ、およびそのグループのメンバー)
なお、グループのプロビジョニングが不要な場合はオフにすることも可能です。
グループ利用時の注意事項
グループの利用には Entra ID P1 ライセンスが必要です。
また、現在仕様として、グループが階層構造になっている (ネストされている) 場合、子グループには設定が継承されません。(自動プロビジョニングされない)
プロビジョニング周期
同期 (プロビジョニング) 処理は 40分間隔で実行され、この時間間隔は固定で変更できない仕様となります。
オンデマンド プロビジョニング
Entra ID の自動プロビジョニング周期は 40分ごとで固定 (編集不可) です。
ただし、テストやトラブルシューティング時は 40分待ってられない... そんな需要に応えた「オンデマンド プロビジョニング」機能があります！
この機能を使えば、1ユーザーまたは最大5人までのグループを対象に、数秒で即時にプロビジョニングが可能です。
2-2. 属性について
- 参考：
Entra ID にて自動プロビジョニングを構成するにあたり、Entra ID - AWS 間でマッピングする属性を設定します。
プロビジョニング時、事前に構成されたこのマッピング設定をもとに Entra ID から AWS に値が反映されます。
グループとユーザーそれぞれに属性マッピング設定があります。
どの属性がどの属性に対応...?
今回 AWS IAM Identity Center との SAML 連携に際して、Entra ID にてエンタープライズアプリをギャラリーから作成していました。
ギャラリーアプリが AWS との自動プロビジョニングをサポートしており、属性マッピングが既定で構成されていました。
今回の検証では既定値をそのまま使っています。
どのような値が入っていたかは、本記事末尾の Appendix に掲載しています。ご参考までに！
3. プロビジョニング処理の例
今回検証にて確認した処理結果から、例として以下の代表的処理をピックアップしてまとめます！
- 3-1. グループが新規作成される例
- 3-2. グループが更新される例
- 3-3. ユーザーが新規作成される例
- 3-4. ユーザーが更新される例
ユーザー運用シナリオにおけるプロビジョニング動作まとめ
さらに無効化・削除といったアカウント状態の変更も含め、実際のユーザー運用でよくありそう (主観) なシナリオをいくつか選んで動作確認しました！
Entra ID 側のアカウント操作を起点にログも含めて、各動作をこちら↓の記事にまとめています。
詳細にご興味のある方は、以下の記事もぜひご覧ください！
3-1. グループが新規作成される例
- 前提状態：プロビジョニング対象のグループと一致するグループが AWS 側に存在していない
- プロビジョニング処理後：グループが作成され、メンバー情報も反映される！
3-2. グループが更新される例
-
前提状態：
- Entra ID にて、プロビジョニング対象のグループのメンバー構成に変更が発生する
- AWS にて、プロビジョニング対象のグループと一致するグループが検出される
- プロビジョニング処理後：AWS にて、当該グループのメンバー情報が更新される！
3-3. ユーザーが新規作成される例
- 前提状態：プロビジョニング対象のユーザーと一致するユーザーが AWS 側に存在していない
- プロビジョニング処理後：ユーザーが作成され、プロパティ情報も反映される！
3-4. ユーザーが更新される例
-
前提状態：
- Entra ID にて、プロビジョニング対象のユーザーのプロパティに変更が発生する
- AWS にて、プロビジョニング対象のユーザーと一致するユーザーが検出される
- プロビジョニング処理後：AWS にて、当該ユーザーのプロパティ情報が更新される！
4. さいごに
以上、Entra ID と AWS IAM Identity Center 間で自動プロビジョニングを構成すると実現できることを、動作の観点からまとめてみました。
前回検証時は既定の手動プロビジョニング状態だったため、Entra ID と AWS 双方でユーザーを作成・管理する必要がありました。
手動プロビジョニングモードの検証記録
自動プロビジョニング構成前の、既定の手動プロビジョニング状態で検証した様子は以下ご参考ください！
自動プロビジョニングを構成すると Entra ID に管理が集約化されるため、まず AWS 側でユーザー作成が不要になります。
ユーザーのみならずグループもプロビジョニング可能なほか、操作も新規作成のみならず更新や無効化・削除といったアカウント状態の連携も可能という検証結果になりました。
シングルサインオンの実現と合わせて自動プロビジョニングも構成することで、一気に管理者側のメリットも感じられるようになりました。
ステップ バイ ステップでの自動プロビジョニングの構成方法 (Part 2 へ) や、
本記事では掲載しきれなかったユーザーアカウント無効化・削除まで含めた動作検証例 (Part 3 へ) については、姉妹記事にまとめます。
引き続き、Entra ID × AWS IAM Identity Center の連携に興味のある方はぜひご覧ください！
Next...
-
自動プロビジョニングの構成方法：
Entra ID で AWS ユーザーを一元管理！(②実装例) -
ユーザー運用シナリオにおける動作検証例：
Entra ID で AWS ユーザーを一元管理！(③運用例)
Appendix：属性マッピング設定の既定値
2025年8月検証時点に Entra ID にて確認した既定の属性マッピング設定をご参考に掲載します。
グループ属性マッピング設定
| # | AWSSingleSignon 属性 | Microsoft Entra ID 属性 | 照合の優先順位 | 削除可否 |
|---|---|---|---|---|
| 1 | displayName | displayName | 1 | 不可 |
| 2 | members | members | 可 | |
| 3 | externalId | objectId | 不可 |
ユーザー属性マッピング設定
| # | AWSSingleSignon 属性 | Microsoft Entra ID 属性 | 照合の優先順位 | 削除可否 |
|---|---|---|---|---|
| 1 | userName | userPrincipalName | 1 | 不可 |
| 2 | urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager | manager | 可 | |
| 3 | active | Not([IsSoftDeleted]) | 不可 | |
| 4 | displayName | displayName | 不可 | |
| 5 | title | jobTitle | 可 | |
| 6 | emails[type eq "work"].value | 可 | ||
| 7 | preferredLanguage | preferredLanguage | 可 | |
| 8 | name.givenName | givenName | 不可 | |
| 9 | name.familyName | surname | 不可 | |
| 10 | addresses[type eq "work"].formatted | physicalDeliveryOfficeName | 可 | |
| 11 | addresses[type eq "work"].streetAddress | streetAddress | 可 | |
| 12 | addresses[type eq "work"].locality | city | 可 | |
| 13 | addresses[type eq "work"].region | state | 可 | |
| 14 | addresses[type eq "work"].postalCode | postalCode | 可 | |
| 15 | addresses[type eq "work"].country | country | 可 | |
| 16 | phoneNumbers[type eq "work"].value | telephoneNumber | 可 | |
| 17 | externalId | objectId | 不可 | |
| 18 | urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber | employeeId | 可 | |
| 19 | urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department | department | 可 | |
| 20 | name.formatted | Join(" ", [givenName], [surname]) | 可 |