AWS IAM Identity Center をオンプレミス AD と連携させる — Organizations 全機能有効化から AD Connector 設定まで

はじめに

どーも！shihopowerです！今回は AWS IAM Identity Center をオンプレミス AD と連携させる方法についてお話します。SAP 対策でこの辺の練習問題に出くわしたのですが、AD Connector やら AWS Managed Microsoft AD やら、普段業務で触らないかつ、紛らわしいサービスがたくさんでてきて頭の中がごちゃごちゃなので整理してみました。同じ悩みを抱えている方の参考になれば幸いです。

この記事で解説すること

1. AWS Organizations の全機能（All Features）とは何か、なぜ必要か
2. IAM Identity Center の Organization インスタンスと Trusted Access
3. オンプレミス AD との接続方法の比較（AD Connector vs AWS Managed Microsoft AD）
4. AD Connector を使った具体的な設定の流れ

参照ドキュメント
本記事の内容はすべて AWS 公式ドキュメントをもとにしています。

---

1. 全体アーキテクチャの概要

まず、登場するサービスの関係を整理します。

オンプレミス
┌─────────────────────┐
│  Active Directory   │
│  （既存のユーザー）  │
└──────────┬──────────┘
           │ 認証リクエストをプロキシ
           ▼
AWS
┌──────────────────────────────────────────────────┐
│ AWS Organizations（全機能有効）                   │
│                                                  │
│  ┌─────────────────┐   ┌──────────────────────┐  │
│  │  管理アカウント  │   │  メンバーアカウント   │  │
│  │                 │   │                      │  │
│  │ IAM Identity    │   │  AWS Management      │  │
│  │ Center          │──▶│  Console アクセス    │  │
│  │                 │   │                      │  │
│  └────────┬────────┘   └──────────────────────┘  │
│           │                                      │
│  ┌────────▼────────┐                             │
│  │  AD Connector   │                             │
│  │（プロキシ経由で  │                             │
│  │  オンプレ AD へ）│                             │
│  └─────────────────┘                             │
└──────────────────────────────────────────────────┘

ポイントは AD Connector がクラウド上にユーザー情報をキャッシュしないことです。認証リクエストをそのままオンプレミス AD にプロキシするため、既存の AD 管理をそのまま活かせます。

---

2. AWS Organizations の全機能（All Features）とは

2 つのフィーチャーセット

AWS Organizations には 2 つのフィーチャーセットがあります。

フィーチャーセット	内容
全機能（All Features）	統合請求 ＋ SCP などの高度な管理機能 ＋ 他 AWS サービスとの統合（推奨・デフォルト）
統合請求（Consolidated Billing）	請求を 1 つにまとめるだけ。管理機能は使えない

AWS 公式ドキュメントでは次のように述べられています。

全機能を有効にすると、組織ポリシー（SCP など）やサポートされる AWS サービスとの統合といった高度なアカウント管理機能が利用できます。

なぜ全機能が必要なのか

IAM Identity Center を AWS Organizations と組み合わせて使うには、全機能が有効になっていることが必須条件です。

AWS Organizations で IAM Identity Center 機能を有効にする場合は、Organizations の全機能が有効になっていることを確認してください。
— IAM Identity Center prerequisites and considerations

全機能が有効でないと、以下が使えません。

• IAM Identity Center による複数アカウントへの SSO
• SCP（サービスコントロールポリシー）の適用
• 他の AWS サービスとの Trusted Access

⚠️ 重要な注意点：一方向の変更

統合請求から全機能への変更は一方向です。全機能を有効にした後、統合請求のみに戻すことはできません。
— Enabling all features for an organization with AWS Organizations

全機能有効化の手順（標準マイグレーション）

全機能の有効化は次の 3 ステップで行います。

Step 1：管理アカウントからリクエスト送信

必要な IAM 権限：

organizations:EnableAllFeatures
organizations:DescribeOrganization（コンソール使用時）

AWS Management Console では、Organizations の Settings ページから「Begin process to enable all features」を選択します。

CLI の場合：

aws organizations enable-all-features

