LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@shokolateinNTTデータ先端技術

Entra ID で AWS ユーザーを一元管理！(③運用例)

Last updated at Posted at 2025-09-24

先日 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 連携され、自動プロビジョニングが有効な環境にて検証しています。

Agenda

構成

自動プロビジョニング編は 3パートシリーズです！

検証してみると奥が深く、これを記録したい！となると記事が非常に長くなってしまうことが分かりましたので、試しにパート分けをしてみました...🙏

Part 記事タイトル 概要
1 Entra ID で AWS ユーザーを一元管理！(①動作例) SAML連携、自動プロビジョニングを有効にしてユーザーを一元管理するとは？の全体像をざっくり記事にまとめました
2 Entra ID で AWS ユーザーを一元管理！(②実装例) AWS、Entra ID 双方で自動プロビジョニングを有効化し、属性マッピングを設定、初回プロビジョニングとサインインを見届けるまでを記事にまとめました
3 Entra ID で AWS ユーザーを一元管理！(③運用例)
★本記事！		 ユーザー新規作成 ~ プロパティ情報更新 ~ 無効化 ~ 削除といった、ユーザーアカウント運用の一般的ライフサイクルをなぞってプロビジョニング処理結果を記事にまとめました

本記事の目次

本記事は以下の構成です：

# 章題 概要
1 実装イメージ 検証時のシステム構成を図をまじえて紹介します
2 ユーザー運用動作確認 ユーザーアカウントのライフサイクルに沿って、各操作のプロビジョニング動作を確認します
3 さいごに 検証の振り返りとシリーズ記事のまとめです
4 参考 検証にあたって参考にさせていただいた神記事たち

長めの記事になってしまったので、適宜飛ばし読みしていただければと思います🚀
PC で開いていただけると Qiita 標準機能の目次が常に表示されますので、ご活用ください！

1. 実装イメージ

下図 (↓) は、検証時の構成を簡易にまとめてみたものです。

実装イメージ(Chris版).png

今回自動プロビジョニングを構成したことにより、Entra ID からユーザーとグループが AWS IAM Identity Center に同期 (作成 / 更新 / 無効化・削除) されるようになりました。

同期の方向は Entra ID から AWS IAM Identity Center への一方向となり、Entra ID がユーザーとグループの管理主体となります。

同期対象範囲は、Entra ID エンタープライズアプリ に割り当てられたユーザーとグループです (既定)。
同期 (プロビジョニング) 処理は 40分間隔で実行され、この時間間隔は固定で編集不可の仕様となります。

2. ユーザー運用動作確認

自動プロビジョニングを構成しユーザー管理を Entra ID に一元化したところで、一般的 (主観) 運用項目における動作を確認してみました。

検証時は複数アカウントを使って試行錯誤したのですが、あらためて運用ライフサイクルを意識して整理しなおすと、以下の表のようになりました。

表記載の補足

  • 「実施したこと (Entra ID)」列：Entra ID 側で実施したユーザー管理操作
  • 「プロビジョニング結果 (AWS)」列：プロビジョニングログおよび AWS 側で確認できたプロビジョニング処理結果
  • 「操作カテゴリ」列：Entra ID プロビジョニングログの「操作」列の値をもとに、プロビジョニング操作をカテゴライズ
# 概要 実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
2-1. ユーザー新規作成 ユーザーを新規作成し、プロビジョニング対象グループに追加する ユーザーが新規作成される 作成
(Create)
2-2. 既存ユーザー追加（未登録） 既存ユーザーをグループに追加する ユーザーが新規作成される
(※AWS 上にすでに存在していなかったユーザー)		 作成
(Create)
2-3. 既存ユーザー追加（登録済） 既存ユーザーをグループに追加する ユーザープロパティ情報が更新される
(※AWS 上にすでに存在していたがプロパティ情報に差異のあったユーザー)		 更新
(Update)
2-4. ユーザー属性更新 ユーザーのプロパティを更新し、値を追加する ユーザープロパティ情報が更新される 更新
(Update)
2-5. アカウント無効化 ユーザーアカウントを無効化する ユーザー状態が Enabled → Disabled に更新される 無効化
(Disable)
2-6. サインインブロック ユーザーアカウントの「サインインをブロック」する ユーザー状態が Enabled → Disabled に更新される 無効化
(Disable)
2-7. グループメンバー除外 ユーザーをグループメンバーから外す ユーザー状態が Enabled → Disabled に更新される 無効化
(Disable)
2-8. 論理削除（soft-delete） ユーザーアカウントを削除（論理削除）する ユーザー状態が Enabled → Disabled に更新される 無効化
(Disable)
2-9. アカウント有効化 無効状態のユーザーアカウントを有効化する ユーザー状態が Disabled → Enabled に更新される 更新
(Update)
2-10. アカウント復元 論理削除状態のユーザーアカウントを復元する ユーザー状態が Disabled → Enabled に更新される 更新
(Update)
2-11. 完全削除 論理削除状態のユーザーアカウントを完全削除する ユーザーが削除される 削除
(Delete)