実行すると、組織内の招待済み（invited）メンバーアカウントすべてに承認リクエスト（ハンドシェイク）が送信されます。

※ Organizations で作成したアカウントにはリクエストは送られません（管理アカウントのオーナーが所有者とみなされるため）。

Step 2：メンバーアカウントが承認（ハンドシェイク）

各メンバーアカウントの管理者が承認を行います。

必要な IAM 権限：

organizations:AcceptHandshake
iam:CreateServiceLinkedRole（AWSServiceRoleForOrganizations が未作成の場合）

CLI の場合：

# ハンドシェイク ID を確認
aws organizations list-handshakes-for-account

# 承認
aws organizations accept-handshake --handshake-id h-xxxxxxxxxx

期限に注意：リクエスト送信から 90 日以内にすべてのアカウントが承認しなければ、リクエストは失効し、最初からやり直しになります。

Step 3：管理アカウントでファイナライズ

すべての招待済みアカウントが承認した後、管理アカウント側で最終確認を行い、全機能の有効化が完了します。

AWSServiceRoleForOrganizations について

全機能の有効化には、すべてのメンバーアカウントに AWSServiceRoleForOrganizations というサービスリンクロールが必要です。

このロールは全機能を有効にするために必須です。招待済みアカウントでこのロールを削除していた場合、全機能への同意ハンドシェイクを受け入れることでロールが再作成されます。
— Using AWS Organizations with other AWS services

また、全機能を有効にした後は、いかなるアカウントからもこのロールを削除できなくなります。

---

3. IAM Identity Center の Organization インスタンスと Trusted Access

Organization インスタンスとは

IAM Identity Center には 2 種類のインスタンスがあります。

インスタンス種別	説明
Organization インスタンス（推奨）	管理アカウントで有効にする。組織全体のアカウント・アプリへのアクセスを一元管理できる
Account インスタンス	単一アカウントに紐づく。IAM Identity Center の一部機能のみ利用可能

Organization インスタンスは IAM Identity Center のすべての機能をサポートします（複数 AWS アカウントのパーミッション管理、カスタムアプリへのアクセス付与など）。
— Organization instances of IAM Identity Center

Trusted Access（信頼済みアクセス）の有効化

IAM Identity Center と Organizations を連携させるために Trusted Access を有効にする必要があります。有効化すると、管理アカウントに AWSServiceRoleForSSO というサービスリンクロールが自動作成されます。

CLI での有効化：

aws organizations enable-aws-service-access \
    --service-principal sso.amazonaws.com

IAM Identity Center を有効にする際、通常は IAM Identity Center コンソールから操作することで Trusted Access も自動的に設定されます。
— AWS IAM Identity Center and AWS Organizations

委任管理者アカウントの活用（ベストプラクティス）

IAM Identity Center の管理を、管理アカウントではなく特定のメンバーアカウント（委任管理者） に委ねることができます。

これにより、管理アカウントへの直接アクセスを最小化でき、セキュリティ上望ましい構成になります。

---

4. オンプレミス AD との接続方法の比較

オンプレミス AD を IAM Identity Center のアイデンティティソースとして使う方法は主に 2 つあります。

比較軸	AD Connector	AWS Managed Microsoft AD + 双方向信頼
コスト	低い	高い（ドメインコントローラー 2 台以上を維持）
クラウドへのキャッシュ	なし（プロキシのみ）	あり
向いているケース	単一ドメイン・既存 AD をそのまま使いたい	複数ドメイン・5,000 人超・AWS 上の AD が必要
複数ドメイン/フォレスト	❌ 非対応（1 対 1 の関係）	✅ 対応
推移的信頼（Transitive Trust）	❌ 非対応	✅ 対応
マネージド度	プロキシのみ	フルマネージド（監視・バックアップ・更新を AWS が担当）

AWS 公式ドキュメントでは次のように整理されています。

AD Connector は既存のオンプレミス Active Directory を AWS に接続するだけで、既存のオンプレミスディレクトリを AWS サービスで使いたい場合に最適です。AWS Managed Microsoft AD は 5,000 人以上のユーザーがいて、AWS ホストのディレクトリとオンプレミスのディレクトリ間で信頼関係を構築する必要がある場合に最適な選択肢です。
— Best practices for AD Connector