本表は運用ライフサイクルにそってナンバリングしているため、検証時系列とは一致しません。

以降、確認したことを簡易にまとめます。

2-1. ユーザー新規作成

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
ユーザーを新規作成し、プロビジョニング対象グループに追加する ユーザーが新規作成される 作成 (Create)
対象ユーザー
Rick Roe (RickRoe@domain.com)
2-1. 動作確認例 (左端の ▶ をクリックして展開)

ご参考までに、Entra ID 側でユーザー新規作成＆グループメンバー追加実施前の AWS 側の状態は以下でした：
画像_2-1_before1.png
画像_2-1_before2.png

[Entra ID] ユーザー操作実施

Entra ID 側でユーザーを新規に作成し、自動プロビジョニング対象であるグループ「AWS Users」のメンバーに追加しました。

  • ユーザー新規作成
    画像_2-1_1.png

  • グループメンバー追加
    画像_2-1_2.png

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-1_3.png
画像_2-1_4.png
画像_2-1_5.png
画像_2-1_6.png
画像_2-1_7.png

[AWS] 結果：ユーザー状態確認

結果、AWS 側で当該ユーザーが新規作成されました。
ちなみに、グループのメンバーとしても追加されています。

画像_2-1_8.png
画像_2-1_9.png
画像_2-1_10.png

2-2. 既存ユーザー追加（未登録）

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
既存ユーザーをグループに追加する ユーザーが新規作成される
(※AWS 上にすでに存在していなかったユーザー)		 作成 (Create)

Entra ID に既存のユーザーも新規のユーザーも、これまでプロビジョニング対象でなく AWS 上に存在していないユーザーなのであれば、対象追加後の自動プロビジョニング処理の結果 AWS 側に新規でユーザー作成されるという処理結果は同じになりました。

プロビジョニング処理結果が [2-1. ユーザー新規作成] と同じため、写真掲載は割愛します。
プロビジョニングログは [2-1. ユーザー新規作成] をご参考ください！

2-3. 既存ユーザー追加（登録済）

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
既存ユーザーをグループに追加する ユーザープロパティ情報が更新される
(※AWS 上にすでに存在していたがプロパティ情報に差異のあったユーザー)		 更新 (Update)
対象ユーザー
Nikki Wolf (NikkiWolf@domain.com)

検証時系列
[2-1. ユーザー新規作成] よりも前に実施しました。

2-3. 動作確認例 (左端の ▶ をクリックして展開)

ご参考までに、Entra ID 側操作実施前からすでに AWS 側には当該ユーザーがすでに存在している状態でした：
画像_2-3_1.png
画像_2-1_2.png

[Entra ID] ユーザー操作実施

Entra ID と AWS 双方に既存のユーザーを見繕い、自動プロビジョニング対象のユーザーグループメンバーにしました：

画像_2-3_2.png

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-3_4.png
画像_2-6_1_Nikki-2.png
画像_2-6_1_Nikki-3.png
画像_2-3_5.png

[AWS] 結果：ユーザー状態確認

結果として、Entra ID の
userPrincipalName 属性と AWS の userName 属性がマッチしたことから同一ユーザーであると判断され、Entra ID 側ユーザー情報と AWS 側ユーザー情報が紐づきました。
Entra ID 側ユーザーの方が属性情報が多かったので、AWS 側の属性情報も更新されています。
ちなみに、グループのメンバーとしても追加されています。

画像_2-7_3.png
画像_2-7_5.png

2-4. ユーザー属性更新

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
ユーザーのプロパティを更新し、値を追加する ユーザープロパティ情報が更新される 更新 (Update)
対象ユーザー
Device Enrollment Manager 1 (00000001@domain.com)

検証時系列
[2-1. ユーザー新規作成] よりも前に実施しました。

2-4. 動作確認例 (左端の ▶ をクリックして展開)

[2-3. 既存ユーザー追加（登録済）] と似たケースですが、属性値の更新にフォーカスして検証しました。
AWS 側にすでにユーザーが存在しているが、属性値が Entra ID と AWS で異なる、特に属性の値が空だったり (姓名、従業員ID) 同属性で値が異なったり (表示名) する場合にどう更新されるかを確認しました。

ご参考：プロビジョニング前の属性値

属性 Entra ID 上の値 AWS IAM Identity Center　上の値
UPN (Username) 00000001@domain.com 00000001@domain.com
メールアドレス (Email) dem1@domain.com dem@domain.com
名 (First name) (空値) DEM Test
姓 (Last name) (空値) User 1
表示名 (Display name) Device Enrollment Manager 1 DEM Test User 1
従業員ID (Employee number) 00000001 (空値)

ご参考までに、プロビジョニング処理前の AWS ユーザー状態を写真でも掲載します：
画像_2-4_1.png
画像_2-4_2.png

[Entra ID] ユーザー操作実施

当該ユーザーのEntra ID 側プロパティは以下の状態に設定していました：
画像_2-4_3.png

プロビジョニング対象グループのメンバーです：
画像_2-4_4.png

[Entra ID] プロビジョニングログ確認

今回のプロビジョニング処理結果ログは以下でした：

画像_2-4_5.png
画像_2-4_6.png
画像_2-4_7.png
画像_2-4_8.png

変更されたプロパティ
初回サイクルのため、[変更されたプロパティ] タブのプロパティ一覧に「externalId」がリストされました。

増分サイクル時に既存ユーザーの属性変更がある場合を別途検証した際、「externalId」はリストされませんでした。
明示的に変更のある属性のみがリストされています。

image.png
(東京タワーの住所を借りました：Example Address in Japan)

画像_2-4_9.png

[AWS] 結果：ユーザー状態確認

以下の結果になりました！

ご参考：プロビジョニング後の属性値

属性 Entra ID 上の値 AWS IAM Identity Center　上の値
UPN (Username) 00000001@domain.com 00000001@domain.com
メールアドレス (Email) dem1@domain.com dem@domain.com
名 (First name) (空値) DEM Test
※変化無し (Entra側が空値の場合は上書きされない)
姓 (Last name) (空値) User 1
※変化無し (同上)
表示名 (Display name) Device Enrollment Manager 1 Device Enrollment Manager 1
※Entra側の値で上書きされる
従業員ID (Employee number) 00000001 00000001
※Entra側の値で上書きされる

画像_2-4_10.png

2-5. アカウント無効化

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
ユーザーアカウントを無効化する ユーザー状態が Enabled → Disabled に更新される 無効化 (Disable)
対象ユーザー
Nikki Wolf (NikkiWolf@domain.com)
2-5. 動作確認例 (左端の ▶ をクリックして展開)

ご参考までに、Entra ID 側でユーザーアカウントを無効化する前の AWS 側の状態は以下でした：
画像_2-5_1.png

操作対象ユーザーである「Nikki」アカウントの Status は Enabled 状態です。

[Entra ID] ユーザー操作実施

Entra ID 側でユーザーアカウントを無効化しました。
(ユーザーのプロパティ画面から「アカウントが有効化されました」の値を設定変更)

  • Entra 管理センターにて対象ユーザーの「概要」(プロパティ) 画面を開き、画面上部の「プロパティの編集」をクリック
    画像_2-5_2.png

  • 「アカウントが有効化されました」のチェックボックスをオフにし、「保存」をクリック
    画像_2-5_3.png

  • Entra 管理センター上部に「ユーザーの更新成功」通知が表示されると、完了です

    ユーザーの更新成功
    ユーザー {UPN} のプロパティが正常に更新されました。

    画像_2-5_4.png

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-5_5.png
画像_2-5_6.png
画像_2-5_7.png
画像_2-5_8.png
画像_2-5_9.png

[AWS] 結果：ユーザー状態確認

結果、AWS 側で当該ユーザーが無効化されました (Status が Enabled から Disabled に！)。