AD Connector を選ぶ場合のポイント

AD Connector には次の制約があります。公式ドキュメントより：

AD Connector を使用して IAM Identity Center に接続する場合、IAM Identity Center は AD Connector が接続している単一ドメインのユーザーとグループにのみアクセスできます。複数のドメインやフォレストをサポートする必要がある場合は、Directory Service for Microsoft Active Directory を使用してください。
— Connect a self-managed directory in Active Directory to IAM Identity Center

また、AD Connector 使用時は次の点にも注意が必要です。

• ユーザーのパスワードリセットは AWS アクセスポータルからはできない（AD 上で行う必要がある）
• 他の AWS アカウントと共有できない
• SAMBA4 ベースの Simple AD はサポートしない

---

5. AD Connector を使った設定の流れ

設定全体の流れ

① AWS Organizations 作成
        ↓
② 全機能（All Features）を有効化
        ↓
③ IAM Identity Center を有効化（Trusted Access も自動設定）
        ↓
④ AD Connector を作成（AWS Directory Service）
        ↓
⑤ IAM Identity Center のアイデンティティソースとして AD Connector を設定
        ↓
⑥ 権限セット（Permission Set）を作成
        ↓
⑦ 権限セットを AD のグループ/ユーザーにマッピング
        ↓
⑧ IT 担当者が AD 資格情報で AWS Management Console にアクセス ✅

① AD Connector の前提条件

AD Connector を作成する前に、以下が必要です。

• オンプレミス AD への VPN または AWS Direct Connect による接続
• AD Connector 用の VPC とサブネット（2 つの AZ に 1 つずつ）
• オンプレミス AD の管理者資格情報（AD Connector が使用するサービスアカウント）

② IAM Identity Center のアイデンティティソースの変更

IAM Identity Center コンソールで次の手順を実施します。

1. IAM Identity Center コンソールを開く
2. Settings → Identity source → Change identity source
3. Active Directory を選択
4. 作成した AD Connector のディレクトリを選択して保存

IAM Identity Center は AWS Directory Service が提供する接続を使用して、ソースディレクトリのユーザー・グループ・メンバーシップ情報を IAM Identity Center のアイデンティティストアに同期します。パスワード情報は同期されません。
— Microsoft AD directory

③ 権限セット（Permission Set）の作成

権限セットとは、AWS アカウントへのアクセス権限をまとめた定義です。AWS 管理ポリシーやカスタムポリシーを組み合わせて作成します。

例：コンソール読み取り専用の権限セット

権限セット名: ReadOnlyAccess
AWS 管理ポリシー: ReadOnlyAccess
セッション時間: 8時間

④ AD グループへのマッピング

作成した権限セットを、AD の既存グループに割り当てます。

1. AWS accounts → 対象アカウントを選択
2. Assign users or groups
3. AD グループ（例：AWS-Admins）を検索して選択
4. 権限セットを選択して割り当て

これで、AWS-Admins グループのメンバーは自分の AD 資格情報で AWS Management Console にアクセスできるようになります。

---

まとめ

ポイント	内容
IAM Identity Center に Organizations は必須	全機能（All Features）が有効でないと使えない
全機能有効化は一方向	統合請求のみには戻せない。90 日以内に全アカウントの承認が必要
AD 連携の選択基準	単一ドメイン → AD Connector、複数ドメイン/大規模 → AWS Managed Microsoft AD
AD Connector の特徴	クラウドにキャッシュしない・低コスト・単一ドメインのみ
コスト最適化のポイント	要件に見合ったサービスを選ぶ。AWS Managed Microsoft AD は高機能だが高コスト

---

参考ドキュメント

• IAM Identity Center prerequisites and considerations
• Enabling all features for an organization with AWS Organizations
• Standard migration process to enable all features
• Organization instances of IAM Identity Center
• AWS IAM Identity Center and AWS Organizations
• AD Connector
• Connect a self-managed directory in Active Directory to IAM Identity Center
• Best practices for AD Connector
• Microsoft AD directory（IAM Identity Center）