画像_2-5_10.png
画像_2-5_11.png

2-6. サインインブロック

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
ユーザーアカウントの「サインインをブロック」する ユーザー状態が Enabled → Disabled に更新される 無効化 (Disable)
対象ユーザー
Nikki Wolf (NikkiWolf@domain.com)

検証時系列
[2-9. アカウント有効化] の後に実施しました。

(「Nikki」ユーザーを使った検証の時系列： [2-5. アカウント無効化] → [2-9. アカウント有効化] → [2-6. サインインブロック])

2-6. 動作確認例 (左端の ▶ をクリックして展開)

[Entra ID] ユーザー操作実施

Microsoft 365 管理センターを開き、ユーザーの「サインインをブロック」しました。

  • Microsoft 365 管理センター (admin.microsoft.com1)> ユーザー 一覧より対象ユーザーを選択し、「サインインをブロック」をクリック
    画像_2-6_1.png

  • 「このユーザーによるサインインをブロックする」チェックボックスをオンにし、「変更の保存」をクリック
    画像_2-6_2.png

-「{ユーザー表示名}によるサインインがブロックされました～」メッセージが表示されると、完了です

{ユーザー表示名}によるサインインがブロックされました。このユーザーは、Microsoft のすべてのサービスから 60分以内に自動的にサインアウトされます。

画像_2-6_3.png

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-6_4.png
画像_2-6_5.png
画像_2-6_6.png
画像_2-6_7.png
画像_2-6_8.png

[AWS] 結果：ユーザー状態確認

結果、AWS 側で当該ユーザーが無効化されました (Status が Enabled から Disabled に！)。
画像_2-6_9.png
画像_2-6_10.png

Entra ID 側でサインインをブロックした場合も、AccountEnabled プロパティが False であると判断されることが分かりました。

2-7. グループメンバー除外

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
ユーザーをグループメンバーから外す ユーザー状態が Enabled → Disabled に更新される 無効化
(Disable)
対象ユーザー
Rick Roe (RickRoe@domain.com)
2-7. 動作確認例 (左端の ▶ をクリックして展開)

ご参考までに、Entra ID 側で当該ユーザーをプロビジョニング対象グループのメンバーから除外する前の AWS 側の状態は以下でした：
画像_2-1_8.png
画像_2-1_10.png

アカウントは有効、かつ「AWS Users」グループのメンバーです。

[Entra ID] ユーザー操作実施

Entra ID 側で当該ユーザーをプロビジョニング対象グループのメンバーから除外しました。

  • Entra 管理センターにて、すべてのユーザー > 当該ユーザーを選択、グループ一覧よりプロビジョニング対象グループを選択して「メンバーシップの削除」>「OK」をクリック
    画像_2-7_1.png

  • 「グループメンバーシップが正常に削除～」通知が表示されると、完了です

    グループ メンバーシップが正常に削除された
    メンバーシップが {グループ名} から削除されました。最近加えられた変更が表示されるまでに時間がかかる場合があります。

    画像_2-7_2.png

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-7_3.png
画像_2-7_4.png
画像_2-7_5.png
画像_2-7_6.png
画像_2-7_7.png

ご参考までに、グループメンバーの更新処理もプロビジョニングログとして記録されています。
画像_2-7_8.png
画像_2-7_9.png
画像_2-7_10.png
画像_2-7_11.png
画像_2-7_12.png

[AWS] 結果：ユーザー状態確認

結果として、AWS 側で当該ユーザーが無効化されました (Status が Enabled から Disabled に！)。
また、AWS Users グループのメンバーから外れました。
画像_2-7_13.png
画像_2-7_14.png
画像_2-7_15.png

Entra ID 側ではアカウントは有効、サインインのブロックもされておらず Microsoft 365 はじめ各種サービスを利用可能な状態ですが、AWS 側は無効にすることができました。

とても興味深いです！

2-8. 論理削除（soft-delete）

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
ユーザーアカウントを削除（論理削除）する ユーザー状態が Enabled → Disabled に更新される 無効化 (Disable)
対象ユーザー
Rick Roe 2 (RickRoe2@domain.com)
2-8. 動作確認例 (左端の ▶ をクリックして展開)

ご参考までに、Entra ID 側でユーザーアカウントを削除 (論理削除) する以前の AWS 側の状態は以下でした：
画像_2-8_before1.png
画像_2-8_before2.png

当該ユーザーアカウントは有効 (Enabled 状態) で、AWS Users グループのメンバーです。

なお今回、Entra ID 側で AWS Users グループのメンバーシップを剥奪しないままの状態でアカウント削除を実施しました。
画像_2-8_1.png

[Entra ID] ユーザー操作実施

Entra ID 側でユーザーアカウントを削除しました。

  • Entra 管理センターにて対象ユーザーの「概要」(プロパティ) 画面を開き、画面上部の「削除」をクリック
  • 「{ユーザー表示名} の削除」メニューが開くので、さらに「削除」をクリック

画像_2-8_2.png

  • Entra 管理センター画面上部に「ユーザーの削除成功」通知が表示されると、完了です

    ユーザーの削除成功
    {ユーザー表示名} が削除されました。

画像_2-8_3.png

論理的な削除状態
Entra ID では、管理者がユーザーを削除すると 30日後にアカウントが完全削除されます。
30日の間はユーザーを復元することが可能なため、この期間の状態を完全削除と区別して「soft-deleted」状態や論理的な削除状態と呼ばれます。

ちなみに余談ですが、論理削除状態のユーザーは「削除済みのユーザー」一覧に表示されますが、UPN が自動的に変わっていました。

  • 元の UPN：RickRoe2@domain.onmicrosoft.com
  • 新しい UPN：{user objectID without "-"} RickRoe2@domain.onmicrosoft.com

画像_2-8_after.png

Entra ID では、ユーザー作成時にすでにディレクトリに存在している UPN は使用不可のため、削除済みユーザーの UPN を逃がすようになっているのだなと思いました。
理にかなっていますね。

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-8_4.png
画像_2-8_5.png
画像_2-8_6.png
画像_2-8_7.png
画像_2-8_8.png

[AWS] 結果：ユーザー状態確認

結果として、AWS 側で当該ユーザーが無効化されました (Status が Enabled から Disabled に！)。

なお、今回のように Entra ID 側でアカウントが論理削除されたとしても明示的に AWS Users グループのメンバーから削除しなかった場合、AWS 側でもグループのメンバーとして残るという結果になりました。

画像_2-8_9.png
画像_2-8_10.png
画像_2-8_11.png

2-9. アカウント有効化

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
無効状態のユーザーアカウントを有効化する ユーザー状態が Disabled → Enabled に更新される 更新 (Update)
対象ユーザー
Nikki Wolf (NikkiWolf@domain.com)

検証時系列
[2-5. アカウント無効化] の後に実施しました。

(「Nikki」ユーザーを使った検証の時系列： [2-5. アカウント無効化] → [2-9. アカウント有効化] → [2-6. サインインブロック])

2-9. 動作確認例 (左端の ▶ をクリックして展開)

ご参考までに、Entra ID 側でユーザーアカウントを無効化する前の AWS 側の状態は以下でした：
画像_2-5_10.png
([2-5. アカウント無効化] 終了時点)

操作対象ユーザーである「Nikki」アカウントの Status は Enabled 状態です。

[Entra ID] ユーザー操作実施

Entra ID 側でユーザーアカウントを無効化しました。
(ユーザーのプロパティ画面から「アカウントが有効化されました」の値を設定変更)

  • 対象ユーザーの「概要」(プロパティ) 画面を開き、画面上部の「プロパティの編集」をクリック
    画像_2-9_1.png

  • 「アカウントが有効化されました」のチェックボックスをオンにし、「保存」をクリック
    画像_2-9_2.png

  • Entra 管理センター上部に「ユーザーの更新成功」通知が表示されると、完了です

    ユーザーの更新成功
    ユーザー {UPN} のプロパティが正常に更新されました。

    画像_2-9_3.png

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-9_4.png
画像_2-9_5.png
画像_2-9_6.png
画像_2-9_7.png
画像_2-9_8.png

実はユーザーが無効な間にひそかに住所プロパティ値を更新していたのですが、無効なままでは属性変更が AWS 側に反映されず (自動プロビジョニング処理スキップ)、アカウントを有効にしたときにアカウント状態と一緒に住所の属性変更が反映されるという動作になりました。

[AWS] 結果：ユーザー状態確認

結果として、AWS 側で当該ユーザーが有効化されました (Status が Disabled から Enabled に！)。
住所情報も反映されています。
画像_2-9_9.png
画像_2-9_10.png

2-10. アカウント復元

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
論理削除状態のユーザーアカウントを復元する ユーザー状態が Disabled → Enabled に更新される 更新 (Update)
対象ユーザー
Rick Roe 2 (RickRoe2@domain.com)

検証時系列
[2-8. 論理削除（soft-delete）] の後に実施しました。

2-10. 動作確認例 (左端の ▶ をクリックして展開)

[Entra ID] ユーザー操作実施

[2-8. 論理削除（soft-delete）] にて論理削除したユーザーアカウントを復元しました。

  • Entra 管理センターにて「削除済みのユーザー」一覧を開き、対象ユーザーを選択して「ユーザーの復元」>「OK」をクリック
    画像_2-10_1.png

  • Entra 管理センター画面上部に「ユーザーの復元完了」通知が表示されると、完了です

    ユーザーの復元完了
    {ユーザー表示名} が復元されました

    画像_2-10_2.png

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-10_3.png
画像_2-10_4.png
画像_2-10_5.png
画像_2-10_6.png
画像_2-10_7.png

[AWS] 結果：ユーザー状態確認

結果として、AWS 側でユーザーが有効化されました。
また、UPN も論理削除状態時の退避 UPN から元の UPN に戻りました。
画像_2-10_8.png
画像_2-10_9.png

2-11. 完全削除

実施したこと (Entra ID) プロビジョニング結果 (AWS) 操作カテゴリ
論理削除状態のユーザーアカウントを完全削除する ユーザーが削除される 削除 (Delete)
対象ユーザー
Rick Roe (RickRoe@domain.com)

検証時系列
Rick Roe アカウントを使って、[2-7. グループメンバー除外] の後に実施しました。
(全体の時系列としては、[2-8. 論理削除（soft-delete）] の後)

2-11. 動作確認例 (左端の ▶ をクリックして展開)

[Entra ID] ユーザー操作実施

Entra ID にて、ユーザーを完全削除しました。

  • Entra 管理センターにて、対象ユーザーを論理削除
    画像_2-11_1.png
    画像_2-11_2.png

  • 「削除済みのユーザー」一覧にて対象ユーザーを選択し、「完全に削除」>「OK」をクリック
    画像_2-11_3.png

  • Entra 管理センター画面上部に「ユーザーが完全に削除されました」通知が表示されると、完了です

    ユーザーが完全に削除されました
    {ユーザー表示名} が完全に削除されました

    画像_2-11_4.png

[Entra ID] プロビジョニングログ確認

今回のユーザー操作に対するプロビジョニング処理結果のログは以下でした：

画像_2-11_5.png
画像_2-11_6.png
画像_2-11_7.png
画像_2-11_8.png
画像_2-11_9.png

[AWS] 結果：ユーザー状態確認

結果として、AWS 側からユーザーアカウントが削除されました。
画像_2-11_10.png

今回、[2-7. グループメンバー除外] の後に本検証を実施しており、完全削除する前の段階で当該ユーザーはすでに自動プロビジョニング対象のグループのメンバーからは外れていました。

その状態で完全削除しても、AWS 側のユーザーも漏れなく削除されるという結果になりました。

これは便利ですね！

3. さいごに

本記事では、Entra ID と AWS IAM Identity Center 間の自動プロビジョニング構成において、
ユーザーアカウントの運用ライフサイクルに沿った動作確認結果をまとめてみました。

新規作成・属性更新・無効化・削除・復元など、実際の運用でよくあるだろう操作を一通り試してみることで、Entra ID 側の操作が AWS 側にどう反映されるかを具体的に把握することができました。

今回の検証を通じて、Entra ID にユーザー管理を集約することで、AWS 側での手動操作が不要になり、運用の一貫性と効率がぐっと高まることを実感しました。

長くなってしまいましたが、3パートにわたる自動プロビジョニング検証シリーズはこれにて完結です！

あれも書きたいこれも書きたいと欲張った結果 3記事に増殖することになってしまいましたが、どこか一部でもみなさまのヒントになれば嬉しいです。

シリーズ記事まとめ

4. 参考

  1. admin.microsoft.com：本記事作成時点 (2025年8月) の Microsoft 365 管理センター アドレスです。(将来的に変更になる場合があります🙏) ↩

1
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
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?